DunGen - Procedural Dungeon Generation

So, it turns out it was a combination of missing that important detail in the pdf and messing up some level positioning stuff with depth. Thanks for pointing my error out! It was quite helpful.

 

Hello, I have one question that I can't fugure out on my self. (pls help)

Doors in my Dungeon are always duplicating. I mean when one room is connected with another - places two similar door prefabs to my doorway. Therefore, for example, if I need to open it - it opens to both directions.

Is that possible to make only one door prefab appear at the connection point?


Thanks in advance!

 

The Doorway component has two different types of connectors: prefabs and scene objects.

If you're using scene objects, a single object is kept for each doorway component, meaning you'll have one for each side of the door. If you use this type of connector for doors, you'll end up with duplicates.

For prefabs, a single object is kept for the doorway pair - this is the one to use for doors.

 

hi, i have a question: when i generate a dungeon automatically dungen unpack the prefabs, is there a way to keep the prefabs not unpacked?

 

Thanks for implementing the Tag feature. I extended Doorways with their own tags and I have more granular control over the connection rules.

 

I don't think this is possible. I tried replacing the standard Instantiate method call with Unity's PrefabUtility.InstantiatePrefab function (this would only work in-editor), but you can't delete child objects without unpacking the prefab first - so none of the doorway or prop processing will work.

Yeah, tags open up a lot of possibilities. I wish I'd added tags to the doorway component myself in 2.14. I decided not to at the time since - unlike for tiles - there was no dedicated feature that used them, but they're very useful to reference through custom code.

 

I really like what I am reading about DunGen. I have a bucket list item to make a game so tools like this are a godsend. I was wondering how well this system would integrate with the asset Top-down. The attached screenshot shows a list of ways to import a dungeon. Would it be pretty painless to use Top Down as a master handler for most game aspects but DunGen to generate the maps?

Thank you

 

Sorry for the late reply.

I'm not familiar with that asset but I can't see why it wouldn't work. One thing that stood out at me from a quick scan of the documentation is that it says procedural levels should be generated in the Awake() method. DunGen's RuntimeDungeon component has an option to automatically generate the dungeon on start - not awake.

You may need to uncheck that box and make a very simple custom script to generate it in the Awake() method instead, or just rename the existing function in RuntimeDungeon.cs from Start() to Awake().

 

Is it possible to add optional branch paths with the key/lock system?

Having a key that appears in main path, and this key can be used in the optional path/branch?
Cause the keys always appear basically in a linear manner, making it really useless to really have a key/lock system.

 

DunGen 2.15
Available on the Asset Store as of 16 October 2021
Be sure to backup your project before updating to a beta version of DunGen.

Features

• Injected tiles can now optionally have a locked door using the standard Lock & Key system
• [New in Beta 3] The dungeon flow now has an option for pruning branches based on tile tags
  • A tile at the end of a branch will be deleted based on whether it has one of the tags in the "Branch Prune Tags" list in the dungeon flow settings [a second prune mode was added in Beta 6]
    
  • This setting ignores any injected tiles marked as required
• [New in Beta 5] Added a new IDungeonCompleteReceiver interface which can be implemented on any script inside a dungeon to receive a callback when the dungeon generation is complete

Enhancements

• Doorways now have a set of tags that can be used for custom connection logic in code using DoorwayPairFinder.CustomConnectionRules

Bug Fixes

• [New in Beta 2] Doorways connected by the dungeon flow's random connection chance setting should now properly respect custom connection rules
• [New in Beta 4] It should now once again be possible to select a different 'Count Mode' in the local prop set inspector
• [New in Beta 7] Fixed an issue causing changes to sometimes not be saved when modifying the tags on a Tile component

 

Keys can spawn along optional branch paths, but locked doors must appear on the main path. However, I've just put together a quick beta build (above) which supports using locked doors on injected tiles using the built-in lock & key system. I haven't had much time to test it so there could still be bugs, but hopefully this change is enough to support your use-case.

Here's how it works:

1. Injected tile entries in the dungeon flow asset now have a 'Locked' option that can be checked to tell DunGen that you want to the doorway into this tile to be locked. You then select which lock type you want to use
2. In the TileSet asset for your injected tile(s), add a new entry for the locked door prefab you'd like to use
3. Back in the dungeon flow graph, select any line segments or nodes where you want the key to spawn and add a new entry for the key type you set up in the injection settings.

Right now, it's possible that the injected tile will be spawned without a lock if DunGen wasn't able to set it up properly for any reason.

 

Hi, I modified the A* Pathfinding NavMesh Generator script to work with a 2D Grid Graph for my top down game. However I'm having a problem with the scanning of the A* graph. It seems that the dungeon is still being generated when the scanning happens resulting in my dungeon being scanned incorrectly. If I manually scan the dungeon through editor after it has generated, everything works perfectly. Is there some way to know when dungen has finished generating the dungeon?

 

If you've modified the AStarNavMeshAdapter script it should already be processed after the dungeon is complete. The adapters run in a post-processing step that happens after the generation is complete.

Does the built-in script have the same issue for you? I haven't encountered it myself, but I'm still running an older version of A* Pathfinding Project Pro so it might be something that only happens with newer versions.

Another thing worth trying is calling 'Physics.SyncTransforms()' at the beginning of the script. Maybe the physics representation of the world hasn't caught up yet.

 

I can't really test the built in script since recast graphs don't work with 2d sprites. Also 'Physics.SyncTransforms()' didn't seem to fix the issue. The first picture demonstrates how the scan looks when the script is run, second picture shows how it should look (and how the scanning works when I do it manually after loading the dungeon)

 

Do you have "Generate Asynchronously" checked in the runtime dungeon component settings? I modified the navmesh adapter to work with the grid graph, but it only works properly when the dungeon is generated asynchronously.

Presumably it's because DunGen waits for one frame so everything is in their proper place, which it doesn't do when generating synchronously. I'm not sure why that matters for the grid graph but not the recast graph though.

 

I don't, got it working by calling 'AstarPath.active.UpdateGraphs(dungeon.Bounds)' immediately after the scan, don't know exactly why. Gonna check the "Generate Asynchronously" from now on since I guess it's not ideal to scan and immediately update the graph

 

Was wondering how easy it'd be to create a set up like this screenshot showing a dungeon level from Dark Cloud?

This is a set number of rooms always separated by corridors, a random number of chests (orange dots) spawn each level however two of them will always contain a set item. One enemy will always drop a key to exit to the next level. Random number of enemies per level. I know I'd have to create the enemies and chests myself.

Most of the screenshots I've seen from users have rooms connected to rooms without these long corridors so hope that makes sense!




Eager to purchase the asset if you think it'd be possible.

 

Separating rooms with corridors became a lot easier with the newest stable release of DunGen thanks to the new tags feature. You can tag all of your room and corridor tiles appropriately, then in the dungeon flow asset you can set up a rule to only allow tiles tagged 'room' to connect to tiles tagged 'corridor'.

Chests can be placed in the room prefabs as normal and given a global prop component so that DunGen can choose a random number of them to keep, then destroy the rest.

Enemies can be handled in a similar way by placing enemy spawners in the rooms themselves, then you could run some custom logic to spawn the desired number of enemies once the dungeon is finished generating (here's an example of running code after the dungeon is complete).

The lock & key system could be used for the locked exit, but if the door is always at the end it might be easier to just put it in the goal tile manually, then add the key to the inventory of a random enemy as you spawn them.

Hope that helps.

 

I used a similar asset, but I had to give it up because it didn't have the feature that the corridors were always connected to the rooms. That is, so that the corridors are never the end of the graph.

Is it possible to make this asset so that the corridors are ALWAYS connected from BOTH ends to the rooms. Because I read the documentation and didn't understand if this feature is available or not.

 

This wasn't possible, but I've been planning a feature to allow tiles at the end of branches to be pruned if they have a specific tag. After reading your post I decided to quickly implement it into the current beta build (see this post).

So now with the new beta version it's possible to tag your corridor tiles appropriately and tell DunGen to prune any tile that appears at the end of a branch and has your 'Corridor' tag. The only other places dead ends can appear are the start and goal nodes, but you can explicitly tell DunGen what tiles to use there.

I hope this helps.

 

For some reason the Local Prop Set doesn't seem to work on my 2D project. I have added the local prop set script to an empty game object on my tile and I added the spawnable objects of the tile to the prop weights list. The count field doesn't work. All of the objects are spawned every time the game generates the dungeon. Also the count mode can't be changed for some reason. I'll add a picture of my setup just in case I've done something the wrong way. I'm using the latest version of dungen

 

Hi I have question regarding seed, does seed number contains info also regarding all random prefabs and local props generated ? For example if I use particular seed it will load everything including props inside tiles everytime? Or the seed will generate same tiles but props and prefabs are still randomized regardsless seed ? Thanks

 

Not being able to change the count mode was a bug I must have introduced recently. I've fixed it in the beta version, but it can be fixed manually if you prefer by simply deleting the line "if (GUI.changed)" at line 86 in "Dungen/Code/Editor/Inspectors/LocalPropSetInspector.cs".

I don't see anything wrong with the way things are set up in your screenshot. I tested a setup just like yours in the 2D sample but it worked as expected, so I'm not sure what the issue is. Did you get any errors in the console at all?

The seed affects everything including all the props, so the dungeon should be completely identical each time you generate with the same seed.

 

Didn't get any errors but when I removed my mirror script which handles spawning the same objects for every instance of the game everything seemed to work, so the problem lies either in my spawner script or in the way that mirror syncs spawns

[Edit] the problem was solved by calling the spawn method on 'Awake()' instead of the 'Start()'

 

[Edit2] 'Awake()' had few problems, fixed by setting 'Start()' as IEnumerator and waiting for a while before spawning the objects from the spawners. I suppose this works because dungen needs some time to remove(?) the unwanted objects (pls correct me if I'm wrong) and by default the spawners 'Start()' method runs instantly giving dungen no time to remove the unwanted spawners

 

Yeah, that's pretty much what the problem is. Start() and Awake() are called as soon as the tiles are placed, which means they run before DunGen has a chance to do the post-processing steps (including handling props). Annoyingly, Start() and Awake() are called after the dungeon is complete if it's generated synchronously.

Usually for things that need to happen after the dungeon is finished, I'd recommend listening for the OnGenerationStatusChanged event and running your code there (like in this example). But that's kind of a pain when you want to run code on an object inside the dungeon, so I've just added an interface in a new beta version that can be implemented on any custom script to let them receive a callback when the dungeon generation is complete. Here's an example of how it could be used.

I hope this helps.

 

HI,
I was trying create multiple dungeon stacking at Y axis for multiple players, however, the nav mesh surface will removed from the last one and generated on the latest one, I am using Full Dungeon Bake, is it possible to keep the navmesh surface even after detached ? Thanks

 

I removed the clear lines in the navmesh adapter and seems work fine, would it be any other approach?

 

That's probably the best way to do it.

 

I think I found a bug in the newest dungen beta. When I clicked to inject special tile in the dungeon flow asset the whole dungeon flow component got messed up and broke with many errors.

 

Thanks. The issue was happening when no key manager was assigned. I've fixed the error in the new beta build - it will now just disable the open to lock injected tiles if there's no key manager assigned to the dungeon flow.

 

Are there any gotchas to be aware of regarding seeds?

I've recently tweaked some tile weights and removed a few tiles completely from a set, as well as removing all constraints on the Runtime component. Now a given seed seems to spawn a different layout between the editor and standalone builds where they used to match. Have tried clearing the library etc.

Unity 2020.3.17, DunGen 2.14, MacOS Standalone.

As a test I tried printing in a post-processing step from the RandomStream like so:

Debug.Log("Post processing with random stream " + generator.RandomStream.Next());

For a given seed (say 372029386) this is 100% consistent in editor (1526331658), and 100% consistent in the build but different to the editor (548227321).

It might be that this is broken since upgrading to DunGen 2.14.

 

I haven't been able to reproduce the issue unfortunately. I've tested it with the editor and all four different standalone configurations (development vs non-development and x86 vs x86_x64) and each time it produced identical results for the basic sample scene and output the same number when I printed the next random number to the log.

I did only test this on windows though so it may be a MacOS exclusive issue, but I don't have a mac to test it on.

I know the built-in random number generator isn't guaranteed to produce consistent results across all the various .NET and mono versions Unity might use, but since DunGen 2.13.3, I'm using a custom RandomStream class that doesn't change based on what platform it's running on.


Also, just to be sure about the changes you mentioned making: you're testing with the changes having been made for both the editor and standalone build right? Basically any change to the settings of a dungeon that involve randomness (including tile sets, weights, etc) will change the resulting dungeon given the same seed. So if the editor build has some tiles removed that are present in the standalone build, you should expect the dungeons to be different too.

 

Thanks for the response- I’m definitely checking a stand-alone that matches the editor updates (has been built after tweaks), and without any expectation it should match dungeons from before I tweaked weights.

There was consistency between editor and builds very recently so I’ve probably done something somewhere, I just can’t think what. I’ll keep digging when I have a chance.

 

Yeah, it's hard for me to understand how the editor generated version can be different from the build generated version.

Wouldn't there have to be a difference in an editor script?

 

It's definitely the RandomStream, the tilesets are correct but clearly generating from different random values for the same seed, debug logs confirm this. The only other changes in my project since it was last consistent would have been updating the Editor version from Unity 2020.3.16 to Unity 2020.3.17. Just tested with the latest DunGen beta above.

 

I've reverted changes to well before the latest round of tweaking, so the dungeon assets are as they were when they were last consistent between editor and build. Looking at the Git history, I must have updated to DunGen 2.14 back in July, so I don't think that's the culprit. However, the inconsistency appears when I load/build that older project state in Unity 2020.3.17. I can't see anything in the release notes that might account for the problem.

As far as I can tell, the dungeons in the editor and build start off matching for 5 or 6 tiles, but over the distance something goes awry and they end up differing. I've tested this in a completely stripped-back scene with no dungeon post processing and it still happens.

 

The only change I can think of that's related to the random number generator is when I swapped it out completely, but that was back in 2.13.3 and it was actually done to make the results consistent across platforms.

It's strange that it seems to start off matching and deviates over time. The previous result of the random number generator is used to generate the next one, so if anything I'd expect it to be completely different even for the first few tiles.

Could you try running a script like this one in the editor and standalone builds and see if the numbers printed to the screen match? If they don't match, it's definitely a problem with the random number generator. By default it generates 10 numbers, but you might need to increase that if the random number generator does actually start in sync between editor and standalone.

For reference, when I run the script I get these results: 7, 8, 7, 5, 2, 5, 9, 4, 9, 2

 

I ran the generator script and it was matching at 50 numbers long (and matched your initial numbers).

Still have similar-but-different layouts. I went over the tiles carefully, and removed all the vertical doorways, which although working threw errors in the validation output. Are vertical doorways (ie upwards/downwards facing) supported?

From testing a couple of seeds, a few layouts matched but most don't. It looks like the divergence always happens on branches rather than the main line.

 

They are, I just didn't think about them when I wrote the doorway validator code. Those errors can safely be ignored.

 

What is the best way to search through all the tiles for spawners gameObject ? I was thinking of adding a script "spawnList" to each tile then cycle through all the tiles and spawn the object(s) on the list.

 

If you just want to call a function on every instance of your spawner script in the dungeon, I would use GetComponentsInChildren. It's recursive so you'd call it on the root gameobject of the dungeon and it would find all instances of your component. Here's an example of a script that you'd put in the scene with your dungeon generator.

If you're using the beta version, there's also the new IDungeonCompleteReceiver interface which is even easier. Just implement the interface in your spawner script and the OnDungeonComplete function will be called automatically whenever the dungeon is finished. Here's an example.

 

Where do you control the dungeon creating when hitting play unchecking the box does not work. Thanks for very fast response !

 

Unchecking "Generate on Start" on the runtime dungeon component will stop it from generating the dungeon automatically. The basic sample scene uses a custom 'Generator' script that generates the dungeon in its start method so you'll want to make sure you don't have that script attached.

 

Ahh okay thanks !

 

Using the Basic example, trying to move the player to the SpawnPosition in the Starting Room, I cycle through the tiles and get the position but the player gameobject will not move, is its position controlled somewhere ?

 

The player in the basic sample is moved to a hard-coded position when the dungeon is generated (see 'DunGen/Samples/Basic/Scripts/PlayerController.cs' line 61) though it would be best to use your own player controller script anyway since that one is made for the example scene - it contains some code specific to the sample like toggling between the two cameras.

 

Awesome thanks very much ! This is a great controller for testing and I added a test mode so will wrap that code. Very cool asset.

 

How do I change the starting location position so the entire dungeon can be at a specific location ?
I tried changing the root but that seems to just be the spawn folder.

I was also wondering if I could load the tile sets at runtime. Example have a Boss, Start and Rooms and load the type of dungeon from my assetBundle into each all the rest is aways the same Dungeon Flow etc.

 

Setting the 'Root' gameobject property in the Runtime Dungeon component settings should work. The dungeon is generated with the start tile at the local origin of the root gameobject, so moving that root object around should cause the dungeon to be generated at its location.

It's possible to programmatically change the dungeon flow settings at runtime, but you'll want to be careful to make sure to use the Instantiate() method to create runtime copies of any assets you want to change the settings of (DungeonFlow, TileSet, Archetype, etc), otherwise you'll be changing the assets in your actual project files. Here's an example script for swapping the tile sets used for the start room.