Before you start
A chat assistant and an original game concept. Coding is optional for the planning exercise.
Why this lesson exists
This lab adapts the “Architect a 2.5D JRPG Brawler in Godot” project write-up into a practice build. The time is an estimated first session, not a promise to finish a production system. Use the public repository as a reference when available; the exercise can be built with original sample content.
Do the exercise
Define the practice version
Separate the long-term vision from the first playable interaction. Record decisions about state, input and events so a future agent can follow them.
Build step 1
Write the game pillars and one-sentence core loop.
Build step 2
Define MVP 1 as one satisfying punch, not the complete RPG.
Build step 3
Separate testable rules from scene-dependent “feel.”
Build step 4
Centralize tunable combat values.
Build step 5
Record every architectural decision that a future contributor might undo.
Build step 6
Update the system index at each milestone.
Run the experiment
Ask someone to describe the first milestone without mentioning future features. It should have a visible action, outcome and short demo checklist.
A prompt to adapt
Replace the bracketed parts with your own practice details.
Work in a disposable practice project. Explain any setup requirements before changing files. Build one small step at a time and show how I can check it. Turn this game idea into six playable MVPs. Each MVP needs one observable goal, acceptance criteria, systems required, content limits, risks, automated-test targets, and a five-minute demo checklist. Prevent later RPG features from leaking into MVP 1. Review this Godot architecture for coupling. Identify direct system references that should become typed signals, global state that should become owned components, and logic that can be extracted for unit testing. My first-version 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.
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.
- Milestone one can be demonstrated independently.
- Deferred systems stay out of the first scope.
- Decision records explain why boundaries exist.
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.