AikoNews · Devlogs
From Blueprints to C++: How the Chaos Spire Procedural Dungeon Began
How a room-placement prototype became a deterministic, modular C++ tool for building the Chaos Spire.
01 · From a room to a route
The Blueprint prototype: a route before a map
The Chaos Spire procedural dungeon did not start as a finished feature. It started with a practical question: how can we build a route that changes between runs, can be reproduced with a seed and still works when rooms have different sizes and shapes?
The first stage was built in Blueprints. A room had to receive connections, open only the entrances it needed and keep its contents centred when its size or shape changed.
Before actors were placed in the world, the system built a logical route. Seeds made specific generations repeatable, and the route distinguished Start, Normal, Key and Boss rooms while storing each child room’s parent and creation direction.
The idea that unlocked the system
The system needed to decide what route should exist before it tried to find a valid physical position for every room.
02 · When the route entered the world
Bounds, corridors and real collision problems
Turning the logical graph into rooms that could occupy real space exposed the prototype’s limits. Doors had to align, corridors had to keep the correct direction and a new room could not cut through one that had already been accepted.
Walls appeared on the wrong side, entrances could be inverted, corridors crossed rooms, bounds were too short, actors were generated more than once and room relationships could become incorrect. We also found an overlap-calculation error caused by applying ABS before subtracting the centres.
The solution was to use real bounds and compare every candidate with accepted rooms on all three axes. When a collision occurred, the system could increase corridor length and move the same room before deciding whether it should be rejected.
A procedural dungeon is not only about generating different rooms. It also needs to make problems repeatable, explainable and fixable.
03 · Reproducible testing
From ten rooms to a 150-room stress test
The documented tests reached 10, 15, 20, 50 and 150 rooms. Initial placement was checked with seed 12345 towards North and seed 12346 towards East.
With Max Rooms = 10, one physical generation confirmed 10 normal rooms plus Start, Key and Boss, for a total of 13 rooms in that test.
These checks were not just about making a larger map. They made it possible to reproduce a result, isolate a failure and measure whether a correction preserved the route’s relationships.
What the tests gave us
Seeds and controlled room counts turned procedural generation from a random result into something we could inspect and improve.
04 · The architecture changed
Why the project moved from Blueprints to C++
On August 2, 2026, we made a major decision: close and archive the Blueprint-based Procedural Dungeon V2 and start again with an independent C++ plugin for Unreal Engine 5.4.
This was not about throwing the earlier work away. The Blueprint stage helped us understand bounds, connectors, retries, room relationships and the difference between logical generation and physical placement.
The new DungeonLabPlugin foundation was designed to be reusable, exposed to Blueprints and independent from Caos Entre Reinos combat, UI and inventory. Its first base included requests and results, states, configuration, connectors, multiple bounds, markers, room definitions and weighted selection.
The Blueprint prototype was not discarded knowledge; it became the specification for a more independent foundation.
05 · The current foundation
Dungeon Blueprint Forge 0.10.1
The most recent documented evolution is Dungeon Blueprint Forge 0.10.1. The generator keeps its deterministic and modular base, preserves connections without crossings or overlaps and uses real bounds for Rectangle, L and T rooms.
The visual polish pass added Smart Centered for wall decoration that respects doors and pillars, corrected the HISM material issue, added torches and per-room fill lighting, and introduced procedural corridor lighting.
DungeonBlueprintForgeDoorFrame is placed at the ends of accepted corridors. Unused connections close when generation finishes, and corridor lights are cleared when the dungeon regenerates.
Where it stands
The generator is becoming a modular tool whose technical rules can support a readable playable space, but the documented phase still includes visual validation and world building.
06 · Next build
Consolidate the foundation before expanding the scope
The next checks are to test the result with the project’s real assets, confirm HISM materials in a clean run and prepare a possible early version for itch.io review.
The immediate priorities are to test rooms, decoration, torches, lighting and corridor frames; add fallback between candidate classes when a room definition does not fit; prepare five demonstration rooms; and define the first procedural shell.
Branches, stairs, verticality and multiplayer remain outside the immediate focus. First, the generator needs to explain its route, reproduce its results and provide a stable visual foundation.
The dungeon started as a prototype of connected rooms. It is now the beginning of a modular tool that can grow alongside the Chaos Spire.