game-engine-architecture

v2026.09.24

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

GitHub
Install command
npx skhub add claude-dev-suite/game-engine-architecture
Markdown
SKILL.md

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 graphECS (entity-component-system)
LayoutObjects with inheritanceData in contiguous component arrays
CachePointer-chasing, poorData-oriented, cache-friendly, SIMD-able
LogicMethods on objectsSystems iterate components
FitsSmall/simple games, editor toolingMany 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.

Discovery
Tags

No tags published for this skill.

Version
Latest version metadata

Version

v2026.09.24

Published

Sep 24, 2026

Category

Uncategorized

License

MIT

Source path

skills/systems/game-engine-architecture

Default branch

main

Latest commit

9496306

Tree SHA

fe4e2f1