Before you start
A chat assistant and an original game concept. Coding is optional for the planning exercise.
Why this lesson exists
The Godot brawler defined its first milestone as one satisfying punch, not the complete RPG. This lab practices that split: one playable milestone now, with the rest of the vision written down and deferred.
Do the exercise
Set your boundary
Separate the long-term vision from the first playable interaction. Record decisions about state, input and events so a future agent can follow them.
Write pillars and a core loop
Write the game pillars and a one-sentence core loop.
Define milestone one
Define milestone one as one satisfying action, like one punch, not the complete RPG.
Separate rules from feel
Separate testable rules from scene-dependent “feel,” and list the tunable values in one table.
Record decisions
Record every architectural decision that a future contributor might undo.
Next sessions, not today
- Tunable values in code Centralize tunable combat values in code when you build milestone one.
- System index Update the system index at each milestone.
A prompt to adapt
Replace the bracketed parts with your own details.
Help me plan [my original game concept] as small playable milestones. First version only: separate the long-term vision from milestone one, a single playable interaction with a visible action and outcome. This is a planning exercise: no code, and later RPG systems stay out of milestone one. If a step needs a tool or file, list the setup first. Then work in four checkpoints and, after each, tell me how to check it: 1. Three game pillars and a one-sentence core loop. 2. Milestone one as one satisfying action, not the complete game, with acceptance criteria and a five-minute demo checklist. 3. Which rules are testable and which depend on scene feel, with the tunable values in one table. 4. A decision record for each boundary a future contributor might undo. Leave coding the tunable values and a system index for later milestones. My engine, if any: [Godot or another engine].
When your first version is done, paste it and ask:
Review this milestone plan for scope creep. Flag anything in milestone one that belongs to later systems, acceptance criteria a five-minute demo cannot check, and boundaries without a decision record. Then name which systems should talk through signals or events instead of direct references when I build it in [Godot or another engine].
Run this experiment
Ask someone to describe the first milestone without mentioning future features. It should have a visible action, outcome and short demo checklist.
Check your result
Use evidence from your output. A confident explanation from the AI is not enough.
If it isn’t working
Architecture documents do not prove a finished game. Keep planned, implemented and playtested status distinct.
Optional. Progress stays in this browser.
Where this came from
Public project repository ↗. The practice lesson is an adaptation, not a verbatim transcript. About the sources.
Prepared September 2026. Tools and interfaces change; use current official setup instructions. Session lengths are estimates.
patrickz