game-architecturelisted

# Game Architecture ## Purpose Game codebases decay in a characteristic way: a deep inheritance tree that cannot accommodate the next entity, a manager singleton that everything talks to, gameplay rules tangled into engine callbacks so nothing can be tested, and tuning values compiled into code so designers must ask a programmer to change a number. This skill covers the structural decisions that prevent that. It is engine-agnostic; `unreal-*`, `unity-*`, `godot-*` and `roblox-*` skills supply the idioms each engine expects. ## When to use - Starting a project, or a substantial new system inside one. - Adding a feature that touches several existing systems. - When adding an entity type requires editing many unrelated files. - When gameplay rules cannot be tested without launching the game. - When designers cannot change values without a programmer and a rebuild. ## When NOT to use - A game jam or a prototype answering a design question. Structure the code to be thrown away; architecture applied to a prototype delays the answer. - A single specific defect. Use `root-cause-debugging`. - Frame-time problems. Use `performance-profiling-method` first; architecture chosen for imagined performance reasons is usually wrong. ## Required context | Fact | Why it matters | |---|---| | Genre and core loop | Determines which systems are central | | Entity count and update frequency | Decides whether ECS-style data layout is warranted | | Single-player or networked | Networking