Before you add more rooms: a six-gate playable-loop check for small RPG prototypes

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.

The Six Gates

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: https://www.seeles.ai/ai-game-generator?utm_source=devto&utm_medium=article&utm_campaign=rpg_indiedev_w1&utm_content=dungeon_loop_checklist_v07

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?