Makelore 2.0 initial clean snapshot

This commit is contained in:
inman
2026-07-29 17:22:35 +08:00
commit b8ca3f8eea
694 changed files with 139782 additions and 0 deletions

View File

@@ -0,0 +1,197 @@
# [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 14, 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] | [36 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] | [lowhigh] | [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] |

View File

@@ -0,0 +1,67 @@
# [Game Title] — Tasks
Project Version: v0.1.0
Document Revision: 1
Last Updated By: <stable-agent-id>
> Every Agent reads and maintains this current-version task context. Keep specialized facts in role-owned artifacts and link them here. Record owner, status, acceptance, evidence, blockers, version proposals, and next action.
## Now
### TASK-001 — [Player-visible outcome]
- **Design source:** [§ exact GDD heading, SYS-###, or concise defect note]
- **Why now:** [Risk reduced, loop completed, or evidence needed]
- **Playable slice:** [Start condition → player action → feedback/result → retry/continue]
#### Acceptance criteria — 1 to 3
- [ ] [Observable behavior in the target play environment]
- [ ] [Critical rule, failure, or edge case]
- [ ] [Feedback, recovery, or complete-loop condition]
#### Non-goals — maximum 3
- [Behavior, content, or polish explicitly outside this task]
- [Optional exclusion]
- [Optional exclusion]
#### Completion evidence — 1 to 3
- [ ] [Build/test command and result]
- [ ] [Playtest path and observed result]
- [ ] [Optional screenshot, recording, log, or URL]
## Next — maximum 3
1. **TASK-002 — [Player-visible outcome]** — Design: [§ heading/SYS-###/defect note] — [Why it follows]
2. **TASK-003 — [Player-visible outcome]** — Design: [§ heading/SYS-###/defect note] — [Why it follows]
3. **TASK-004 — [Player-visible outcome]** — Design: [§ heading/SYS-###/defect note] — [Why it follows]
## Blocked
| Task | Design reference | Blocker | Evidence already gathered | Unblock condition/owner |
|---|---|---|---|---|
| [TASK-### — outcome] | [§ heading/SYS-###] | [Specific missing input or dependency] | [Link/result] | [Concrete condition and responsible person if known] |
## Version Proposals
| Proposed version | Level | Proposed by | Reason | Affected artifacts | Status |
|---|---|---|---|---|---|
| [v0.2.0] | [PATCH/MINOR/MAJOR] | [stable-agent-id] | [Why a new version is needed] | [Files/areas] | proposed |
## Last verified
- **Date/build:** [YYYY-MM-DD + URL/tag/commit]
- **Environment:** [Device, browser/runtime, display, and input]
- **Verified path:** [Start → core action → result → retry/continue]
- **Checks passed:** [Build/runtime/console/playtest results]
- **Known issue:** [Most important remaining issue, or “None known”]
## Promotion rule
When `Now` is complete:
1. Record up to three pieces of completion evidence and update `Last verified`.
2. Propagate any design discovery to the applicable GDD section or defect note before closing the task.
3. Promote at most one `Next` task that attacks the largest current risk or closes the most important playable loop. If none is justified, leave `Now` explicitly empty.