Document Architecture — the C4 Map

This page is the map of every document a game built from this template produces, and where each one sits in the C4 model. The plan (146 tasks) says what gets made; this map says where the written result lives, so every creative asset — art, design, story, mechanics, code — slots into one consistent software architecture instead of a pile of files.

The C4 model, as used here

• L1 — System Context. The game as a single system among its actors: players, stores/platforms, press, community. Creative context lives here too: the Setting and Story are the world the player enters. Read these first; everything below zooms in from them.
• L2 — Containers. The game’s major pieces: the game client, save/data, backend services (if any), the content pipeline, this docs site. The bibles direct containers (how the client looks and sounds); budgets bind them; the GDD designs across them.
• L3 — Components. Inside the containers: gameplay systems, quests, levels, HUD/menus, asset families. Component documents specify one piece and its interfaces to its neighbours.
• L4 — Code. Classes, modules and data schemas. L4 lives in the repo and the Technical Design Document — never as site pages per class.
• Supplementary views. C4’s extra diagrams map to operations: deployment (launch), dynamic/runtime (pacing in Levels/Systems), and the running system (support). Cross-cutting records (decisions, provenance, risks, QA) govern all levels.

The GDD follows Tim Cain’s order

Setting (L1) → Story (L1) → Systems (L2/L3). The GDD compiles the three; every mechanic in it is headed by its goals and names the Setting/Story element it serves. A mechanic that serves neither is cut or justified.

Every document, by C4 position

Where a new asset slots in

Rules for reading, writing and editing inside this structure are in the repo’s AGENTS.md (“Documents and the C4 model”).