| 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.
