By name: game-engine-architecture description: | Game-engine architecture, engine-agnostic: the game loop (fixed vs variable timestep), ECS vs scene-graph/OOP, the render pipeline, core subsystems (physics, audio, animation, assets, memory), and netcode models. Architect- level, beyond any specific engine.
USE WHEN: designing/evaluating a game engine or game's architecture in general, "game loop", "ECS", "entity component system", "render pipeline", "forward vs deferred", "rollback netcode", "lockstep", custom engine vs off-the-shelf, data-oriented game design.
DO NOT USE FOR: Unity-specific work (use the gamedev/unity-* skills);
low-level cache/SIMD detail (use hardware-aware-design); web graphics (use
graphics skills).
allowed-tools: Read, Grep, Glob
Game-Engine Architecture (engine-agnostic)
Generalizes the Unity-specific gamedev/* skills into engine-agnostic design.
For Unity APIs/DOTS specifics, defer to those skills.
The game loop
The heartbeat: process input → update simulation → render. Key decision is the timestep:
- Fixed timestep for the simulation (deterministic physics, stable netcode), decoupled from a variable render rate with interpolation. This is the standard for anything needing determinism (multiplayer, physics).
- Variable timestep is simpler but makes physics/netcode non-deterministic.
Data model: ECS vs scene-graph/OOP
| OOP / scene graph | ECS (entity-component-system) | |
|---|---|---|
| Layout | Objects with inheritance | Data in contiguous component arrays |
| Cache | Pointer-chasing, poor | Data-oriented, cache-friendly, SIMD-able |
| Logic | Methods on objects | Systems iterate components |
| Fits | Small/simple games, editor tooling | Many entities, performance, parallelism |
ECS is the modern default for performance and parallelism (see
hardware-aware-design); OOP scene graphs remain fine for simpler titles.
Render pipeline
- Forward (shade per object) vs deferred (G-buffer, shade per pixel — many lights) vs forward+ / clustered. Choose by light count and platform (mobile/bandwidth favors forward/tiled).
- A render graph / frame graph declares passes + resource dependencies so the engine schedules and aliases GPU memory — the modern structuring approach.
Core subsystems
Physics, audio, animation, scene/asset streaming, and a memory strategy (pools/arenas/frame allocators rather than per-frame malloc — determinism + no GC stalls). Keep subsystems decoupled behind clear interfaces.
Netcode (multiplayer)
- Lockstep (send inputs, simulate deterministically everywhere): tiny bandwidth, needs full determinism; RTS.
- Client prediction + server reconciliation: responsive, authoritative server; FPS.
- Rollback: predict + re-simulate on correction; fighting games. Authority and determinism (fixed timestep) are the cross-cutting requirements.
Guidance
Prefer off-the-shelf (Unity/Unreal/Godot) unless you have a specific reason to build. If custom: fixed-timestep loop, ECS for entity-heavy/perf games, a render graph, arena memory, and a netcode model matched to the genre.