# [Game Title] — Living GDD

Project Version: v0.1.0
Document Revision: 1
Last Updated By: game-design

> Keep this document current and testable. The agent drafts it from the user's brief; do not ask the user to fill blanks. For a first concept pass, complete Status, the core prompts in Sections 1–4, the `Must`/`Not in this release` boundary in Section 6, and the top risk/current experiment in Section 7. Delete unused placeholder rows. Add active system specifications in Section 5 and evidence records in Section 8 only as the next prototype needs them, then replace hypotheses with evidence.

## Status

- **Stage:** Concept / Prototype / Build / Ship
- **Current build:** [path, URL, tag, or commit]
- **Last updated:** YYYY-MM-DD
- **Largest current risk:** [one testable question]
- **Decision labels:** Hypothesis / Tested / Committed

## 1. Game promise

- **One-sentence game:** [Player + core action + pressure/goal + distinctive result]
- **Player fantasy:** [Who the player feels like and what feeling to protect]
- **Target player:** [Relevant experience, interests, and accessibility needs]
- **Platform and input:** [Browser/device plus keyboard, pointer, touch, or gamepad]
- **Rendering mode:** [2D by default / 3D only when the user explicitly chooses it]
- **Engine:** [Phaser 3.90.0 for 2D / Three.js + TypeScript for 3D, with exact dependency version in TECH_STACK.md]
- **Typical session:** [Duration and natural stopping point]
- **Desired feeling arc:** [Start → tension/growth → result]
- **Hard constraints:** [Schedule, team, technology, content, or release limits]

## 2. Pillars and boundaries

| Pillar | Observable player promise | Trade-off it wins |
|---|---|---|
| [Pillar 1] | [What the player perceives or does] | [What to prefer when ideas conflict] |
| [Pillar 2] | [What the player perceives or does] | [What to prefer when ideas conflict] |
| [Optional pillar 3] | [Promise] | [Trade-off] |

### Non-goals for this release

- [Explicitly excluded feature, audience, mode, or production burden]
- [Second exclusion]
- [Optional third exclusion]

## 3. Experience chain and core loop

| Fantasy | Player verbs | Mechanics | Rules/pressure | Feedback | Reason to repeat |
|---|---|---|---|---|---|
| [Experience] | [3–6 verbs] | [Systems] | [Limits and consequences] | [How results are perceived] | [Mastery, variation, reward, or new goal] |

### Core loop

1. [Receive or choose a goal.]
2. [Read the situation and decide.]
3. [Perform the core verb.]
4. [Receive a clear consequence.]
5. [Retry, advance, or choose the next goal.]

### State flow

`Launch → Start → Play → Pause/Resume → Outcome → Retry/Continue`

- **Start condition:** [How play begins]
- **Success/outcome condition:** [Observable rule]
- **Failure/end condition:** [Observable rule]
- **Retry/continue:** [What resets, what persists, and retry friction]

## 4. Player model

### Controls and feedback

| Input/context | Verb | Availability | Immediate response | Accessible alternative |
|---|---|---|---|---|
| [Input] | [Action] | [When legal] | [Control/visual/audio response] | [Remap, toggle, assist, or N/A with reason] |

### Rules the player must understand

1. [Rule or invariant in player language]
2. [Rule or invariant in player language]
3. [Rule or invariant in player language]

### Essential information

| Player question | How the game answers | Fallback cue |
|---|---|---|
| What is my goal? | [World/UI/audio cue] | [Persistent or repeatable cue] |
| What can I act on? | [Affordance and state cue] | [Redundant cue] |
| What changed and why? | [Cause/effect feedback] | [Result/failure explanation] |
| What can I do next? | [Prompt, layout, or state] | [Recovery route] |

### Presentation baseline

- **Camera:** [Fixed/following; framing, bounds, movement, shake, and comfort limits]
- **3D presentation when applicable:** [Scene, world-up, units, model format, lighting, camera controls, loading fallback, and performance target]
- **UI:** [Persistent information, overlays, safe areas, and hierarchy]
- **Feel and feedback:** [Timing, motion, audio, effects, and restraint]
- **Accessibility:** [Remapping, alternatives, reduced motion, contrast, text, and audio controls]

## 5. Active system specifications

> Copy this block only when a system enters active work. Keep its stable `SYS-###` ID. Tracked tasks must reference the ID or exact heading.

### SYS-001 — [System name]

- **Status:** Hypothesis / Tested / Committed
- **Player purpose and pillar:** [Why it exists]
- **Decision or expression:** [Meaningful choice or skill]
- **Inputs and preconditions:** [Trigger and legal context]
- **Owned/read state:** [State and source of truth]
- **Outputs/events:** [State changes and external signals]
- **Dependencies:** [Systems, assets, content, or platform assumptions]

#### Rules and transitions

1. [Availability/start rule]
2. [Active behavior, priority, or formula]
3. [Resolve, interrupt, and recovery rule]

`available → started → active → resolved/interrupted → recovered`

#### Feedback and fairness

| Event/state | Immediate confirmation | Consequence | Recovery/next action | Redundant cue |
|---|---|---|---|---|
| [Event] | [Response] | [Visible result] | [What follows] | [Non-audio/non-color cue] |

#### Tunables

| Name | Unit | Default hypothesis | Safe test range | Intended player effect |
|---|---|---:|---:|---|
| [Meaningful name] | [s, px/s, count, %] | [value] | [low–high] | [Effect] |

#### Edge cases

- [Repeated/simultaneous input]
- [Interrupt, scene/state change, or limit]
- [Cleanup and player recovery]

#### Delivery contract

- **Acceptance criteria — maximum 3:**
  - [ ] [Observable player-facing condition]
  - [ ] [Critical rule or edge condition]
  - [ ] [Feedback/recovery condition]
- **Non-goals — maximum 3:** [Excluded behavior for this version]
- **Primary playtest question:** [One uncertainty this implementation must answer]

## 6. MVP and release boundary

### Must

- [Complete start → play → result → retry/continue loop]
- [Core system/content requirement]
- [Required feedback, UX, accessibility, or delivery condition]

### Later, after evidence

- [Extension and the evidence that would justify it]
- [Extension and trigger]

### Not in this release

- [Explicit exclusion]
- [Explicit exclusion]

### Quality boundary

- **Target environment:** [Device/browser/display/input]
- **Performance target:** [Frame rate, load time, or supported floor]
- **Save/data expectation:** [Persistence and compatibility]

## 7. Risks and playtests

| Priority | Risk as a question | Cheapest valid test | Pass/change signal | Status/evidence |
|---:|---|---|---|---|
| 1 | [Largest uncertainty] | [Prototype/playtest] | [Observed behavior] | [Planned/Keep/Change/Inconclusive + link] |
| 2 | [Next uncertainty] | [Test] | [Signal] | [Status] |

### Current experiment

- **Question:** [One question]
- **Build:** [Included and deliberately omitted]
- **Observe:** [Behavior/result, not only opinion]
- **Decision:** Keep / Change / Inconclusive
- **Next action:** [One concrete follow-up]

## 8. Evidence and decisions

### Tuning

| Variable | System | Current value | Target effect | Last evidence | Next test |
|---|---|---:|---|---|---|
| [Name] | [SYS-###] | [Value + unit] | [Player outcome] | [Build/test/date] | [Change/control] |

### Playtests and design changes

| Date/build | Question or trigger | Observed evidence | Decision | Affected sections/tasks |
|---|---|---|---|---|
| [Date/build] | [Question, constraint, defect] | [What happened] | [Keep/change and why] | [Headings, SYS IDs, TASK IDs] |