DunGen - Procedural Dungeon Generation

Current Version (Asset Store): 2.15.1
Current Version (Beta): 2.16

DunGen is a Unity editor extension that lets you generate procedural dungeon layouts at runtime quickly and easily, with no programming required.

The extension uses a room-based approach that allows you to design and create segments of a level as you usually would inside unity. Simply create a prefab that represents a "room" in your dungeon, specify doorway positions, and let DunGen generate your random dungeons.

With an easy-to-use graph-based interface, you can control the flow of your dungeon, placing specific rooms, or varying the type of dungeon that is placed along the main path.

DunGen also provides several options for randomising props that appear in your dungeon, all fully customizable with user-defined weights and limits. DunGen is designed to satisfy as many requirements as possible without encroaching in "game-specific" territory. The full source-code is also available for if you need additional, specific features or adjustments.

Buy DunGen on the Asset Store​

The latest beta version (if there is one) can always be found here.




Features:

• Design each room as you would any other scene, assign doorways and watch DunGen piece them together
• Full control over dungeon settings: length, branching factor and weights for each room type
• Supports multiple doorway shapes/sizes and only connects doorways that match
• Supports multi-floor setups with no additional work. Just place doorways where they should be and DunGen handles the rest
• Procedural doesn't mean everything has to be completely random. Control the flow of your dungeon with an easy-to-use graph interface
• Local Prop Sets: Specify which objects (and how many) appear on a per-room basis
• Random Prop: A list of prefabs of which one is chosen at random to be spawned at the current position
• Global Prop Limits: Limit the number of props allowed on a per-dungeon basis
• Everything has a complex "weight" so you can control how likely it is (and where it is most likely) for certain objects to appear
• Support for SECTR VIS portal culling
• Lock Key system allows you to place locked doorways and matching keys throughout the dungeon layout (requires some programming to integrate with your own game)
• Full source code included

Things to consider before purchasing:

• There are some restrictions on where doors can be placed depending on the room shape. Explained on pages 3 & 4 of the readme file.

More information is available on the Asset Store page.
I'll try to answer any questions in this thread as quickly as possible. Support is also available by e-mail (please include your invoice number unless you're asking a pre-purchase question).

Links
Asset Store
E-mail Support (please include your invoice number unless you're asking pre-purchase questions)
Documentation
FAQ


Changelog:

Spoiler: Changelog

2.13.1
BUG FIXES
- Removed deprecated components from sample scenes to avoid warnings in Unity 2020.1
- The 'Adjacent Room Culling (Multi-Camera)' component should now work when using scriptable render pipelines, provided the project is Unity 2019.1 or higher
- The 'Adjacent Room Culling' component (non-multi-camera) now also has a 'Target Override' property to match its multi-camera counterpart, allowing it to be used in games where you want to cull around the character, not the camera (e.g. third-person or 2D)
- Fixed an issue in the Dungeon Crawler Sample that caused the NavMesh to persist between scenes
- Fixed an issue with SECTR portal culling integration that caused rooms to not be culled initially when 'Multi Camera Culling' was turned off
- Fixed an issue causing 'Doorway Connection Chance' to do nothing

2.13.0
ENHANCEMENTS
- Tiles prefabs are now only instantiated after the entire dungeon layout is generated, resulting in much faster generation times
- Local Prop Set and Random Prefab props can now be nested properly. Global props should still not have other props nested inside them, but can be nested inside others.
- Archetypes can now be be marked as unique. DunGen will try to ensure that unique archetypes are only used once throughout the dungeon.
- When using the 'Full Dungeon Bake' mode with the built-in Unity NavMesh adapter, it's now possible to use your own surfaces for more control over settings by unchecking the 'Auto-Generate Surfaces' checkbox.
0 The Door component now contains a 'DontCullBehind' property to allow doors to be closed without culling rooms behind it. This works for the built-in culling and the SECTR VIS integration
- Doorway connector & blocker prefabs can now all be assigned weights for more control over how frequently certain objects spawn

BUG FIXES
- Local prop sets now correctly work with objects attached to door connectors & blockers
- The SECTR VIS integration will no longer throw an error if a door already has a SECTR_MEMBER component

2.12.0
FEATURES
- Dungeon Crawler Sample (Extract from "DunGen/Samples/DungeonCrawler.unitypackage"). Requires Unity 2019.1 or higher
- Doorway sockets are no longer hard-coded and are instead assets that can be added without modifying DunGen's source code
> Doorway size is now part of the new DoorwaySocket asset instead of being applied to each doorway instance
- Doorway socket connection logic can be overridden by providing your own function to DoorwaySocket.CustomSocketConnectionDelegate
- Added a new constraint in generator settings to enforce a minimum padding distance between unconnected tiles
- Added a new constraint in generator settings to disallow overhangs (so rooms cannot spawn above other rooms)

ENHANCEMENTS
- Door prefabs are now parented to their doorway objects, rather than the dungeon root
- Added a new icon for doorways
- The maximum overlap between two connected tiles can be tweaked in the dungeon generator settings
- Simplified up-vector selection
- If no socket is specified for an entry in a TileSet's locked door prefab list, the locked door can be assigned to any socket

BUG FIXES
- Assigning a prefab to a key is now optional
- Disabled doorways are no longer considered when connecting tiles together or when calculating tile bounds

2.11.9
FEATURES
- Added a new built-in culling component "AdjacentRoomCulling"
- Added "Full Dungeon Bake" mode to Unity NavMesh integration which allows the entire dungeon to be baked as a single surface when generated

ENHANCEMENTS
- Improvements to built-in basic culling camera
> Improved performance by ~60% (3.19ms -> 1.29ms in test case)
> Now optionally supports culling light sources
> Now supports culling doors
- Some improved inspector tooltips

2.11.8
FEATURES
- Added an option to override the global "Doorway Connection Chance" on a per-tile basis
- Added an option to restrict connecting overlapping doorways to only tiles that occupy the same segment of the dungeon flow graph. This should help to prevent unintended shortcuts from appearing when this feature is used

ENHANCEMENTS
- The documentation has been updated to include some recent features which had mistakenly been omitted. The documentation also includes a previously missing step when setting up the Lock & Key system
- An error is now logged whenever a tiles automatically calculated bounds are invalid (have a negative or zero size)

BUG FIXES
- Automatic bounds calculation should now work properly with newer versions of ProBuilder

2.11.7
FEATURES
- A more comprehensive validation tool has been added to help find any errors when setting up a dungeon. This can be accessed using the "Validate" button in the DungeonFlow asset inspector
- Added a 'Branch Mode' option to the dungeon flow allowing users to optionally specify the number of branches that should appear globally across the entire dungeon, rather than locally per-tile

ENHANCEMENTS
- BasicRoomCullingCamera now has an option to also cull in the editor scene view
- Improved performance of BasicRoomCullingCamera in scenes with a lot of renderers
- Foldout labels can now be clicked to expand the foldout
- The old dungeon validation is now only run inside the editor for a minor performance improvement in packaged builds
- Doorways now also draw their expected up-vector to make it clearer which way they should be facing
- Adapters (such as integration for SECTR VIS and Unity's NavMesh) will no longer fail silently if attached to a GameObject without a RuntimeDungeon component
- Creating a new DunGen asset will now allow the user to specify a file name
- Some improvements for the DungeonFlow inspector

2.11.6
BUGFIXES
- Fixed an issue preventing the dungeon generating from working until the scene/editor is restarted after finding an issue with the dungeon layout
- SECTR VIS integration will now correctly use the already calculated tile bounds instead of its own. This should prevent any gaps from forming between sectors (resulting in incorrect culling)
- Fixed an issue causing some DunGen components to not save correctly when edited in the new prefab editor in Unity 2018.3
- Undo/redo should now work consistently

CHANGES
- Most DunGen components now support editing multiple selected objects
- All inspector lists are now re-orderable
- Added some in-editor tooltips to properties that didn't already have them
- The Tile and RuntimeDungeon components now also allow for editing bounds in the scene view
- There is now the option to disallow any tile repetition. This can be done on a per-tile basis or overridden globally in the dungeon generator

2.11.5
BUGFIXES
- Fixed an issue preventing the basic culling camera from culling rooms behind a closed door
- The Basic Culling Camera will now no longer incorrectly refresh the visible set of tiles every frame - this could increase performance greatly
- Fixed an issue causing the integrated basic culling to not work if the camera was spawned through code

CHANGES
- Updated to work with the new prefab system in Unity 2018.3
- [BREAKING CHANGE] A* Pathfinding Project Pro integration updated to version 4.0+. If you're using an older version, you'll need to add ASTAR_PATHFINDING_VERSION_3 to your "Scripting Define Symbols" in the Unity project settings
- Moved demo scripts to their own namespace to avoid naming conflicts
- Small update to the 2D demo scene to include a controllable player character

2.11.4
BUGFIXES
- The start tile should now correctly respect the transform of its root game object
- The integration for A* Pathfinding Project Pro should work correctly in Unity 5 or higher
- Off-mesh links produced for Unity's NavMesh system will now take the agent's radius into account

2.11.3
CHANGES
- Auto-calculated bounds should now ignore particle systems

BUGFIXES
- Large tiles should no longer overlap a small amount
- The per-tile "Allow Rotation" and "Allow Immediate Repeats" options should work correctly again
- DunGen now supports setting Physics.autoSyncTransforms (new in Unity 2017.2) to false
- Lock & key placement should now correctly be done after props are processed

2.11.2
CHANGES
- The "Basic Room Culling Camera" component can now optionally be provided with a TargetOverride transform for third-person games
- The ArchetypeValidator will now report a warning when a TileSet contains an entry with an unassigned tile and will no longer throw an unhandled exception

BUGFIXES
- Tiles will now correctly never appear in the dungeon layout when they have a tile weight of zero

2.11.1
FEATURES
- Tiles can now optionally designate entrance and exit doorways (available by manually adding a Tile component to your tile)

CHANGES
- Door prefabs will now always take on the transform of the Doorway that spawned it
- "Allow Immediate Repeats" now defaults to true to avoid confusion when testing DunGen with a setup that has only one tile. It's still possible to override this behaviour both globally and on a per-tile basis
- The DungeonGenerator class has a new "Retrying" event that is fired whenever DunGen has to retry the entire dungeon layout

BUGFIXES
- JIT errors should no longer be thrown on platforms that require AoT compilation (such as Xbox One & iOS)
- Fixed an error preventing use of the PlayMaker integration
- Fixed a rare issue that caused rooms with vertical doorways to sometimes be flipped upside-down
- Fixed an issue that caused the dungeon generator to incorrectly revisit certain statuses (Branching, PostProcessing, Complete), thus making multiple calls to the OnGenerationStatusChanged event
- Fixed multiple errors with the dungeon flow editor window
- Fixed an OutOfMemoryException that could occur when a tile had a weight of zero

2.11.0
- Added API to DungeonGenerator for registering post-process callbacks: RegisterPostProcessStep() & UnregisterPostProcessStep()
> Callbacks are invoked during DunGen's Post-Process step in order of phase (before or after built-in post-processing), then priority (highest to lowest)
> The base NavMeshAdapter class has been changed to use this method to ensure that the NavMesh is build before DunGen reports that the generation is complete when using the OnGenerationStatusChanged event
- Added an adapter for Unity's new NavMesh system (5.6 beta)
- Added an adapter for built-in simple culling for use in interior first-person games; works best with auto-closing doors on each doorway
- Dungeon generation can now be performed asynchronously so as to avoid blocking Unity's main thread, allowing for things like animated loading screens to play while the dungeon is being generated
> There are some new settings for runtime dungeons to control this behaviour
> The new "Pause Between Rooms" settings allows you to pause the generation for a number of seconds after a room is placed to visualise the generation process

CHANGES
- Drastically changed the way DunGen appends tiles internally - it should now generate faster most of the time and practically never fail
- Culling adapters now use the same method as NavMesh adapters, they are added as components to the GameObject containing the RuntimeDungeon; moved culling code out of DungeonGenerator class
- Documentation has been completely re-written to be more modular, easier to follow, and to include features that may have been skipped over in previous versions. The documentation is now front-loaded with information to get started quickly, more advanced topics come later
- Improved the inspector for the Doorway component & changed some of the terminology; it should be much easier to understand now
- The option to use the legacy weighting system has been removed, there was no reason to use it and it's no longer possible with the new generation method anyway
- Added tooltips to all dungeon generator settings
- Code Cleanup
> Removed experimental GenerateAppended() method. It was never fully supported and never would have been
> Removed orphaned code for dungeon analysis window. RuntimeAnalyzer has always been the way to analyse dungeon generation
> Removed code used to generate a main path without allowing backtracking - it wasn't even exposed as an option and allowing backtracking is objectively better
> Removed visibility code from the base Tile class; visibility should be handled by culling adapters
> Removed TypeUtil & AnalysisWindow

BUGFIXES
- Fixed an issue with the generation failing due to not finding matching doorways in a tile when using a custom IsMatchingSocket() method
- Disallowing repeated tiles should now work as intended and will now also consider branches
- Fixed a collision issue when using manually overriden tile bounds
- Fixed an issue with injected tiles on the main path marked as "required" not appearing occasionally
- Unused tiles deleted during the generation process should no longer contribute to the NavMesh when generating synchronously

2.10.0
- Fixed an issue with the 2D demo scene which caused tiles to overlap
- "Ignore Sprite Bounds" in the dungeon generation settings is now unchecked by default
- Doorways now have a priority for deciding which doorway's "Door Prefab" should be chosen
- Added an option to specify which layer the tile trigger volume is placed on (Defaults to "Ignore Raycasts", only effective if "Place Tile Triggers" is checked)
- "Avoid Door Prefab Rotation?" for doorways should now be set properly
- Door prefabs should now always be cleaned up correctly
- Auto-placed trigger volumes for tiles no longer sometimes have negative sizes
- Fixed an issue with the SECTR VIS integration that was causing door states to not correctly update
- Fixed an error that occurred when trying to place a lock on a doorway that was already locked
- Added a DungeonFlowBuilder helper class to assist with creating a dungeon flow graph through code
- Added a new "count mode" to the local prop set script which allows the number of props to change based on the tile's position in the dungeon layout
- Fixed an issue that was incorrectly allowing assets to be selected in the LocalPropSet component

2.9.0
- Reverted the ProBuilder support changes made in 2.8.0 - these are no longer necessary
- The Dungeon class now has a Bounds variable which reports the axis-aligned bounding box of the entire dungeon layout
- Fixed an error in the runtime analyser
- A root GameObject can now be chosen when using the RuntimeDungeon component. If none is specified, it will default to the old behaviour of creating a new root named "Dungeon"
- RandomPrefab props now have options for keeping the spawned prefab's position or rotation as an offset. Previously, spawned prefabs always snapped into position and ignored the prefab's transform (this is still the default behaviour)
- Added integration for generating navigation meshes with both RAIN and A* Pathfinding Project Pro
- The utility function UnityUtil.CalculateObjectBounds() now ignores trigger colliders by default. Room bounds should no longer encompass any trigger colliders
- Fixed errors when using custom doorway socket connection logic
- Moved TypeUtil class to the editor folder as it was causing issues when trying to build for Windows Store (and possibly other platforms)
- Added an option to disable the trigger volumes DunGen places around each tile. If disabled, the DungenCharacter component won't receive events when moving between rooms

2.8.0
- DunGen will no longer throw an ArgumentOutOfRangeException if a GameObject containing a Doorway component is disabled
- Tiles will now maintain their proper weights across multiple TileSets. The old behavior can be reactivated using the "Use Legacy Weighting" option in the dungeon generator settings
- Fixed an error when trying to build a project with SECTR integration
- Fixed a stack overflow exception that occurred when no Tile matched the requirements for the next room in the layout
- The scale of Tile prefabs will no longer be reset before being placed by the generator
- DunGen now supports tiles made with ProBuilder


2.7.0
- Injected tiles can now be marked as required. If a required tile is not present at the end of the branch path stage, the generation will fail (and retry until the layout is successfully generated or until the maximum number of failed attempts is reached)
- Added a new "Length Multiplier" option to the dungeon generator. The main path length of the output dungeon will be multiplied by this number. Allows for dungeon length to be altered at runtime between calls to the Generate() function
- Added support for PlayMaker actions for generating and clearing dungeon layouts
- Fixed an issue that was causing dungeons to not generate properly when Generate() was called from a physics trigger/contact
- The dungeon generator will now wait one frame before changing its status to "Complete" to ensure all unused GameObjects are properly destroyed first
- Fixed an error that caused DunGen to try to place locks & keys using a DungeonFlow without a KeyManager assigned
- Tiles placed using the tile injection system should now correctly make use of their full range of possible spawn locations
- Injected tiles should no longer occasionally overwrite tiles placed by a node in the DungeonFlow
- SECTR VIS culling is now easier to enable. Just unpack "DunGen/Integration/SECTR_VIS.unitypackage" and select "SECTR VIS" from the list of portal culling solutions in the dungeon generator settings. It's now also much easier to integrate your own portal culling solution; just derive a new type from PortalCullingAdapter and implement it's abstract methods.
- Portal culling will now also automatically handle doors placed by DunGen so that rooms are culled when the connecting door is closed. There is now a Door component which will automatically be added to door prefabs placed by DunGen. This component includes information about which doorways and tiles it is connected to and has an IsOpen property which is used to turn portals on or off when used with portal culling
- As a result of the new culling changes, door objects are now parented to the dungeon root, rather than their doorway to avoid being incorrectly culled
- Doors placed by the Lock & Key system are now considered the same as a door prefab and so will also benefit from the above

2.6.0
- Tiles can now be "injected" into DunGen before randomization occurs. Injection delegates can be added to the generator's TileInjectionMethods property
- Tile injection for simple cases can be done through the DungeonFlow inspector. No code required.
- Fixed an issue that sometimes caused tiles to not be cleaned up correctly in editor-built dungeons, resulting in what looked like overlapping tiles
- There's now a "Overwrite Existing?" option when generating dungeons in the editor
- Doorways now have a "Hide Conditional Objects?" option which hides all GameObjects in the "Add when in use" and "Add when NOT in use" lists. For the purpose of reducing clutter at design-time - has no effect on the runtime results
- All object lists now report how many objects they contain
- Doorways now have a "Blocker Prefabs" list which works similarly to the existing "Door Prefabs" list, except with doorways that are not in use. Allows you to define blocking objects without placing them in the tile first, if that's your preferred workflow

2.5.5
- "Allow Immediate Repeats" can now be specified per-tile and is now set to false by default
- Both "Allow Immediate Repeats" and "Allow Tile Rotation" now have optional global overrides that can be set in the dungeon generator
- Fixed an issue causing Tile trigger volumes to sometimes be incorrectly oriented
- Fixed a bug which lead to SECTR portals not being removed when calling the Generate() function multiple times (like when using the analyzer)
- Fixed some camera related bugs in the demo scene

2.5.4
- DunGen is using a new method for socketing doorways together which is more robust. Doorways can now be aligned vertically (for stairwells, for example)
- The DungeonGenerator class now has a DetachDungeon method allowing you to "tear-off" the dungeon from the generator so that it is not overwritten next time Generate() is called
- [EXPERIMENTAL] The DungeonGenerator class now has a GenerateAppended method which will generate a new dungeon appended to a previous dungeon that you specify. NOTE: This is entirely experimental and NOT supported functionality; dungeons generated in this manner will likely overlap or fail depending on whether allowIntersection is set
- Doorway components now have a ConnectedDoorway variable
- Tiles now have some methods of getting/checking adjacent Tiles
- Tiles now contain a BoxCollider trigger component. There's a new DungenCharacter component which handles information about which Tile it's currently in (with events fired when switching tiles)
- The Lock & Key system will correctly also place locks on doorways that don't have a prefab applied to them

2.5.3
- DunGen should no longer try to apply a lock to the same door twice, causing an exception to be thrown
- Doorways with no possible "locked door prefab" will no longer be considered when adding locks
- In-editor dungeons will once again generate correctly
- Dungeons should now be generated in the local coordinate space of it's root GameObject, rather than at the world-space origin
- Minor changes to make the demo scene compatible with Unity 5.0
- Fixed a divide-by-zero error when calculating a branch tile's NormalizedPathDepth, resulting in errors in Unity 5
- An archetype's "Branch Count" and "Branching Depth" variables should now work as intended

2.5.2
- Fixed an issue causing RandomPrefabs to not inherit their parent's rotation
- RandomPrefabs will now correctly be added when nested inside another RandomPrefab
- Door prefabs will now correctly be added to open doorways
- Users should notice a large improvement in success rate when generating dungeons.
- DunGen will keep trying until it succeeds when the project is built (can still fail in the editor as a safety net to prevent infinite loops for invalid dungeons)
- Fixed an issue causing bounding boxes to sometimes be calculated incorrectly
- Doorways should no longer have multiple door prefabs assigned to them if the doorways were connected by overlapping
- Added a Straighten slider to the DungeonArchetype that controls the likelihood that the main path generated will be a straight line (thanks to Binary42)
- Doorways with different sockets will no longer be connected when overlapping
- Multiple keys can now be spawned for a single lock. In the KeyManager asset, each key has a "Keys per Lock" value
- DunGen should now retry to place a Tile when none of those in the TileSet have a socket of the correct type
- Users should notice a further large improvement in success rate when generating dungeons; in addition to shorter generation times (thanks to ashwinFEC)
- DunGen should now correctly try to add the specified number of locked doors to a dungeon segment. NOTE: This still rarely produces desired results

2.5.0
- Added an option to reduce the frequency that duplicate rooms are being placed right next to each other. Un-checking "Allow Immediate Repeats" in the dungeon generator settings will enable this behaviour.
- Added a button to the Local Prop Set inspector that allows for all currently selected GameObjects to be added to the list at once.
- Fixed a bug causing the bounding box of some rooms to be incorrect once rotated by DunGen.
- Fixed a bug causing the ChosenSeed variable to be set incorrectly after a failed generation attempt.

2.4.2
- Doorways no longer have to be on the very edge of a room's bounds. DunGen will calculate the bounds as usual, then collapse them to fit the doorways where necessary.

2.4.1
- Fixed a bug preventing the seed from being set manually
- Fixed a bug causing branching depth to not behave as expected

2.4.0
- Added preliminary support for 2D dungeons. It's now possible to change the up-axis for dungeon generation inside the dungeon generator settings. 2D support hasn't been thoroughly tested yet but it is feature-complete.

2.3.1
- DunGen now supports SECTR portal culling. If you have the SECTR VIS extension, you will have automatic portal culling applied to your runtime and in-editor dungeons with minimal setup.
- Added door prefabs

2.2.0
- Fixed an issue that caused the timings returned by the generation stats to be inaccurate when the dungeon fails to generate the first time
- It's no longer a requirement to make sure the prefab's position is set to (0,0,0) - not doing so will no longer cause the tile's position to be offset in the dungeon
- Added a new analysis tool that generates a set number of copies of a dungeon and presents detailed results such as success rate, average generation time, etc

2.1.0
- Lock Key system
- You can tell DunGen to connect doorways that overlap but were otherwise not connected during the generation process

2.0.0
- This is a complete re-write from version 1.x, a lot of things have changed in the code
- Implemented the dungeon flow editor. You can now control the flow of your procedural dungeons including the ability to add specific rooms at points on the main path
- Introduced two new types of asset: Dungeon Archetype and Tile Set which should allow for far more control when building a dungeon
- Homogonized object weights. Weights for all objects (tiles/rooms and all prop types) now contain a main path weight, a branch path weight, and a depth scale curve
- A lot of terminology and naming was changed, there's less ambiguity now when it comes to identifying key components of DunGen
- Cleaned up the UI a lot

1.0.1
- Added some height-varying rooms to the demo project to demonstrate multi-floor dungeons
- Added the option to generate a dungeon in the editor instead of at runtime

 

I've added a new room type to the web demo to showcase multiple floors. The demo scene in the asset store package doesn't have this change yet but it's just the same process - only the doorway is placed further up the wall.

The height variation really makes it more fun to explore.

 

Why must it be a MonoBehaviour?
You could easily turn this into an editor window and generate levels in-editor too instead of only runtime.

 

That's not something I'd really considered but it shouldn't be too hard to do. I'll start working on that pretty much straight away, it shouldn't take long so I'll probably have the next version submitted for approval by tomorrow.

Thanks for the input

 

Wow, this looks awesome; way more in-depth than other dungeon generators I've seen! This looks like it could be adapted to generate floorplans, too. Is there any way to ensure it fills an area completely?

 

Right now there isn't a way to ensure the dungeon fills an area completely. It's a fairly naive algorithm so it's difficult to guarantee anything. You could do something like this:

- Define a bounding box where the dungeon can be placed
- Modify the code that checks for overlaps to also check if the room is in these bounds, if not, discard the room

But even then, you can't be sure it'll fill the area, just reasonably confident. When designing DunGen I had to make a choice between freedom to design rooms without size/shape restrictions and being able to impose constraints more easily. I chose the former but I'll definitely spend time looking into ways to allow constraints without removing the freedom to design rooms as you want.

As for the floorplan thing, DunGen doesn't so much care about what you're representing with it, it just deals with gameobjects that have "sockets" - they can be anything you like theoretically. After generation, you also get access to information about the relationship between the rooms, so really, you can ignore the objects that DunGen places in the scene and use this information however you want. It comes in the form of three lists: allRooms, mainPathRooms, branchRooms and doorwayConnections with each room also knowing it's own depth in the dungeon. Hopefully, that's enough information to do pretty much anything you want to with it.



Unrelated: Version 1.0.1 has been approved, which just includes the option to use DunGen from the editor instead of at runtime. It's a little slower to generate in the editor for whatever reason, I've tweaked some things to make it faster but it's still slower than the runtime version. As an example, a dungeon I generated at runtime took 170ms to generate, the same dungeon took about 1 second in the editor (it took 6 seconds when I first implemented it). I'm not sure there's much I can do to improve it further, it just seems to be the way Unity handles moving things in the editor.

 

Hello,
If I make the prefab-room with sloping floors, DunGen arrange the props in different y-coordinate?

 

You place the props in the room yourself, DunGen doesn't do anything to place objects, it only decides which of the props should be kept and which should be removed. If you want objects on a sloped floor, you can do that. There are three types of prop randomization in DunGen:


Local Sets - You place multiple objects in the room and DunGen picks a number (that you choose) at random to keep, the rest are destroyed. This happens for each instance of a room.

Random Prop - You place an empty game object and choose a number of prefab objects. DunGen picks one at random to spawn at the empty game object's position. This also happen for each instance of a room.

Global Prop - You place objects in the room as usual but give it an ID number. DunGen picks a number (that you choose) at random to keep from the whole dungeon. E.g. You place a treasure chest in each room, give it an ID of 0 and tell DunGen that you only want one global prop with the ID of 0 to be in the dungeon.



As an example, I made a room with a sloped floor and added three props: a desk, table and small table and place them how I like. Using a Local Prop Sets component, I can tell DunGen how many of these objects I want to appear in each instance of this room and DunGen will randomize them. I chose to have exactly one. This is what I get:

Making the room prefab in the editor:


In-Game:


Hope that helps.

 

I'm open for feedback feature requests for the next version. I'm planning on working on the next release now so I'd like to know what features people are most interested in.

Possible upcoming features include:
- Built-in pathfinding solution
- Portal culling to only draw rooms you can see - should greatly reduce the number of draw calls and improve performance (especially on mobile devices)
- Lock key system - allowing for procedurally placed locked doors and corresponding keys in the dungeon


If anyone has anything to add to that list, now is a good time to do it. I can't promise I'll be able to implement everything for the next release but I'll get as much as I can done.

 

Hi this looks pretty cool. Can you make an exit point to the dungeon, and then choose it to be as far away from the entrance as possible?

 

DunGen generates a "main path" for the dungeon and then some branch paths coming off it (both with configurable lengths). Once the dungeon has been generated, you have access to a couple of lists containing information about the rooms. To add an exit to the end room in the main path, you would spawn your "exit" gameobject (through a script) into the last room in the mainPath list.

You can't have DunGen do this automatically just yet though. In the next version, you'll be able to choose to place specific rooms at the start and end of the dungeon path if you want to. So you should be able to do what you're asking out of the box. If anyone needs this functionality right now just say so and I'll try to put something together and get it submitted before I release the next version.

 

I've added a new web player demo and screenshot to the original post. The new demo (found here) uses simpler rooms with no objects and lower walls to better show off the actual layout of the dungeon. I've also raised the camera in the new demo so you can see the multi-floor structure over the railings.

 

Hi,
This tool looks amazing. I am excited to see the new version that includes the built in pathing solution and the lock and key system. I have a couple of questions: How would it handle enemy units? Do you add them to the rooms like objects and they spawn randomly? Would light sources work the same way? if you exit a dungeon into a new dungeon is it possible to go back to the previous dungeon or is that iteration lost forever? I am extremely interested in this as it is almost perfect for a project I am working on.

I have my obligatory suggestions for improvements
- Fog of war for unexplored rooms. (if using a top down or isometric view)
- Hidden doors
- Persistent dungeon floors that can be returned to.

 

The new webplayer2 looks great!

 

Thanks! Sorry for the late response.

Personally, I would add enemies (or enemy spawn points) to the rooms like any other object. Then you can use either a local random prop set or a global random prop script to pick from them at random. With the local prop set you can, for example, choose to have 0-3 of the spawn points in a room be active. If you use a global prop script, you can decide how many spawn points the entire dungeon floor has. It just depends on how you want to do things.

Light sources would work the same way. Any GameObject can be used with the randomized props (which is very powerful when combined with custom scripts attached to those objects). One consideration to make with light sources however is that they'd need to be dynamic - you can't bake lighting when you don't know if the light is going to be there or not.

Going back to a previous floor is easy enough. The dungeon is created using a seeded random number generator - give it the same seed (an integer), and it'll generate exactly the same dungeon layout. The only caveat is that objects would return to their original state. Any monsters the player had killed or any loot they had collected would be re-spawned. So depending on your needs, you might want some way of saving any changes the player made to a floor and then re-applying them to the layout when they backtrack.


Thanks for the suggestions! I'll add them to my list and see what I can do.

The hidden doors idea could potentially be done in the current version with a little bit of trickery. With doorways, you can specify GameObjects that you want to appear in the room when the door is in use or not in use. This is usually used for things like door frames, however, you can choose to spawn a random prop (which picks from a list of prefabs at random to spawn at the current location) when the door is in-use (leads to another room). This random prop can have a 95% chance to spawn an empty prefab and a 5% chance to spawn a prefab that looks like a wall but has a custom script that allows the player to open it. You'd probably want this to only happen for rooms in a branching path rather than on the main path (you won't want the player to spend hours trying to find the exit when it's through a hidden door). I'm not in a position to check right now but I believe I've included the ability to set the random prop's spawn chance separately for main and branching paths so you can set the chance for the hidden doorway to spawn on the main path to zero.

As an aside, a random prop can also be placed when the doorway is not in use and would pick between a blank wall, a locked door, or a collapsed doorway mesh to add a little bit of variation to the dungeon for doorways that are not usable.



The next version of DunGen (which I'm calling v2 - honestly, there are enough big features improvements to call it that) is taking longer than I would have liked thanks mostly to the pathing solution. It's not an easy problem to solve (there are whole $75 assets that deal solely with pathfinding). But the lack of pathing solution in DunGen is obviously a huge road block for people so I'm determined to get it incorporated. I'll try to keep this thread updated with the progress of v2 but I might have to work on other projects in order to get the money (and therefore, time) to finish it. Apologies to anyone keenly waiting on the release, I'm working as hard as I can.

 

Yeah there are already several pathfinding solutions, so it may be more worth while to focus on the level generation.

 

Perhaps - it's something that I've considered. I'm in an odd position with this: on one hand, it's not "my problem" since navigation really has nothing to do with dungeon generation and it's a big enough problem to be a full-priced asset on its own (of which there are many and they'll almost certainly do a better job). On the other hand, most games with procedural dungeons are going to need AI to traverse said dungeon and without it, DunGen just feels... incomplete.

Honestly, I'd feel a little scummy listing another $75 asset as a dependency if you want things to move through the dungeon.

Unfortunately, the structure of a lot of the code is determined by whether I include a built-in pathing solution or not so I can't even release v2 without the pathfinding and come back to it later. I need to either implement the pathfinding or scrap the idea altogether before I can progress. Not a good situation to be in.

 

It's up to you, but my recommendation would be to keep the scope on the core elements of DunGen, and make it as polished as possible.
It's noble to want to fulfill every request made here, but if it comes at a cost of quality to your core product then you will be worse off. No other dungeon generator offers pathfinding - as there are specialist assets out there that already do a great job. One only has to do a simple search in the asset store. The one that stands out so far is Aron Granberg's Astar, but there are some $10 options as well - I don't know how good those are though.

 

So I've decided not to include a built-in pathfinding solution in the next version. It was going to be a problem and after having dropped it, I'm making more progress. I still can't say with confidence when v2 will be released since it's effectively a complete re-write of the original but it's coming along much more quickly now.


I have, however, got the new system to generate a very basic dungeon (no objects as of yet). I don't think I ever mentioned this as a thing I was doing for v2 but it's far enough along to show now. First, it'll be helpful if I explain some new/changed terminology - the naming of things in v2 is much less ambiguous than before:

Tile - What was previously known as a "room", the discrete blocks used to build up the dungeon
Tile Set - A group of Tiles, you can organize these however you like
Dungeon Archetype - A description of a type of dungeon (which Tile Sets it can use, the branch count depth, etc)
Dungeon Flow - Describes the flow of the dungeon through the use of a graph. The dungeon flow can contain multiple Dungeon Archetypes
Dungeon - The actual layout that has been generated from the Dungeon Flow and placed in the scene

This is what a graph could look like:


The line in the graph can be split into as many segments as you like. You can apply a different Dungeon Archetype to each segment. Nodes can be placed on any point of the line (start goal nodes are fixed) - nodes can have any number of Tile Sets associated with them and when the dungeon is generated, a single Tile from those Tile Sets is picked at random to be placed at the node's position.

In the above example:
The start and goal nodes use a specific Tile (a square room with a sphere in the center)
The dungeon is split in the middle, with a different Dungeon Archetype assigned to each half
There is a mini-boss room just before the half-way mark and a boss just before the goal. Both of which use a specific "boss room" Tile (a square room with a cube in the center)

And this is the result in-game (the colouring wasn't applied in post-process, they're actually different Tile Sets):


This should add a lot more control for those who want it. If you just want the old behaviour, you would just have a single line between the start and goal nodes and apply the same Tile Sets to each of them.

As always, any comments, questions, or suggestions for improvement are welcome.

 

This looks very cool. Just a friendly suggestion - I think this feature should be mentioned outside of the tutorial as well.

Which allows to have doorways larger than one "tile".

 

Would it be possible to set a room to use a specified rotation only? If your game uses a fixed perspective (Diablo, Torchlight etc.) it might be important for certain rooms.

 

Thanks for the suggestion! I've added a point about different shaped/sized doorways to the feature list in the original post. I'll add it to the feature list on the asset store page when I release 2.0

It isn't possible right now but after reading this post I went to try and implement it in version 2.0 and I've been able to get something working fairly quickly so you can expect to see this feature in the next version. It's something I'll have to keep an eye on though since the more restrictions imposed on where rooms can/cannot connect, the greater the chance that the dungeon will fail to generate.


Speaking of version 2.0, I'll be releasing it once I finish testing, have made a demo project and written the new documentation. I could wait until all of the features I've mentioned have been implemented but I don't see the point. I'd rather release what I've got now and then add features in incremental updates after that. You get all the features that aren't done yet just as quickly but you get the finished features quicker.

 

Currently I'm evaluating unity3d in general for an game idea I have and even already programmed some dungGen myself your asset would make my life by far easier and implementing the idea faster

As far as I have seen up to now, it seems that the DungGen from you is connecting one room to another from start to end with branches. Would it be possible that it generates 2-n pathes from start to end or is it currently only planned to have it 'one-way'?

Thx in advance
Wyl

PS: As I'm eager to test the asset, I agree with you - as soon as you think you have something stable, please release it and update further features later on

 

Unfortunately, it's only a single path through the dungeon. Having multiple paths is something that I wanted to do but I really don't think it can be done with the way DunGen works.

There are other algorithms I could have used for the layout generation that would make things like this easier but they all come with some hefty constraints like rooms having to be a certain shape/size and doorways having to be in set positions.

 

But branches can still join with each other again in certain cases, right? I think I saw some paths in the web player going around in circles rather than always stopping at a dead end. Or maybe it was just one huge room.

 

They shouldn't be able to join. I went to look at the demo but you can't really see clearly which paths go where - with the multi-floor rooms, everything is overlapping.

Basically, the algorithm just builds up a path one room at a time, there's no way for it to backtrack or join up with other paths. Before I made DunGen, the system that I based it on (which came from one of my 20+ failed attempts at making a game over the last 2 years :|) would connect any doorway that, by chance, lined up with another doorway it was not connected to once the layout was finished but I don't think I kept that for DunGen. It happened so rarely anyway.

 

Well, I guess you could still use clever room templates to get around this, like creating a circular floor with some doors leading to the inside but having an ID reserved for small one-door rooms only so the inner circle gets randomly filled with small rooms to create the illusion of a circular map layout.

I am really excited about DunGen, so I'll probably purchase it tomorrow and start experimenting.

 

I've just submitted DunGen version 2.0.0 for review so it should be on the asset store in the next few days. If you don't want to wait that long, you can fill in the form at the bottom of <link removed as no longer relevant> with your invoice number and e-mail address and I'll send you the latest version as soon as possible.

I'm trying to make this process automated so people who want to can have access to the latest version before Unity gets around to approving it for the asset store but for now, I have to manually e-mail the package out to people. I'll try to get responses posted as quickly as I can.


The tutorial for the new version can be found here (http://www.aegongames.com/dungen-2-x-tutorial/). I'll be updating the original post when v2 gets approved. I'm still working on the features that didn't make 2.0.0 and I'll be keeping the original post updated with progress. Next up is the lock key system.

 

Great - will do as soon as possible.

Regarding the lining up doorways discussed above - do you think it would be much work to (re)implement that feature?

 

I don't think so. It was fairly straight forward to implement before although a lot has changed since then. It should be as simple as putting some extra code at the beginning of the post-process step (before the doorways are processed) that checks for any doorways that are not connected but share the same position, and calling the currentDungeon.MakeConnection() function.

I'll check it out and try to include it as an option in later versions - I didn't want to include it as the default behaviour because it removes some of the control (suddenly a room that was supposed to be at the very end of a branch is connected directly to the main path, for example) but I could definitely see it being an option in the Dungeon Flow settings - perhaps using a random percentage range for more control over how many overlapping doorways are connected.

I'll look into it.

 

- Version 2.0.0 has now been approved on the asset store -

I also want to leave an update on where I'm at with the lock key system. I haven't got it working yet, this is mostly just a post about the design I've gone with so far.

There is a new asset type called "Key Manager" which contains information about all of the keys you might need (name, prefab and colour since I think that's going to be a common thing people will want). Ideally, I would have liked the key manager to be saved in some sort of project settings but it seems Unity doesn't have any way of doing that (please, correct me if I'm wrong), so for now, it'll have to be an asset that you make in your project.

In the Dungeon Flow graph, you can add as many key types as you like to two lists in the graph objects (both lines and nodes) which will determine where keys locks can be placed in the dungeon.


Locks placed on a node in the graph will cause the entrance doorway to that room to be locked. Locks placed on a line in the graph will cause random doorways in that segment of the dungeon to be locked with that key type. I haven't yet decided on how keys will be placed, it's likely there will be a new component type to act as potential key spawn points.

In each TileSet asset, you will be able to specify a collection of possible locked door prefabs for each doorway socket group.

Since the handling of locks keys is fairly game-dependant, I'll be using a couple of interfaces that you can implement to work with the system. Some programming is going to be required for this, there's just no way around it.

ILockKey - Will have an OnKeyAssigned method. When keys and locked doorways are placed in the generation process, this method will be called on any script that implements the ILockKey interface in the key or locked doorway prefabs placed in the scene with information about which key type was assigned.


I'm still not sure exactly how I'm going to handle everything but I'm trying to make it as generic and controllable as possible while keeping the process simple. The lock key system is more dependant on gameplay code than I'd thought so it might be the case that I just can't include it in DunGen but for now, it's looking possible, I just have to work out some of the design problems.

Once again, any comments or suggestions are welcome.

 

I think it would make sense to allow these spawn points to be part of other prefabs so a key could spawn "inside" a container like a chest, a bookshelf or even a monster. Maybe introduce a generic loot spawn point?

 

So perhaps another interface? That would allow people to implement something like an "IKeySpawnable" interface in their own scripts and handle key placement however they like. That way, you could have a simple KeySpawnPoint component but you could also implement the interface on an Inventory script to give the key to monsters/chests.

So when DunGen is placing keys in the dungeon, it will pick from any script that implements IKeySpawnable at random and call its SpawnKey(Key key) function. That would mean it would be up to the user to handle key placement but I can't think of any other way to do it without stepping on game-specific implementations. Having said that, when it comes to checking if the player has a key and unlocking doors, there's no generic way of doing that either - so there really is no programming-free way of using the lock key system, there has to be some game-specific code in place.


One thing I hadn't thought of until now is Javascript or Boo. I never use either of them so I don't know how/if you can implement C# interfaces on Javascript/Boo classes in Unity. I don't really want people to feel they have to write their scripts in C#, but I think interfaces are the cleanest way of handling this particular problem.

 

Bought the asset and having fun currently with it.

It simple to use but on the other hand can be very powerful if used as indended And it is similiar as what I wanted to achieve with my generator (thanks for saving lot of time).

As I didn't dwelve deep into the code, would it be possible to access the random seed for generating with another script? What I want to achieve is that I generate several seeds in the beginning of a new game and store it to create a persistant dungeon during that game (going back and forth). Currently as far as I see there is only the option to have a random number or a specific seed.

Additionally, would it be possible that based on the depth of the dungeon to define if there should be a 'roof' on top of the room or nothing?

With regards to the key/lock-system: I think you are right... writing something very generic on one hand and no need for code on the other is very hard to achive. Would it be possible to solve that with some prefabs utilizing the keyword key/lock? In that way someone could define a prefab (like a pickup/trigger/chest/etc) and connect it with the 'lock' room. This may sound a bit silly, but I'm new to the options Unity offers.

BR
Wyl

 

Is it possible to add your own assets?

 

The seed is exposed in the DungeonGenerator class through an integer variable called "ChosenSeed". This will be set to the last seed used by the generator to create a dungeon.

To vary objects by depth you could maybe use one of the random prop types (probably a Random Prefab component) and adjust the chance of each object to spawn (roof or nothing) using the Depth Scale graph in the prop weight to make different objects spawn based on their depth in the dungeon.

Yes, it is. In fact, there's no option not to. All of the rooms are built up using your own models - the demos are only as bare-bones as they are because I don't have much art I can use so I just built the rooms out of primitive shapes for the most part.

 

Version 2.1.0 has been submitted to the asset store for approval, it should be available in a couple of days (or you can fill-in the form on the bottom of this page with your e-mail and invoice number). Sorry it took so long, I was an idiot and accidentally deleted a backup so I had to re-do some work.

In this version:
- The lock key system has been implemented, you can place locks and keys in the Dungeon Flow graph editor
- The option to have doorways that coincidently line-up, be connected, potentially leading to multiple paths through the dungeon. This option can lead to your dungeon not exactly following the flow you laid out and in some cases, can bypass locked doorway. This is not the default behaviour but is in place for anyone who wants it and doesn't care too much about the side-effects.

I've also updated the web player demo (link) to include locked doors. In the demo, there are 0-1 locks with matching keys in the yellow segment, a guaranteed lock on the boss-room entrance (with key somewhere in the orange segment) and a guaranteed lock on the boss-room exit (with matching key in the boss-room).

 

Ah man, your asset is looking really good! I'm too far down the track with Random Dungeon Generator now (also good), but I do like the fact that you can control the flow with DunGen. I'll definitely give your one a go for the next project

 

Woohoo!

 

Do the tiles know which archetype they are a part of in the dungeon flow? If so you could introduce an option to only allow them to connect doorways with other tiles of the same archetype so you wouldn't be able to bypass nodes.

 

Hi AegonGames, do you have the manual for download anywhere? It's quite hard to read it in the embedded into the iframe on your website.

 

They know what archetype they're using but not necessarily which dungeon segment they're a part of. Only connecting doorways on tiles with a matching archetype would work, unless you have more than one line segment or node using the same archetype. I could give each tile an ID to track which part of the dungeon it belongs to and connect doorways based on that. There still could be some locked doorways that you can skip (ones placed on the line segment itself) but at least these won't be the important ones that you place manually on nodes.

Yeah, sorry. There should be a download link just underneath the embedded viewer now (or you can find it here).

 

All good - many thanks Aegon!

 

Haha, you've tempted me Aegon - I had to purchase it after reading through

 

Thanks for the nice tool. I finally got some time to play with it after I have my enviroment ready in Unity

I really appreciate the fact that you can build your room(s) as a level designer but on the other hand add enough randomisation into it, that it keeps beeing interesting

One of my questions back then was with regards to the depth of the dungeon. I think we talked about different things. Consider I have an 'outdoor'level add height 0. Some of my rooms have stairs attached that leads deeper into the ground. If the room is on the highest level (like the outdoor or like to heighest part of a tower) I would need a ceiling. If I'm underground, a ceiling would be interesting/needed. Is there any way that I can access the information if the top of the current room is below the ground-level? And based on this, to add the ceiling or keep it off?

Nevertheless, I'm very happy with the purchase - enough fun to play around. After building some room, I have to think how to implement the key/lock interface. As I'm still learning Unity3D a question: would it be possible with the key/lock system that the key is a 'lever/button' to pushed or entered and that can trigger the door (via the interface)?

Thx in advance
Wyl

PS: Any idea if and when you're going to implement portal culling? I'm targeting mobile and anything reducing heavy FPS-drops are more than appreciated.

 

DunGen 2.1.0 has been approved and is now available on the Asset Store, I've updated the OP to reflect this.

There's no way for DunGen to know this but you could possibly write a custom script attached to the room itself to check if it's Y-position is below zero. DunGen places the first room at (0, 0, 0) so you can assume a height of zero to be ground-height (depending on how you set up your rooms).

The implementation is completely up to you. You could have the "key" prefab be a lever using a custom script (that implements the IKeySpawnable interface so it knows which key type has been assigned to it) that when interacted with, would look for a locked doorway in the scene that has been assigned the same key ID, and open it. There's no default implementation in DunGen, I tried to leave it as open as possible for this reason.

At some point, I hope to make a couple of examples for the lock key system showing a few different ways you can handle it in your own game since I know this is probably the least clear part of DunGen right now.

Portal culling is next on my list but I can't say when it'll be ready, sorry.

 

First of all, I want to thank you for your fast feedback.

The answers makes sense If you could bake some additional examples into the asset would be great.

I have some further queries:

I build a simple 9x9 units big room, with 1 exit on each side (this is the only tile). When I try to create a dungeon, it sometimes already failed only having a value of 20 for the number of tiles of the archtype between the start and end node (I wanted to perform a stress test with 500 rooms, but that failed as well..). Do you have any Guideline (or may include it in a readme in the future) what are do and don'ts (e.g. size layout of rooms) Would it be possible to add an example of the bigger layout from the webdemos?

Additionally, I have another question with regards to the logic behind the generator: Is the generator when placing rooms use the 'final' geometry of the room or is it using the one from the prefab?

Thx in advance - still try and test it

 

When it comes to increasing the chance that DunGen will successfully generate a layout, the more doorways the better. I'd suggest that most rooms should have more than 2 doorways if possible and that no room have less than 2. If DunGen fails to place a room, it will pick another doorway and try again until the maximum number of failed attempts is reached so increasing the number of doorways will make it less likely that the generation will fail.

Another thing to think about is rooms that would double-back on themselves in the dungeon. L-shaped rooms with a door on each of the points might lead to a circular path that blocks itself. But again, adding additional doorways would alleviate that problem somewhat.

One final thing to consider (and is arguably the most important) is that doors that don't lie on the axis-aligned bounding box (AABB) of the room basically don't count. DunGen checks for room collisions using the rooms' AABBs so doorways in incorrect placements will always result in a failed attempt at attaching a room. I want to remove this requirement in later versions, but for now, you'll have to ensure that doorways are in an accessible position (see the top of page 4 in the documentation for examples).

Sorry, I'm not sure what you're asking here. DunGen places an instance of the room prefab in the layout (objects in the room are parented under a single gameobject representing the room), just as it is in the prefab.

 

So if I understand it correctly, if the room is currently in the main branch and it doesn't find any other possible room/doorway combination within e.g. 20 iterations (per doorway or in total?) it will fail. It will maybe not marked as branch and Dungeon goes back in the line of main-rooms to find another way? This would mean, if all the rooms are on one floor level (no staircases, etc) and for whatever reason it goes in a bit bigger circle and is very likely to fail? As mentioned in your example for the L-shaped rooms.

True, I wasn't really clear here.

Lets take the below example prefab:
--#--
-###-
#####
-###-
--#--

The - are emtpy space, the # are floor tiles. the Red # are only available if there is a doorway used, otherwise the red # would be empty as well in the final drawing. For example there is a doorway on the south and the north used by DunGen:
--#--
-###-
-###-
-###-
--#--

Is the AABB calculated based on the prefab or is it calculated based on the final 'room' placed by DunGen?

Hope my textual drawing makes sense.

BR
Wyl

 

If the maximum number of failed attempts is 20, DunGen will try to place a room connected to the previously placed room up to 20 times (picking a random doorway and room template each time). When it succeeds, the number is reset for the next room to be placed. If it surpasses 20 failed attempts, DunGen will try to regenerate the dungeon from scratch (which also uses the maximum number of failed attempts). If it fails to generate a dungeon 20 times, it won't try again, but the dungeon generator will have its status set to "Failed" (which you can catch with the OnStatusChanged event).

If DunGen fails to generate a main path, it will just consider the whole dungeon a failure. There are better ways I could do it as you mentioned but this is how it works for now.

The AABB is calculated from the full contents of the prefab.


Hope that helps!