Dungeon Protocol began as a game idea, but its real challenge is systems coordination. A procedural run touches dungeon topology, door traversal, room state, combat, AI, loot, upgrades, UI, persistence, and end-of-run outcomes. Treating those pieces as an engineering system makes the project easier to reason about and safer to extend.
Run state is the connective tissue
The generated dungeon graph is not only a layout. It determines room progression, when doors can transition, what the minimap can reveal, when a combat room is complete, and which cleanup work must happen before the next state begins. Explicit room and run state prevents visual transitions from becoming the source of truth.
- ›Procedural dungeon graph and randomized room progression
- ›Door traversal and room-assignment safeguards
- ›Minimap and room-state tracking
- ›Combat-room completion and enemy cleanup
- ›Upgrade, victory, and defeat transitions
AI is behavior, timing, and ownership
Enemy variety comes from more than changing movement speed. Archer strafing and projectile leading, kiting, flanking, melee commitment, defensive decisions, telegraph locking, fakeouts, and boss phases all depend on carefully defined ownership and timing. The Iron Warden adds charge behavior, phase-two changes, and environmental positioning around pillars.
Testing the boundaries between frames
The suite grew from dozens of tests to more than 600 because the hardest failures happened where systems met: doors and room assignment, upgrade overlays and pause state, projectile motion and collision, telegraph ownership, or objects disposed across frames. Validation combines dotnet build, Godot headless imports, automated gameplay and system tests, and smoke tests.
💡 The test suite is concentrated at system boundaries: room transitions, UI overlays, collision, telegraphs, and cross-frame object lifetimes.