# Game Engine Architecture

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

- Skill: `claude-dev-suite/game-engine-architecture` (Agent Skill)
- Install (CLI): `npx skillmds@latest add claude-dev-suite/game-engine-architecture`
- Raw SKILL.md: https://api.skillmd.com/api/skills/claude-dev-suite/game-engine-architecture/raw
- Safety review: pending (external: skill-scanner PASS, skillspector PASS)
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Web & Frontend
- Author: claude-dev-suite (https://skillmd.com/u/claude-dev-suite)
- Updated: 2026-09-08
- Page: https://skillmd.com/skills/claude-dev-suite/game-engine-architecture

---

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