Plan a game as small playable milestones
https://patrickz.ai/learn/game-architecture/

OUTCOME
Produce an implementation plan with a testable first milestone.

YOU NEED
A chat assistant and an original game concept. Coding is optional for the planning exercise.

1. 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.

2. Build step 1
Write the game pillars and one-sentence core loop.

3. Build step 2
Define MVP 1 as one satisfying punch, not the complete RPG.

4. Build step 3
Separate testable rules from scene-dependent “feel.”

5. Build step 4
Centralize tunable combat values.

6. Build step 5
Record every architectural decision that a future contributor might undo.

7. Build step 6
Update the system index at each milestone.

8. 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.

PROMPT
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.

EXAMPLE / 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
[ ] Milestone one can be demonstrated independently.
[ ] Deferred systems stay out of the first scope.
[ ] Decision records explain why boundaries exist.

IF IT FAILS
Architecture documents do not prove a finished game. Keep planned, implemented and playtested status distinct.

MY RESULT / NEXT CHANGE