DunGen - Procedural Dungeon Generation

I really don't understand, in my case global override doesn't help and the rooms still rotate. Maybe I'm placing the doors wrong somehow. I just put them so that the blue line is looking in the direction of the possible connected rooms

 

I hadn't thought of that, but yeah it could be something to do with the doorway placement.

In addition to the blue line that should be pointing out (which is correct in your image), there's also a green line pointing upwards that unfortunately can't be seen in the 2D view. If some of your doorways are upside-down then it could be flipping your rooms.

 

Thank you for your response, and suggestions.

I have opted to create some extra scripts in order to make it easier to track the doors and enemy AI. I must admit that I found your tutorial to be a "best in class" product, but having 1 or 2 extra page of "how to get/set XYZ" by code would be really useful for the next steps.

Thanks again!

 

Thank you very much. I changed the door rotation and everything worked correctly

 

hello, in the "lock and key" section is there a way to make sure a branch is locked? for secret treasure room. I'm using the 2d version.

and will there be an implementation for alternate path to the end of the dungeon?

 

Unfortunately, it's not possible make sure specific branches are locked with the way the system is currently set up. I've made a note of it as something for me to look into though.

Alternate paths through the dungeon is a tricky one and something I've been thinking about for a long time. The only ways I can think of supporting this feature would involve completely changing the workflow (for example, making it grid-based) so it's just not on the table for now.

 

@Aegon-Games hi, long-time DunGen user here.

I'm working on a new project that uses DunGen and am seeing long generation times for a 10-tile flow (but 0% fail rate) so I have been using the analysis sample scene (thanks for providing that!). Generation is taking 20-40 seconds; I only have one tile injection and no other special constraints.

Your sample assets only take a few seconds to generate but the geometry is very lightweight so maybe tile asset size is an issue.

Can you shed some light on what operations are done during Branch Path Generation? That process is hundreds of times longer than any of the others, even if I have zero branches specified.

Thanks in advance!

 

After investigating, it looks like some extra tasks are being incorrectly attributed to the branch path generation time so it's going to be a little trickier figuring out what's actually causing the slow down. One of the tasks wrongfully included is the final placement of the tile prefabs so it's possible the tile complexity is an issue, but I wouldn't have thought it would take that long just to instantiate prefabs.

I need to look into this some more but hopefully I'll be able to at least provide a new build with more fine-grained analytics to help narrow down the problem.

 

DunGen 2.16 - Download
Available on the Asset Store as of 15 August 2023
Be sure to backup your project before updating to a beta version of DunGen.

Enhancements

• Most lists now support dragging and dropping to add new elements (including archetypes, tile sets, props, and doorway connectors/blockers)
• All lists now support undo/redo when adding or deleting elements
• Prop processing is now significantly faster on complex dungeons with many GameObjects
• (New in Beta 2) Empty GameObject entries in the LocalPropSet or RandomPrefab components will no longer be ignored and can now be used to signal that no prop should be spawned
• (New in Beta 2) Added a validation rule that warns when a terrain is being used in a tile that allows rotation (Unity terrains cannot be rotated)
• (New in Beta 2) Selected doorways are now checked for valid placement in the editor:
  • The doorway will be colour-coded (green = valid, orange = not placed on the edge of the tile, red = not axis-aligned)
  • A red line will be drawn from the doorway to the nearest valid location
  • For doorways that are incorrectly placed, there will be a button in the inspector to attempt to fix the placement issues
• (New in Beta 2) The dungeon validator will now warn when a doorway is not placed on the edge of the tile bounding box
• (New in Beta 2) Unity NavMesh Adapter improvements
  • Added a new option to automatically calculate the start and end points of navigation links per-doorway instead of just using a pre-determined distance on either side of the doorway
  • When using the "Full Dungeon Bake" mode, any existing navmesh surfaces in the dungeons will now be disabled to avoid overlapping navigation meshes
• (New in Beta 4) TileConnectionRule supports a new 'ConnectionDelegate' which contains more information for more complex custom connection rules. The old delegate has been marked as obsolete but will continue to function for now
• (New in Beta 5) Tags are now available on tile and doorway proxy objects for easier access when writing custom connection rules in code

Bug Fixes

• Fixed an issue where too much time was being attributed to the branch generation step. New steps for branch pruning and instantiating tile prefabs have been added for more accurate analysis
• Fixed and issue causing the 'Cull Each Child' option to not work properly with newer versions of SECTR (requires re-exporting SECTR_VIS integration package)
• (New in Beta 2) Fixed a NullReferenceException when using an empty entry in the RandomPrefab component
• (New in Beta 2) Fixed an issue causing the dungeon validator to incorrectly warn about doorways facing the wrong way in a tile containing a terrain
• (New in Beta 3) Fixed an issue causing keys to sometimes not be able to spawn in the same room as the lock
• (New in Beta 3) Key spawn points will now correctly only be used once
• (New in Beta 3) Fixed an issue causing a doorway's 'LockID' to not be assigned
• (New in Beta 5) Fixed a NullReferenceException caused when no valid locks could be found
• (New in Beta 5) Fixed a NullReferenceException when trying to copy tags from a tile that has none assigned
• (New in Beta 5) Fixed a bug causing DunGen to generate too few branches when the branch mode is set to 'Global'

 

The new beta version in the post above has a bug fix that should allow for a more fine-grained look at how long each generation step takes. Post-processing was taking a while on more complex dungeons and I've improved that in the new beta version too.

So far I haven't been able to find any issues that might cause the generation to take 20-40 seconds for a short dungeon, but hopefully the changes should help narrow down the search. I tried making a dungeon with more complex tiles (~2000 objects per room) but it still only took 1-2 seconds for a dungeon with around 20 tiles.

 

DunGen 2.16 won't install.

 

Do you get any error messages when trying to import the package?

 

I'm not sure if these questions have been asked yet.

Is there a way to force specific doorways to spawn something?
i.e. I've got a start tile with three doorways, I would like each door to spawn a branch of their own.

Can I branch with a different tile set or archetype than the main path?
i.e. I would like a branch to spawn in the form of a tower somewhere in the dungeon.

Can I restrict what type of tiles are allowed to spawn from a specific doorway?
i.e. Door 1 = Dungeon, and Door 2 = Castle

 

Unfortunately, these aren't things that can be done with DunGen right now.

For your first example, I imagine you'd actually want multiple main paths rather than simple branches (branches give much less control so they're not really all that useful for gameplay). Outside of a major rework, that's not something that's going to be possible.

Allowing branches to use a different tile set or archetype from the tile that spawned it is an interesting idea and something I'd like to do. I was hoping to just implement it in the next beta version, but after looking into it for a bit it's going to take a lot more work than I first thought.

 

Hi there!

How does one use the doorway tags to accept of refuse doorway connections?

I noticed that the documentation refers to a script on github for more advanced use, but it also seems to refer to the tiles settings (vs. doorways). I would much appreciate your guidance.

 

At the moment, doorway tags are just for custom connection rules in code. I do want to add some settings to the UI for specifying valid tag pairings for doorways similar to what the tile connection rules section of the dungeon flow does for tiles - it could maybe even replace sockets entirely.

For now though, here is a custom connection rule script that will only allow doorways to connect if they match one of the listed valid tag pairings.

 

Thank you very much for your response, and for the script. I look forward to your doorway tag pairing update as well, it would certainly fit nicely with Dungen!

 

Hi there!

I am encountering an issue where my door component is facing forward, but I receive a diagnostic that it not facing forward. This is present in multiple tiles, and was initially working. Upon play, the dungeon is created successfully approximately 9 times out of 10.

Would you be so kind as to confirm if my setting is correct (i.e., it should pass the validator) in the attached picture?
Thanks!

 

That looks right to me. If it's working properly despite the error, it's likely a bug in the validation code itself and shouldn't cause any issues - other than being annoying.

When you say it was initially working, have you updated your version of DunGen lately? I think I re-worked some of the validation code recently and I might have introduced a bug then.

 

Thank you for your response, and I guess it must then be a diagnostic bug. I did not update Dungen (2.15), but I did make a lot of changes in the tiles' child transforms (floor, ceiling, walls at X1 instead of 0.995).

Thanks!

 

Hi, thanks for your great product and support!
I have branches set to generate 1-1 on the global setting which means 1 branch for the entire dungeon. I don't understand why dungen is unable to successfully place 1 branch in the following dungeon image which shows a successful main path where eight of the eight tiles ALL have 4 valid doors, leaving 2 doors per tile free but which failed to generate a branch. That is 16 valid doors but no branch. When generating a branch, does dungen not go to a new valid door and put a branch on it if it fails to generate a branch on the current chosen door?
All tiles in the image below have 4 valid doors, green arrows point to what seems to me to be 16 logical places where 1 branch could be placed but was not. Thanks!

 

I'm using Volumetric lights 2 asset in my project. Volumetric lights 2 uses sphere mesh filter and I noticed that when Dungen builds navmesh sphere shapes gets into navmesh calculations. Is there a way to avoid this? I've tried to put Navmeshmodifier component to the light object with Remove object setting but sphere mesh still gets into the navmesh. Is there a way to for example leave TransparentFX layer out of navmesh? I've not found layer settings in Navmesh adapter. I'm using Unity 2022.3.2f1 and Dungen 2.15.1

** Edit: I got this fixed. I imported Unity NavMesh integration included with Dungen.

 

Hi , one question.

Is there any way to modify the values of the LocalPropSet through a script before the dungeon is generated?

Depending on the difficulty level of the game, I would like to modify the Depth Scale of some props, or totally remove them prom the list.

Thanks!

 

Sorry for the extremely late reply, I didn't realize there were new posts here. Usually I get an email, but I must have forgotten to clear my alerts last time.

I'm not sure if these questions still need answering given how long it's been, but here we go anyway:

After looking into it, I found and fixed a bug causing DunGen to not generate enough branches when using the global branch mode. Hopefully that will fix the issue you've been having. The bug fix is available in DunGen 2.16 which should now be on the Asset Store but if not, can be downloaded from this post.

There isn't a built in way to do that, but you could maybe make your own prop set class that derives from LocalPropSet and override the Process() method to change any properties before processing:

Code (CSharp):

1. public class MyLocalPropSet : LocalPropSet
2. {
3.     public override void Process(RandomStream randomStream, Tile tile)
4.     {
5.         // Override properties here
6.      
7.         base.Process(randomStream, tile);
8.     }
9. }

 

Hi,

I'm enjoying the asset so far! One question though.

is it possible to "snap" the doorway component to doorway entrances? I'm having issues with tiny gaps in-between rooms where the doorway sockets are. What are the best practices around this?

Thanks!

 

There's a new feature in 2.16.0 that might be able to help with that: With a doorway selected - if it isn't on the edge of your tile - there should be a button in the inspector that says 'Fix Doorway Placement' that will snap the doorway exactly to the edge of the tile.

 

Hey,

Thanks for getting back to me. I tried out the feature but it still looks like it's slightly mismatched with my geometry. Although it might be an issue with my setup. I'll do some more tinkering with it this weekend.

 

@Aegon-Games Hey mate. Is there a way to ensure ALL doorways from a certain tile are connected?

 

There's no way to do that right now, but it's been requested a few times so it's definitely something I want to look into.

 

Is it possible to add "checkpoints" in a generated dungeon? That could be used as triggers to save player progress through the dungeon, but also to extend the dungeon (in effect to make it endless)?

Is it also possible to "despawn" or unload parts of, or a whole generated dungeon?

Lets say, for example, that I have three "dungeons" loaded: The previous (where the player came from), the current (where the player is currently passing through), and the next (which the player will enter after the current).

When the player leaves one dungeon, it becomes the previous, while the old previous gets unloaded. The dungeon the player enters becomes the current, and a new dungeon is generated to become the next.

Is something like this possible, to create what is really an endless dungeon runner?

 

In some post-processing we are doing, it is handy to know which tiles are part of which "branch". I have added a BranchId value, where all tiles that are part of the same branch share the same branch id value, to help simplify the grouping/determination of branch tiles. This is in the TilePlacementData class, and set in the GenerateBranchPaths() method of DungeonGenerator. Is this something that could be added to the base project?

 

Unfortunately, this isn't something you can do out of the box right now. There used to be an experimental feature to attach a new dungeon to an existing one, but it was removed some time ago when I optimised the dungeon generator.

Since the generator now spawns proxy objects instead of actual tiles (until it's finalised), it's quite a bit more involved to attach one dungeon to another. Having said that, attaching a new dungeon to the previous one is a feature request that's come up a few times so I'm planning on looking into it further when I have some more time.

Sure, that sounds like good information to have. I'll have it included in the next build.