A dungeon crawler feels tense when every room changes what the player can afford to do next. Start with a short route, one encounter and a resource that carries between rooms. A small fixed dungeon lets you check the exploration and combat loop before adding random maps or a large inventory.
This guide sets out a fictional three-room design and a prompt for an AI game maker. The numbers and later design change are proposed rules, not observations from a finished game. Use the walkthrough to check what your own prototype actually does.
Give each room a purpose
Connect an entrance, a guard room and an exit in a line. A trap on the route to the guard damages the player once. The guard blocks progress until defeated, and the exit completes the run if the player is still alive. The player starts with one healing potion and decides whether to use it after the trap or save it.
| Location | Player task | State that carries forward |
|---|---|---|
| Entrance | Learn movement and approach the route | Health and one potion |
| Guard room | Survive a trap and resolve one encounter | Remaining health and potion status |
| Exit | Reach the finish while alive | Victory or defeat result |
A fixed route is enough to test the relationship between exploration and attrition. Make room transitions visible and keep the guard and trap states when the player backtracks. A player should not be surprised by a reset unless they have started a new run.
Set a small resource budget
Start at 10 health. The trap deals 4 damage once, leaving 6. The potion restores up to 3 health, without exceeding the maximum of 10, and can be used only once. The guard has 6 health; each player attack deals 3. After each attack that leaves it alive, the guard responds for 2 damage.
Without the potion, the first attack leaves the guard at 3 health; its response reduces the player from 6 to 4. The second attack defeats the guard, so it does not respond again. If the player uses the potion immediately after the trap, health rises from 6 to 9; the same response leaves 7. Both paths reach the exit in this example. The cost of the second path is spending the only potion, which becomes meaningful when you add another threat later.
| Choice after the trap | Health before the guard | Health after the guard | Potion remaining |
|---|---|---|---|
| Save potion | 6 | 4 | One |
| Use potion | 9 | 7 | None |
These are deliberately simple design assumptions, not a balance test. The immediate first version does not punish saving the potion, so tell the reader what the choice teaches instead of claiming it creates a difficult trade-off already.
Specify the dungeon in a build request
Describe the room sequence, events and state transitions as well as the mood. SEELE's capability catalogue describes game creation from an idea, including RPG and roguelike categories, and a 2D asset workshop. Use those categories to guide the request, then inspect the actual result. They do not establish that this exact dungeon or combat system has been generated and tested.
Create an original small top-down dungeon crawler.
Connect an entrance, a guard room and an exit in that order.
Start the player at 10 maximum health with one potion.
A trap on the route to the guard deals 4 damage once per run.
A potion restores up to 3 health, never above maximum, and is consumed.
The guard has 6 health. Each player attack deals 3 damage.
After a player attack, the guard deals 2 damage only if it is still alive.
Defeating the guard opens the route to the exit. Reaching the exit alive wins.
At zero or less player health, end the run immediately in defeat.
Keep trap and guard states when backtracking. Show health, potion status,
room and clear feedback for damage, healing and the final result.
Restart restores the player, potion, trap, guard and initial room.
Use original illustrated characters and stone rooms, without franchise assets.Build room transitions and state first, then the encounter and potion. Add atmosphere after the underlying rules are consistent. If the first output changes several systems at once, ask for one correction using a precise starting state and expected result.
Make information visible without removing uncertainty
Show current health and whether the potion remains. A trap can be visible as a marker in the prototype so the player understands what caused damage. A guard's remaining health can make the timing of its response clear. Later, you can choose to conceal information, but define what the player can reasonably learn before relying on that uncertainty as a challenge.
Backtracking should not duplicate rewards or reset hazards accidentally. Record whether the trap has fired and whether the guard is defeated as run-level state. If the player revisits the guard room, preserve those facts until restart.
Check the run from entrance to exit
- Trap: cross it at 10 health and expect 6. Return across it and verify that health stays at 6.
- Encounter: attack the 6-health guard once and expect 3 health remaining on the guard plus one 2-damage response. Defeat it with the next attack and confirm no second response occurs.
- Healing: after the trap, use the potion and expect 9 health. Try again and confirm that no second healing occurs. In a fresh run, use it at full health and verify the cap remains 10.
- Ending: defeat the guard and reach the exit alive. Victory should occur once; reaching zero health should instead end the run immediately.
- Restart: confirm the player returns to the entrance at 10 health with the potion, a fresh trap and a living guard.
When a check fails, describe the setup, action and expected result. For example: “The guard had 3 health, and the player dealt 3 damage. The guard was defeated but attacked again; a defeated guard should not respond.” Retest the nonlethal first attack too, so the fix does not remove every response.
Plan a branch as a hypothetical iteration
Once the fixed route works, consider adding a side passage after the trap. In this proposed version, the side passage has a second 4-damage hazard before rejoining the route to the exit. It offers no reward yet, so it is a useful state test but not a compelling strategic choice. Add a clearly specified reward or shortcut only after deciding why a player might take that risk.
Test the saved-potion path against the added hazard: the player leaves the guard at 4 health and would reach zero if they take 4 more damage, causing immediate defeat. A player who healed after the trap leaves at 7 and would survive at 3. These outcomes follow the proposed numbers; they are not results from a playtest. Track the new hazard separately so revisiting it does not accidentally trigger the original trap again.
Frequently asked questions
Do I need procedural rooms in the first version?
No. Three fixed rooms make transitions and resource changes predictable. Once the player can complete and restart the route, introduce a small pool of room layouts and record how a particular layout can be reproduced. Generated variety is more useful when the underlying events already work.
When should the player use the potion?
In the initial example, either choice reaches the exit because no damage follows the guard. Saving it becomes useful only when a later rule gives it a purpose. Make future threats and potion availability part of the design rather than claiming one choice is always correct.
How can I avoid an unwinnable dungeon?
Walk through a complete route with the stated starting resources and check the remaining health after each mandatory event. If every route requires more health than the player can have, change the damage, provide a defined recovery or add a viable alternative. Recheck the result after each change.
What should happen when I revisit a room?
Keep the run's recorded state: a fired one-time trap stays spent, and a defeated guard stays defeated. Decide separately whether other objects reset or remain changed. Restart should restore the initial state explicitly rather than relying on room navigation to reset it.
Finish a short run before expanding it
A connected route, a clear encounter and one limited resource are enough to establish a dungeon-crawling loop. Check the player’s health at each step, then introduce branches, rewards or new enemies one at a time. Develop an original world in the SEELE AI Creator Game Maker and check the result against your rules. For a broader workflow, see how to create a game with AI.
