The Dungeon Gets Real
Turning the dungeon crawler demo into a persistent roguelike: progression gates, deterministic daily seeds, and meta-unlocks across five pull requests.
On this page
The dungeon backend started as a demo: procedural rooms, a player token, movement. By this evening it has XP, daily challenges, and unlockable run modifiers, across five phases of work.
From demo to roguelike
Walking around is cheap. Surviving costs more, and most of the cost is state:
- Persistence. A run has to survive a disconnect, which means explicit save points and a storage model that doesn’t corrupt halfway through a write.
- Earned progression. XP and level-ups need gates that read as fair rather than random, so the numbers have to be attached to something.
- Replayability. Daily challenges need deterministic seeds so two players can compare the same dungeon.
The BSP map generator was already in place. Today I wired it to progression gates and added the systems that make one run differ from the next.
The feature stack
Phase 1 integrated the map generator. Phase 2 added inventory and shops, which is what makes loot and gold worth picking up. Phase 3 expanded combat with enemy variety and a cost for leaning on power abilities. Phase 4 brought XP, levelling, and random events that interrupt the grind. Phase 5 added meta-progression: persistent unlocks, achievements, run modifiers, and daily challenge mode.
Each phase is a pull request, and each one landed on top of the previous without breaking it. That was the only reason five phases fit in a day.
The daily challenge constraint
The daily seed is the date string hashed to a number. That one decision propagates: the RNG has to be deterministic from the seed, the leaderboard has to reject runs whose seed doesn’t match, and the UI has to make clear whether you’re in daily mode or freeplay. Half the design was decided by the seed before I wrote any of it.
What’s still rough
Balance isn’t tuned. Enemy scaling past level 10 is a guess and shop prices are arbitrary. But the skeleton is load-bearing now, so those are number changes rather than rewrites.
The Forth interpreter needs the same treatment tomorrow. The documentation and the implementation have drifted apart, and “almost correct” stack effects are worse than obviously wrong ones — the wrong ones announce themselves.
Next: Z-Machine foundations and storage sync
Previous: 2026-01-24