What is the way to programatically change the Goal of the dungeon?
My use case is that my dungeon will have an exit tile with some portals to advance to the next level, but every X levels that exit portal room must change to a boss room. I looked at injecting tiles but I think that won’t work, since the original Goal will remain the same.
The easiest solution is to just have two dungeon flow assets and to swap them out based on what level the player is on, but that does come with the development overhead of maintaining two near-identical dungeon flows.
You could also programmatically duplicate and modify your existing dungeon flow asset at runtime. Care needs to be taken when doing this as the DungeonFlow asset - as well as many of the child objects like TileSets - are ScriptableObjects and any runtime modification to these will make permanent changes to your project. Always make changes to duplicates of any ScriptableObject.
Here’s an example script that takes an original dungeon flow asset and modifies it to use a different TileSet. It then stores the new DungeonFlow asset inside the ‘BossRoomFlow’ variable so you can swap it into the runtime dungeon component whenever you like:
var runtimeDungeon = FindObjectOfType<RuntimeDungeon>();
runtimeDungeon.Generator.DungeonFlow = BossRoomFlow;
I see that setting the dungeon length affects only the main path length, when setting branch count and depth these are not taken into account when calculating the length.
Is there a way to specify a number, say 20, with an arbitrary depth and branch count and at the end of the day always get 20 rooms including the branches?
I there a way to specify the branch depth for a Global branching type. You can specify branch count but not depth.
Hi, what do you think about a feature to generate x number of valid dungeons and store the seeds as valid so everytime it will use one of those ensuring the dungeon will be generated? With this, the failed generation error could be erradicated.
It’s something I’ve considered before, but it would drastically reduce the number dungeons the player could encounter unless you ran the system with a lot of potential seeds. It would also need to be re-run any time a change is made that can affect the dungeon layout.
Fortunately, the failed generation error only happens in the editor (to avoid running into an infinite loop if the dungeon is configured incorrectly). In a packaged build, DunGen will just keep trying until it succeeds.
Is that a new feature? I remember seeing in the player logs failed to create the dungeon in xx Times.
I have another feature, the possibility to bake XX number of dungeons. User will define a name for the filenames so the script will create a dungeon in the editor and save in the desired folder/name. One click solution could be pressed when creating master builds (not testing). Baked dungeon are already created and loading much faster (also running with umbra occlusion) Right now, loading times are brutal for mid size dungeons or dungeons with complex rooms.
Unlimited retries in a packaged build isn’t a new feature. I’m not sure exactly when it was introduced, but it goes back at least as far as DunGen 2.6
Since both of your feature requests involve avoiding costly dungeon generation, they may not be needed once I’ve done the performance optimizations I have planned for 2.18. For now, I’ve made a note of the features and I’ll re-evaluate once I know how far I can push the performance.
Hi, I have a dungeon flow with 4 nodes and I was wondering if there was way to control the weight of each node, so I could make the rooms of one node more prominent than others
Sorry, I’m not sure what you mean by making the rooms of one node more prominent.
Do you mean assigning a different weight to each TileSet in a node so you can re-use TileSets across multiple nodes, but have the node itself be able to adjust the likelihood that a specific TileSet is chosen? Basically, like adding a ‘Weight’ field to each TileSet in the list here:
I was wondering if it was possible to limit the tiles spawned for each node. For example, could I make “OPEN_NODE” spawn a single tile? (“Start”, “OPEN_NODE” and “CONNECTION_TO_INT” they all can connect with each other, and the same goes for “CONNECTION_TO_INT”, “MIDDLE2” and “GOAL”).
It’s not currently possible to make nodes connect to one-another like that. DunGen tries to place tiles spawned by nodes at the appropriate percentage along the path. In your example, the tiles would be spawned roughly at these percentages:
The gap between them would be filled with tiles from the line segment (the white bar drawn on top across the whole graph).
You could maybe get the nodes to connect by moving them very close together (so they overlap almost completely in the dungeon flow), but unfortunately it just wasn’t originally designed with that type of precision in mind.
Actually, yeah. If you just remove the nodes altogether and just use a single archetype containing all the tiles, you could assign each tile a tag (“Start”, “OPEN_NODE”, etc). In the dungeon flow settings, you could then set up some tile connection rules to only allow tiles with compatible tags to connect to each another (e.g. tag pairs for “Start” + “OPEN_NODE”, “OPEN_NODE” + “CONNECTION_TO_INT”, etc).
Note that the dungeon length would need to be set to the exact right size to accommodate only the tiles you want. If the rules are set up in such a way that only those exact 5 tiles can be strung together, but the dungeon length says it should be 6+ tiles long, it will result in failure every time.
Using the tile connection rules on the dungeon flow is a bit limited. If you need more control, you’d want to use a custom tile connection rule like in this example