DunGen - Procedural Dungeon Generation

I have a problem regarding special tile injections. I have two "special rooms" that are configured the following way (see screenshot below). The bossroom2 is always approximately on the right place but bossroom1 generates roughly to the 1/3 of the dungeon's path. I'd like the bossroom1 to be generated at about 1/5 of the dungeons path like I've stated in the special tile injection's properties.

 

Hi! I just had a quick question, where do you instantiate the "Dungeon" object in the code when generating the dungeon. I am unable to find it. Thanks!

 

I've found that the injected tile position tends to be more accurate for longer dungeons. If your dungeon is only 10 tiles long for example, using 0.2 as the path depth means the tile needs to be injected within the first 2 tiles (actually, only the second tile counts since the first is always the start tile and can't have branches).

The issue is made worse if there aren't many tiles that have branches. If no tiles at the current path depth have branches, the injector will wait until there are branches to use.

You could also try reducing the path depth slightly (maybe 0.15-0.2 instead of 0.2-0.2). That might cause the generator to try to inject the tile a room early, giving it a greater chance of finding a valid tile in the first 1/5 of the dungeon.

I instantiate the dungeon root GameObject (if one doesn't already exist) in DungeonGenerator.cs at around line 209.

 

I've tried this with 30 tile long dungeons. Also all of my tiles have 4 doorways that can be used. Still every branch path depth rule tend to work only in the last ~half of the dungeon the expected way. At the first half the branch path depth rules are consistently off. Is there a way to just straight up return a dungeon's main path's length and force the generator to create only one branch containing the desired room at a certain point of the main path?

 

There's no way to have such fine control over branch placement I'm afraid. One thing you could try is to make the tile injector much more strict about where it can spawn the tile. Right now it will attempt to inject the tile after reaching the desired depth and will continue to do so until it succeeds or until the dungeon is complete.

You could modify the behaviour so it only tries to inject the tile up to a certain distance after the desired path depth. For required tiles, this will likely result in more failed generation attempts (you might receive an error saying "Failed to generate the dungeon 20 times"), but you can increase the max failed attempts in the runtime dungeon component. In packaged builds, DunGen ignores that number and will keep trying until it succeeds - the max failed attempts number is just to avoid the editor freezing if you ever make an invalid dungeon that can never succeed.

Here's an example of how you could change the behaviour. In DunGen/Code/InjectedTile.cs around line 37, there's a function that looks like this:

Code (CSharp):

1. public bool ShouldInjectTileAtPoint(bool isOnMainPath, float pathDepth, float branchDepth)
2. {
3.     if (IsOnMainPath != isOnMainPath)
4.         return false;
5.  
6.     if (NormalizedPathDepth > pathDepth)
7.         return false;
8.     else if (isOnMainPath)
9.         return true;
10.  
11.     return NormalizedBranchDepth <= branchDepth;
12. }

Replace it with this instead:

Code (CSharp):

1. public bool ShouldInjectTileAtPoint(bool isOnMainPath, float pathDepth, float branchDepth)
2. {
3.     if (IsOnMainPath != isOnMainPath)
4.         return false;
5.  
6.     // Allow 5% deviation from the expected depth for this tile
7.     const float errorThreshold = 0.05f;
8.  
9.     float minPathDepth = NormalizedPathDepth;
10.     float maxPathDepth = NormalizedPathDepth + errorThreshold;
11.     float minBranchDepth = NormalizedBranchDepth;
12.     float maxBranchDepth = NormalizedBranchDepth + errorThreshold;
13.  
14.     if (pathDepth < minPathDepth || pathDepth > maxPathDepth)
15.         return false;
16.  
17.     // If we're on the main path, there's no branch depth to check
18.     if (IsOnMainPath)
19.         return true;
20.  
21.     if (branchDepth < minBranchDepth || branchDepth > maxBranchDepth)
22.         return false;
23.  
24.     return true;
25. }

This change completely removed the variation in my test project. I was aiming for the same injected tile locations as you (0.2 and 0.9). With the old method I was getting on average 0.28 and 0.90, but after the above change I was getting the expected values of 0.2 and 0.9 on average.

I can't just make this change as-is to DunGen since it's not necessarily the behaviour everyone would want, but I'll be looking into adding it as an optional set of constraints for injected tiles in a future build.

 

Thanks! Will give it a try!

Edit: Everything seems to now work the way I wanted!

 

I keep getting this error on the navmesh script - do you know what's missing/what steps I didn't take?

 

Do you have Unity's NavMesh components package installed? DunGen's navmesh support is built on top of this package because the built-in navmesh doesn't support runtime baking. I thought Unity would have brought the package into the core engine by now, but it still needs to be downloaded separately.

 

The readme on that gtihub states: "This project is now developed as part of the [AI Navigation](https://docs.unity3d.com/Packages/com.unity.ai.navigation@latest) package. Please add that package to your project in order to continue building the NavMesh using these components and to get access to newer versions."

But I guess this does not seem to be the case?

 

Can confirm, copying from the github directly works - the preview package they used to replace it seems to have different namespaces causing broken references

 

Hi is there any significant difference between Doorway socket and Doorway tag ? looks like I can use both for same connection logic between tiles

 

Either can be used for custom connection logic. The only real difference is that you can only have one socket per doorway, but you can have any number of tags.

Doorway sockets are the original method (tags were only added recently), and they're still useful for the simplest connection logic: matching sockets are allowed to connect, mismatched sockets aren't.

 

Hi is there any event for generation complete when i generate dungeon in editor ? im using custom script that i attached on runtime generation for OnGenerationStatusChanged success which works, but is it possible to do it from editor's generate button ? if not, is it possible to implement it for future releases ? thanks

 

I hadn't thought of that. It wasn't possible without modification because the dungeon generator instance used by the window isn't exposed.

I've added a new static OnAnyDungeonGenerationStatusChanged event to the DungeonGenerator class so you can use that in place of OnGenerationStatusChanged and the event will be fired for any generator, even in the editor. Since it's such a small change, I've just pushed it to the asset store under the same version number - so it'll be available whenever Unity approves it.

Edit: The change is available on the asset store now

 

Hi!
I came across an article on level generation in Enter The Gungeon, They also operate in terms of flow, and create different variations of the dungeon. But I personally did before in DunGen only straight levels, no looped moments. Tell me is it possible? If so, could you show an example of such a flow implementation?

Spoiler

 

This can't be done with DunGen currently I'm afraid. The only way to achieve any sort of looping is to set the "Connection Chance" in the dungeon flow settings to 1. This will connect any doorways that coincidentally overlap, but there's no way to control which rooms will be connected.

 

Sorry if I've missed it somewhere within the readme, but is there a way to set a max width/height to the dungeon?

 

The closest thing would be the "Restrict to Bounds" settings on the RuntimeDungeon component. You can use this to create a bounding box for the desired maximum size of the dungeon.

 

I have just purchased DunGen and am having trouble getting the NavMesh baking at runtime working.

I am using Unity 2020.

Importing the Unity NavMesh integration package causes a lot of script errors.

Following the instructions - i installed Unity's navmesh component package from Github since from what i've read this is what the addon is built upon and is still needed even though it's from older versions of Unity.

This removes most of the script errors, however a couple remain and the addon therefore does not function.

 

I assume the error you're seeing is this: "The type or namespace name 'AI' does not exist in the namespace 'Unity'"?

Unity has moved the development to the AI Navigation package - it mentions it on the GitHub page but it's easy to miss. The package is marked experimental, but it's the same code as on the GitHub page so either can be used really.

Frustratingly, the package version is using a different namespace so I can't make my adapter work with both - I added both namespaces hoping it would work, but it looks like it throws errors when using the code from GitHub.

There are two ways to fix the errors:

1. Use the package version of the navmesh components.
2. Remove the superfluous using statements in the scripts. If you double-click on each error it will take you to the problematic line which should look like this: "using Unity.AI.Navigation;". Just delete the whole line. You should then get two more errors for the lines "using Unity.AI.Navigation.Editor;". Delete those too and everything should compile properly.

 

Thanks - i tried the second method and it worked

 

Hello! the "Length Multiplier" isnt very reliable, if i set it to 0.5, its very often no nodes will be generated inbetween the start and goal nodes. Is there a way to specify a set number of nodes instead of a length multiplier?

im wanting to make my dungeons increase in size, each time its generated

 

Sorry for the late reply. One option for setting a specific number of rooms is to modify the dungeon flow settings prior to generating the layout. This needs to be done with care - you'll need to create a copy of the dungeon flow in code (and any other asset you may want to modify) to avoid making permanent changes to the original assets in your project.

I've made an example script here that should help.

 

Hi Aegon-Games!
I have an issue with objects such as guns being culled when moving too far from the room they were spawned in while using BasicRoomCullingCamera.cs.

I see you have a couple of scripts on Github that might help with this but I'm uncertain how to use them.

1. GlobalDungeonObject.cs - do I attach this to any objects that I would like to stay with the player?
2. UnparentGlobalDungeonObjects.cs - do I add this to the Dungeon Generator?

Thanks.

 

Thank you! just so i know whats happening. i keep my `Runtime Dungeon` component in the scene, but disable `Generate on start`. then i use this script to manually generate a dungeon to my liking?

// We make a copy of the dungeon flow before modifying any settings.
// If we just modify the original, we'd permanently change the settings
// on that asset in our project.
// NOTE: This has to be done for any asset we want to modify
// (anything derived from ScriptableObject such as tile sets and archetypes) to avoid changing the original


im not entirely sure what you mean by this? As obviously, i dont want to break the project

So i want to be 100% sure of things if i continue with this change

 

Yes, the GlobalDungeonObject should be attached to any object you want to be pulled out of the dungeon hierarchy. The UnparentGlobalDungeonObjects doesn't need to be attached to your dungeon generator (but that's probably the best place for it) - you just need to make sure the 'Runtime Dungeon' reference is filled in.

Yeah, you'll want to disable 'Generate on Start' and have a script call the 'Generate()' function of the provided script.

If all you want to do is modify the dungeon length, the script can be safely used as is. Once the dungeon flow has been duplicated (like I've done on line 27 of the script), you're good to modify properties of that duplicated asset (named 'modifiedFlow' in my example) without inadvertently changing the version of the dungeon flow in your project files (named 'originalFlow' in my example).

The issue comes when you want to make changes to things like tile sets and archetypes which themselves are also assets in your project. They would need to be duplicated to avoid changing the originals.

 

Wonderful! It works perfectly. I was worried my AI would fall into space if the tiles disappeared but they just carry on Thanks AG.

 

I found a way back a dozen pages back, that we could set Dungen to connect certain doorways to some and not others. This is different from tiles, let's say if I want to connect a certain doorway from a room to a certain tile and block others, but still allow other doorways from the same room to connect to any, what's the new method? It seems like "IsMatchingSocket" method is obsolete, now.

Also, this isn't strictly Dungen related, but a question to one of the smarter gurus out here: While making my dungeon, I noticed that many tiles overlap. Looks wise, it's no too bad, the walls overlap each other perfectly so it doesn't show too many glitches, but I'd still want to know if there's a way to remove any overlapping gameobjects and just keep one of them instead of both. Anyone know a solution for this?

 

You can add your own connection logic to DoorwayPairFinder.CustomConnectionRules. With a custom rule, you can decide whether to allow or deny connections based on either the tiles or doorways involved. Here's an example script that only allows tiles tagged as being 'large' to connect to one-another through a specific large doorway socket. The example script can be attached to any GameObject.

Regarding the overlapping walls, the sample dungeon crawler project has wall meshes that are cut in half so that when rooms get placed back-to-back if creates one full wall. It worked quite well for the sample, but it may not suit the style of your game - and if you're using asset packs they probably won't come with half-walls.

 

Thanks a lot for this, mate. I just need to modify this for my needs and just pop that script up in a doorway gameobject, right?

 

You'll want to put that script on any object outside of your dungeon (I'd usually put it on the dungeon generator, but it doesn't need to go there specifically). If it's placed on a doorway, it'll create a copy of the rule for every instance of the doorway.

 

Hey, is it possible, to add navmesh surface geometry dropdown to UnityNavMeshAdapter.cs (like "LayerMask" or "AddNavMeshLinksBetweenRooms") when doing full dungeon bake, in future update? currently it takes meshes, but I had to edit adapter code to accept colliders. So its not mandatory to re-edit code after DunGen update. Also maybe make "collectable objects" as dropdown too ? just idea, thanks !

 

It's not the most elegant solution, but you can use any NavMeshSurface settings you like by adding your own NavMeshSurface component to the scene and telling the adapter to use that surface instead of automatically generating one.

 

Nevermind, I actally created own script from BaseAdapter.cs

 

Hello,
does anyone have a proper solution to sync the dungeon GameObjects to every client using Mirror networking lib?
I can sync the seed variable and generate an identical dungeon on each client, but it won't work fine because each player would have different GameObjects instances in their game.
How am I supposed to "link" each of them and handle their despawn/movement? (for example items and pickups).

Thanks

 

For room geometry (walls, floors, etc.), it's fine to generate them as different GameObjects on each client.

For objects that need to sync over the network, such as doors and enemies, make them network objects and spawn them only on the server.

 

> such as doors and enemies, make them network objects and spawn them only on the server.

Would it be enough to make a script like that and attach it to these special objects?

Code (CSharp):

1. using Mirror;
2.  
3. public class AutoSpawnNetwork : NetworkBehaviour
4. {
5.     void Start()
6.     {
7.         if (isClient)
8.             return;
9.  
10.         NetworkServer.Spawn(gameObject);
11.     }
12. }

 

It was quite a while ago when I did this, but I think that was the basic idea, except on the client you'll want to destroy the object since the server will spawn a network one.

 

Somehow seems isClient and isServer are both still false

It was harder than this.
I had to code some complex logic since the code above wasn't working for multiple reasons

 

Just curious, but are you saying that the dungeon layout is deterministic (based on the seed) and thus identical on each client, but the decoration of the dungeon isn't?

 

Everything is identical

 

Hello, is there a possibility to randomly generate my seed myself to be able to display it and to be able to choose one to try the same level as your friends ?

 

int seed = Mathf.FloorToInt(UnityEngine.Random.value * int.MaxValue);

 

Once you've got your seed from whatever source you want (using a random number generator as Binary42 said, or asking for input from the player), then you can just pass it into the dungeon generator like this:

Code (CSharp):

1. // Find a reference to the RuntimeDungeon component. This should probably be a property on a component instead of using FindObjectOfType
2. var runtimeDungeon = FindObjectOfType<RuntimeDungeon>();
3. var generator = runtimeDungeon.Generator;
4.  
5. // Get your random seed from somewhere
6. int randomSeed = new System.Random().Next();
7.  
8. // Apply it to the generator
9. generator.Seed = randomSeed;
10. generator.ShouldRandomizeSeed = false;
11.  
12. // Then generate the dungeon
13. generator.Generate();

 

After a day with disappointing results from Dungeon Architect I wonder if DunGen can maybe help me?

I want to generate mazes like Wolfenstein, Dungeon Master, Eye of the Beholder. That means there cannot be corridors next to each other with thin walls. I also don't want each blocked tile to have the same walls on all sides.

Is something like this possible to generate with DunGen?

 

Sorry for the late reply.

DunGen doesn't do traditional mazes very well. There's one main path from the start to the goal, and then any number of branch paths coming off the main path. There's no guaranteed way to make these branches meet back up with the rest of the dungeon to create loops, just an option to connect any doorways that coincidently overlap with another. The result will be one true path through the dungeon with many dead-ends, but the dungeon won't be shaped like a traditional maze - it will probably look more like a tree-shape. It's a maze of sorts, but it might not be what you're looking for.

For avoiding corridors being placed too close to one another, that can be solved either through the design of the rooms or by overriding the bounding boxes to push other tiles away.

In the top image below, a corridor has padding in its bounding box to prevent any other tile from being placed too close. The bottom image shows a room with a doorway that's flush with the wall (left) vs one where the doorway is protruded (right) to avoid other rooms being placed right next to it.



Sorry, I'm not sure what you mean by the last part: "I also don't want each blocked tile to have the same walls on all sides."

 

Hello, was wondering if you could help me a bit.
For some reason, no matter what I do, I end up getting overlaps


This is 2D sprites and I've set up my 3 tile prefabs with doors in correct orientation and such, and I'm manually overloading the tile bounds, though that didn't seem to help.


I've setup the doors like so but sadly have no idea what I'm doing wrong.


Though if I move the doors out "of bounds", like so:




Then it works, but there's the obvious gap in my doors.

 

@Aegon-Games Thanks for the answer. Seems like DunGen is not the right tool for me then.

Regarding "same wall on all four sides": if you take Wolfenstein as an example, and you lay down a tile of wall, it will feature the same texture on all four sides (although two sides are drawn darker they are technically the same texture). For a dungeon crawler like Grimrock, it would be devastating to not be able to specify different textures (meshes) for each side.

 

The doorways should be right on the edge of the tile's bounding box, otherwise you'll get overlaps or gaps. In the screenshots, your doorways are snapped to the grid, but the edge of the sprites don't line-up with that grid.

There are three possible solutions I can think of:

1. Move the doorways to the edge of the tile. They doorway will no longer be snapped to the grid, which will cause your rooms to be misaligned from the grid as well. This might not be a problem for you if you're not going grid-based gameplay.
2. Keep doorway placement the same, but modify the sprites so the edges of the room line up with the grid.
3. Go with your third screenshot where the doorways are out-of-bounds and then make a new sprite that looks like it connects the two doorways, and assign it as a 'Connector' prefab on the doorway component.

I'd recommend either option 1 or 2.

Yeah, I thought it might be the case that DunGen wouldn't be a good fit for your project.

For the sake of completion, here's the answer to your final question:
Since DunGen just pieces together hand-made rooms that you've built, it's completely up to you what you do with the walls. They can all be the same, all be different, or anything in-between.

 

Hello! this might be strange. But, when using dungeon, trigger colliders ect stop registering after going beyond 250 units in any direction. I don't suppose this issue is known and you know what causes it?