26 lines
1.3 KiB
Markdown
26 lines
1.3 KiB
Markdown
---
|
|
paths:
|
|
- "design/gdd/**"
|
|
---
|
|
|
|
# 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` and is not a per-system GDD.
|
|
If `design/gdd/game-pillars.md` exists, it uses
|
|
`references/studio-docs/templates/game-pillars.md` and is also not a
|
|
per-system GDD.
|
|
|
|
- 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
|