Makelore 2.0 initial clean snapshot
This commit is contained in:
197
.opencode/skills/nianxxgame-skill/assets/GDD.template.md
Normal file
197
.opencode/skills/nianxxgame-skill/assets/GDD.template.md
Normal 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 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] |
|
||||
67
.opencode/skills/nianxxgame-skill/assets/TASKS.template.md
Normal file
67
.opencode/skills/nianxxgame-skill/assets/TASKS.template.md
Normal 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.
|
||||
Reference in New Issue
Block a user