17-game-system-architecture-specification
Installation
SKILL.md
Game System Architecture Specification
Use When
- An approved game SRS needs architecture and ADRs.
Do Not Use When
- Detailed classes are the task; use the game technical implementation specification.
- Do not hide authority or save ownership inside engine components.
Required Inputs
| Artefact | Source or provider | Required? | Behaviour when missing |
|---|---|---|---|
GREQ-*, engine/platform decision, topology, budgets and risks |
Requirements, architecture and production | Yes | Stop and return unresolved decisions. |
| Plugins, platform services, data and threat constraints | Specialist owners | Conditional | Mark integration provisional. |
Workflow
- Draw contexts for client, services, platform, content/build, telemetry and operators.
- Define state, command/event flow, determinism, saves/migrations and time/randomness ownership.
- Establish engine-neutral domain boundaries and Unity, Godot, Unreal or Apple adapters.
- Specify content streaming, asset import, graphics/audio/UI/camera budgets, accessibility/localisation settings and fallbacks, consuming approved visual contracts from
design-system-skills. - Design online topology, replication budget, sessions, persistence and compatibility where applicable.
- Design trust, data/economy/ad integrity, separate SDK privacy boundaries, child-safe disabled defaults, build provenance, observability and rollback/kill switches.
- Define shared-platform seams as optional capabilities with per-game adoption, identity, performance and simplicity criteria; do not force every package into every game.