wangxuming/makelore
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
80e8386fa61a82f86611d8decb18bb5cc9bf9fc7
makelore/.opencode/skills/nianxxgame-skill/assets/GDD.template.md
inman b8ca3f8eea Makelore 2.0 initial clean snapshot
2026-07-29 17:22:35 +08:00

7.5 KiB
Raw Blame History

[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]