I am currently working on an RPG game with a procedural generated dungeon, pretty much like described in this article: http://gamedevelopment.tutsplus.com/tutorials/bake-your-own-3d-dungeons-with-procedural-recipes--gamedev-14360
I have implemented this the following way:
- Every room and/or corridor is a blueprint representing the room geometry with a few child actors for torches, chests, crates and so on. Every room has several custom components that function as doorways/exits.
- Upon loading a level, the level blueprint runs the generation code, selecting a room blueprint from a list, selecting an unconnected exit from the existing level geometry and transforming the newly spawned room, so that the selected exit and one of the exits of the new room align correctly, taking existing geometry into account and restarting the process when the new room would collide with an existing one. This processed is repeat a certain number of times until a somewhat acceptable dungeon has been built. I use a custom “spawn into level” blueprint node to add the spawned rooms to the correct streaming level instance so they disappear when the level is unloaded.
- Every level (as in streaming level) represents a single floor of the dungeon and the final exit is a special ‘floor transition blueprint’ which upon activation by the player creates a new instance of the dungeon streaming level, transforms it roughly 2000 units on the negative z-axis and moves the player to the entrance of the new instance, where the whole random generation starts again.
This basically gives me a random dungeon that I can keep going down as long as I want or until I get killed. It works okay, but using blueprints for building a room is a bit cumbersome and has some disadvantages:
- I can only use dynamic lighting. However, some of the rooms would certainly look better if some lighting could be precomputed.
- The blueprint editor is not really suited for working with actors that have rather large number of components. It also does not preview the blueprint with correct dynamic lighting
I was wondering if the whole process can and should be reworked by using a streaming level for each room, creating an instance of the room and transforming it accordingly instead of room blueprints. Would this allow using precomputed lighting? Is transforming and therefore moving/rotating an instanced streaming level possible after it has been loaded, as the placement algorithm I currently use requires it? Is there an option to find all actors that only belong to a specific streaming level instance so I can easily find all exits/doorways of a room? Are there maybe any planned or upcoming changes to the level streaming system that would make this a lot easier to achieve?
I know these are a lot of questions but I was hoping to get some input about how other people might implement this (or already did implement something like this). Of course, changing an already working system is quite some work so the benefits should really be noticeable. I am not afraid of using more C++ code to improve this, however, I would like to avoid making changes to parts of the engine itself.
Any input is appreciated. Thanks in advance!