Small dungeon-crawler prototypes often grow sideways. We add rooms, enemies, loot, and UI before proving that one short run is understandable and worth repeating.
Before adding content, I like to reduce the prototype to six gates. A player should be able to pass all six in one three-to-five-minute run.
1. Orientation
Can the player tell where they are, where they can move, and what looks interactable without a paragraph of instruction?
This is not an art-quality test. Grey boxes are fine. The question is whether the route and the next point of interest are readable.
2. Encounter
Does the player meet a threat or obstacle that changes their behavior?
An enemy that can be ignored forever is decoration. A locked door with no readable condition is confusion. The encounter should create a decision.
3. Choice
Is there at least one choice with a visible trade-off?
Examples: take a safer route or a shorter route; spend a limited resource now or save it; engage the enemy or avoid it. The choice does not need a large system behind it yet.
4. State change
Can the player see that their action changed the run?
A door opens, health drops, an item is consumed, an enemy changes state, or a new route becomes available. If the change is only visible in a debug log, the loop is not communicating enough.
5. Consequence
Does the earlier choice affect what happens next?
A prototype becomes a loop when the player can connect action and consequence. Without that connection, adding more content usually adds noise rather than depth.
6. Restart value
After success or failure, is there a reason to try one more run?
The reason can be small: test the other route, use the resource differently, avoid damage, or reach the end faster. You do not need a full progression system to test replay intent.
A simple review pass
Run the prototype once with no explanation. Note the first place the player stops, asks what to do, or misses a state change. Fix that single break, then run it again. Only add another room, enemy, or reward after the six-gate sequence is readable.
This checklist is engine-neutral. If you are building in Godot, Unity, or a custom stack, the same question applies: what must one short run prove before the project earns more content?
For readers comparing a manual checklist with an AI-assisted browser-prototype route, this SEELE product page describes paths from broad mini-game ideas toward browser-playable prototypes:
It is not presented here as a Godot plugin or a dungeon-crawler-specific system. The useful comparison is whether a prototype route helps you test the six gates earlier—not whether it replaces production.
Which gate tends to break first in your early RPG prototypes: orientation, choice, state feedback, or restart value?
SOCIAL SHARE CARD GENERATOR