Game Engine In C++: Architecture And Core Loop

Building your own engine from scratch is the fastest way to understand how low-level systems, memory management, and graphics APIs work together. Most tutorials handwave the architectural decisions, leaving you with tangled classes and memory leaks before you even render a textured quad.

To write a functional system in C++, you need to design a strict application loop, manage resource lifetimes using smart pointers, and interface directly with modern graphics hardware. Let's break down how to architect a lightweight, extensible framework without relying on bloated external libraries.

Setting Up the Build System and Project Layout

Before writing any C++ source code, you need a clean directory structure and a reliable build generator. Relying on IDE-specific project files will lock you into a single platform, so using CMake is the standard industry approach for cross-platform compilation.

Structure your root directory with separated subfolders to isolate concerns:

• core/: Contains the main application window, time step calculations, and engine loop.
• renderer/: Manages graphics context creation, shaders, and vertex buffers.
• input/: Handles keyboard, mouse, and gamepad polling states.
• utils/: Houses logging macros, file loaders, and math helper headers.

Your root CMakeLists.txt file configures the compiler standards and binds your internal subdirectories together:

cmake_minimum_required(VERSION 3.22)
project(EngineCore CXX)

set(CMAKE_CXX_STANDARD 20)
set(CMAKE_CXX_STANDARD_REQUIRED ON)

add_subdirectory(core)
add_subdirectory(renderer)
add_subdirectory(input)
add_subdirectory(utils)

Targeting C++20 gives you access to concepts, designated initializers, and formatting libraries that keep low-level boilerplate code concise and readable.

Designing the Core Application Loop

Every interactive application relies on a continuous loop that processes input, updates game state, and renders frames. A naive loop running at maximum CPU speed will peg your processor at 100 percent utilization and drain a laptop battery in minutes. You need a fixed or variable time step that measures delta time accurately.

Here is how you structure the main execution class in core/Engine.cpp:

#include "Engine.hpp"
#include <chrono>
#include <thread>

namespace Engine {

    CoreApp::CoreApp() : m_isRunning(false) {}

    void CoreApp::Initialize() {
        // Initialize windowing context and graphics API
        m_isRunning = true;
    }

    void CoreApp::Run() {
        auto previousTime = std::chrono::high_resolution_clock::now();
        
        while (m_isRunning) {
            auto currentTime = std::chrono::high_resolution_clock::now();
            std::chrono::duration<float> elapsed = currentTime - previousTime;
            previousTime = currentTime;

            float deltaTime = elapsed.count();

            ProcessInput();
            Update(deltaTime);
            Render();
        }
    }

    void CoreApp::Shutdown() {
        // Clean up graphics context and allocated buffers
    }
}

By tracking deltaTime, your physics calculations and movement updates remain frame-rate independent. If a player drops from 120 frames per second to 60 frames per second, objects move the exact same distance per second.

Initializing Modern Graphics and Shaders

Modern hardware requires explicit context creation. Instead of legacy OpenGL immediate mode, you must manage Vertex Array Objects (VAOs) and Vertex Buffer Objects (VBOs) manually.

When configuring your rendering pipeline, compile vertex and fragment shaders directly at runtime. For example, a basic vertex shader passes transformed coordinates to the rasterizer:

#version 330 core
layout(location = 0) in vec2 aPosition;

void main() {
    gl_Position = vec4(aPosition, 0.0, 1.0);
}

Pair this with a fragment shader that outputs a flat color to the framebuffer:

#version 330 core
out vec4 fragColor;

void main() {
    fragColor = vec4(0.2f, 0.6f, 0.9f, 1.0f);
}

Loading these strings into OpenGL requires checking compilation logs. If a shader fails to compile, your engine should throw an exception or log the exact error string returned by glGetShaderInfoLog. Never ignore shader compilation failures, as silent failures result in black screens.

Managing Memory and Resource Lifetimes

Writing an engine in C++ means you are entirely responsible for object lifetimes. Manual new and delete calls across multiple subsystems lead to double-free bugs and dangling pointers.

Adopt modern memory management practices by following these rules:

• Use std::unique_ptr for subsystems or components with a strict single-owner lifetime, such as the renderer or window context.
• Use std::shared_ptr and std::weak_ptr for shared assets like textures, meshes, and audio clips loaded from disk.
• Avoid raw pointers except for non-owning references where nullability is guaranteed during the object's lifespan.

If your texture manager loads an image file multiple times, store those assets in an unordered map cache indexed by file path strings. This prevents redundant disk reads and duplicate GPU memory allocations.

Common Architecture Pitfalls to Avoid

Building a custom framework comes with distinct engineering traps. Watch out for these frequent mistakes:

• Tight Coupling: Do not let your rendering code directly query input states. Pass input structures into your update loop so systems remain modular and testable.
• Premature Optimization: Don't write custom memory allocators or entity-component systems before you have a solid window opening and rendering a colored triangle.
• Global State Abuse: Avoid singletons for core systems. Passing pointers or references explicitly makes multi-threading and unit testing much easier down the road.

Frequently Asked Questions

Which graphics API should I target first?

OpenGL or Vulkan are the standard choices for desktop development. OpenGL is significantly easier to learn for a first-time engine builder, while Vulkan provides explicit low-level control at the cost of thousands of lines of boilerplate setup code.

How do I handle cross-platform window creation?

Instead of writing native Win32 or X11 platform code from scratch, integrate a lightweight window abstraction library like GLFW or SDL. They handle OS-level event polling, OpenGL context creation, and input handling cleanly.

Should I write my own math library?

Writing your own vector and matrix math classes is a fantastic learning exercise for understanding transformations and linear algebra. However, once you understand the math, switch to a tested, header-only library like GLM (OpenGL Mathematics) to avoid subtle floating-point precision bugs.