Game Development

Game development is the engineering and craft of building interactive real-time software. A game is a soft real-time simulation: it reads input, advances a model of the world, and presents the result as images and sound, repeating that 30 to 240 times a second on hardware that ranges from phones to consoles to high-end PCs. This hub covers the architecture every game shares (the engine, the game loop, and how game objects are composed) and links to the focused pages on gameplay systems, audio, multiplayer, and production.

Topics in This Section

The pages are grouped by the layer of a game they cover.

Suggested reading order

• New to game programming: Game Loop, then ECS, then core loop design, then save systems and UI.
• Solo or small-team developers: Engines, procedural generation to stretch a small content budget, monetization, and testing early rather than late.
• Large productions: Unreal Engine, multiplayer networking, performance optimization, and certification.
• Specialists: technical art (rendering and shaders), XR (VR/AR and spatial audio), and networking (multiplayer and network fundamentals).

How the pieces fit together

flowchart TD
    IN["Input<br/>devices, remapping"] --> LOOP["Game loop"]
    LOOP --> SIM["Simulation<br/>gameplay, AI, physics"]
    NET["Networking<br/>replication, prediction"] <--> SIM
    SIM --> WORLD["World state<br/>entities and components"]
    WORLD --> REN["Rendering"]
    WORLD --> AUD["Audio"]
    WORLD --> UI["UI / HUD"]
    WORLD <--> SAVE["Save / load"]
    CONTENT["Content pipeline<br/>assets, procedural generation"] --> WORLD
    REN --> OUT["Frame presented"]
    AUD --> OUT
    UI --> OUT

The engine owns the loop and the subsystems. Game code lives mostly in the simulation, and every other system reads from or writes to the shared world state.

Engines

An engine provides the loop, rendering, audio, physics, input, asset pipeline, and editor, so that a team spends its time on the game rather than on infrastructure. The choice of engine shapes the language the team works in, the platforms it can reach, and the costs it pays.

When choosing, weigh the target platforms (console support and certification tooling), the team’s language skills, how much engine source access you need (Unreal and Godot ship source; Unity source access is an enterprise add-on), the genre (2D, open world, competitive multiplayer), and the total cost over the product’s lifetime. Engine migrations mid-project are expensive, so prototype the riskiest system in the candidate engine before committing.

Game Loop Architecture

Every game runs a loop that repeats once per frame:

flowchart LR
    I["Process input"] --> U["Update simulation<br/>(zero or more fixed steps)"]
    U --> R["Render<br/>(interpolated state)"]
    R --> P["Present / wait for vsync"]
    P --> I

Fixed and variable timesteps

The central design decision is how simulation time relates to wall-clock time.

The standard approach, popularized by Glenn Fiedler’s “Fix Your Timestep!”, decouples the two clocks:

const double dt = 1.0 / 60.0;          // simulation step (e.g. 60 Hz)
double accumulator = 0.0;
double previous = now();

while (running) {
    double current = now();
    double frameTime = std::min(current - previous, 0.25);  // clamp to avoid the "spiral of death"
    previous = current;
    accumulator += frameTime;

    pollInput();
    while (accumulator >= dt) {        // catch up in whole fixed steps
        prevState = state;
        simulate(state, dt);           // physics, gameplay, AI: deterministic step
        accumulator -= dt;
    }

    double alpha = accumulator / dt;   // fraction of the next step already elapsed
    render(lerp(prevState, state, alpha));
}

Engines expose this directly. Unity has FixedUpdate (physics) and Update (per frame). Unreal ticks per frame by default, with optional physics substepping and async physics. Godot has _physics_process and _process. Networked games that use lockstep or rollback netcode need a fixed, deterministic step so that every peer computes the same result; see Multiplayer Networking.

Two other frame-level concerns are worth knowing:

• Frame pacing. Consistent frame times matter more than average FPS. A game averaging 60 FPS with alternating 10 ms and 23 ms frames looks worse than a steady 50 FPS.
• Parallelism. Modern engines split each frame into jobs on a worker pool and pipeline simulation and rendering, so the render thread draws frame N while the game thread simulates frame N+1. This adds a frame of latency in exchange for throughput.

State machines

Game logic above the loop is usually organized as finite state machines: a character is in exactly one of Idle, Moving, Jumping, Attacking, or Stunned, with explicit transitions between them.

stateDiagram-v2
    [*] --> Grounded
    state Grounded {
        [*] --> Idle
        Idle --> Moving: input
        Moving --> Idle: no input
    }
    Grounded --> Airborne: jump / fall
    Airborne --> Grounded: land
    Grounded --> Stunned: hit
    Airborne --> Stunned: hit
    Stunned --> Grounded: recover

Hierarchical state machines (as in the Grounded superstate above) let shared transitions, such as “hit leads to Stunned”, be defined once on the parent instead of on every sub-state, which avoids a combinatorial explosion of transitions. The same structure drives menus (see UI Design), game flow (boot, menu, loading, playing, paused), and animation graphs. For AI decision making, behavior trees and utility systems usually scale better than raw FSMs; see Game AI.

Entity Component System (ECS)

A classic object-oriented game hierarchy (Actor, then Pawn, then Character, then FlyingCharacter) becomes rigid as designers ask for new combinations. Component-based design replaces inheritance with composition: an object is the set of components it has. Entity Component System (ECS) takes this further and separates data from behavior entirely:

flowchart LR
    subgraph A1["Archetype: Position + Velocity"]
        direction TB
        P1["Position[ ]"]
        V1["Velocity[ ]"]
    end
    subgraph A2["Archetype: Position + Velocity + Health"]
        direction TB
        P2["Position[ ]"]
        V2["Velocity[ ]"]
        H2["Health[ ]"]
    end
    MOVE["MovementSystem<br/>query: Position, Velocity"] --> A1
    MOVE --> A2
    DMG["DamageSystem<br/>query: Health"] --> A2

Because each component type is stored in tightly packed arrays, a system reads memory sequentially. This is cache-friendly, easy to vectorize, and easy to parallelize, since systems that touch disjoint components can run at the same time. The two common storage designs are:

• Archetype (table) storage. Entities with the same component set share a table of column arrays. Iteration is very fast, but adding or removing a component moves the entity to a different table. Unity Entities (DOTS), Unreal Mass, Bevy, and flecs use this design.
• Sparse-set storage. Each component type has its own sparse set indexed by entity. Adding and removing components is cheap, and iteration over several components is somewhat slower. EnTT uses this design, and Bevy offers it as an option per component.

ECS pays off with large numbers of similar entities (crowds, projectiles, particles, RTS units) and with simulation that has to be parallel or deterministic. For a few hundred unique, script-heavy objects, a conventional component model such as Unity GameObjects, Unreal Actors and Components, or Godot nodes is usually simpler to work with. Many engines combine the two: they use objects for authoring and ECS for hot loops.

Design, Physics and Platforms

A few cross-cutting fundamentals come up in every project:

• Core loop design. The repeated activity that drives engagement (for example fight, loot, upgrade, fight harder) is tuned to player motivations (mastery, exploration, social play, expression) and paced with a difficulty curve. Accessibility and assist options widen the audience without removing challenge for others.
• Physics and collision. Engines ship physics middleware or their own solvers: Unreal uses Chaos, Unity uses PhysX (with Havok as an option for DOTS), Godot 4.4 and later can use Jolt as a built-in option, and Havok and Jolt are also licensed standalone. Collision detection runs a broad phase (BVH, sweep-and-prune, or spatial grids) to find candidate pairs, then a narrow phase (GJK/EPA, SAT) for exact contacts. Characters usually use a kinematic capsule controller with step and slope handling rather than a full rigid body.
• Platform targets. Consoles require certification (TRC, TCR, and lotcheck requirements) and usually fixed 30, 60, or 120 FPS modes. Mobile is limited by thermals, battery, memory, and touch UI. PC needs scalable graphics settings, several input methods, and handheld PCs such as the Steam Deck as an increasingly common target. See Testing & QA and Platform Tuning.

See Also

• Performance Optimization: profiling, bottleneck analysis, and platform-specific tuning
• Networking Fundamentals: the transport-level concepts underneath multiplayer
• 3D Rendering and Shader Programming: the GPU side of the frame
• Game AI: decision making and navigation for non-player characters