1.4 KiB
1.4 KiB
paths
| paths | |
|---|---|
|
Design Document Rules
These rules apply to per-system GDDs under design/gdd/**.
design/gdd/game-concept.md uses
references/studio-docs/templates/game-concept.md. In full /brainstorm
review mode, design/gdd/game-pillars.md is created or updated through the
creative-director subagent during CD-PILLARS. In lean or solo mode, the main
brainstorm workflow creates the initial version directly. It uses
references/studio-docs/templates/game-pillars.md.
- Every design document MUST contain these 8 sections: Overview, Player Fantasy, Detailed Rules, Formulas, Edge Cases, Dependencies, Tuning Knobs, Acceptance Criteria
- Formulas must include variable definitions, expected value ranges, and example calculations
- Edge cases must explicitly state what happens, not just "handle gracefully"
- Dependencies must be bidirectional — if system A depends on B, B's doc must mention A
- Tuning knobs must specify safe ranges and what gameplay aspect they affect
- Acceptance criteria must be testable — a QA tester must be able to verify pass/fail
- No hand-waving: "the system should feel good" is not a valid specification
- Balance values must link to their source formula or rationale
- Design documents MUST be written incrementally: create skeleton first, then fill each section one at a time with user approval between sections. Write each approved section to the file immediately to persist decisions and manage context