Adding my 2c.
All in all, all top down RGN systems work similarly if not exactly the same.
if you need it to spawn as you go, completely randomly. The blueprint example is ideal. Clockwork can expand on that, works great in his game.
If you need to pre-generate something then things are a little different.
First you make the levels. Then you make a persistent work, in which all the levels can be loaded.
at runtime, the persistent will take care of spawning the levels in a random position based on some algorithm or method you define.
In top down, you can imagine each sub level as a box.
Let’s say you have an area of 10x10, which gets filled in randomly by the levels you created.
Let’s say you always have an entry level, and an exit level (Diablo style ladder rooms? Something similar anyway).
In the 10x10 box system you run some algorithm that defines where the entry point and the exit point end up.
Keep it simple, but also make sure that there is some margin between the entry and exit points - say a distance of 3 boxes minimum. If the random points picked are within that distance you just pick a different point randomly again.
This creates a generally decent entry/exit point that forces the player to stroll the level a bit.
Now that you have the 2 spots defined you need to cut a way to it.
tons of ways this can happen.
it could be as simple as removing a box in one of the cardinal directions and replacing it with a level.
level.
each level will likely be built with an entry and exit (or several exists). Depending on those, the automated system will test and remove the appropriate adjacent box /and or, choose another random level to test.
(Because if you are at 10x10 and you pick a level that would lead into 10x11 you just made something that’s not valid).
This is usually all built to happen by numbers or with a multidimensional array, so levels can always be memorized and reconstructed at all times by feeding in the correct sequence.
moreover, the calculations and determinations even when recursive are usually near instant - and the loading of the levels, when using the persistent, is usually done by distance but manually (since no levels are actually placed like you normally would for tiled landscapes).
As such, it doesn’t make much of a difference which method you use. Whether a “box” is a level you can stream in, or a blueprint you can load in.
I would use individual levels for ease of use. You can customize lights and all sorts of other things within them making each dungeon room truly unique looking. they can also all support their own level BP code, which although not necessary and usually not something you want since you should handle checks of things via proper OOP it can still be useful for things like enemy respawns, or running timers.
