DunGen - Procedural Dungeon Generation

Current Version (Asset Store): 2.16.0
Current Version (Beta): 2.17.0

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.



  • 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).

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



- 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

- 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

- 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

- 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)

- 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

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

- 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

- 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

- 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

- 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)

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

- 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

- 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

- 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

- 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

- 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

- 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

- 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

- Auto-calculated bounds should now ignore particle systems

- 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

- 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

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

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

- 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

- 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

- 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

- 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

- 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

- 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

- 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

- 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

- 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

- 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

- "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

- 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

- 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

- 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

- 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.

- 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.

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

- 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.

- 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

- 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

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

- 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

- 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

1 Like

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.

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

1558910--91909--$want i want y coordinate.jpg

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:


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.

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. :)

Different doorway types

The doorway has a Socket ID field which is used to match certain doorway types together. Each doorway can only connect to another doorway with a matching Socket ID. This allows you to make sure that larger doorways aren’t incorrectly connected to smaller ones. If all of your doorways are the same size, you can safely leave this at the default value for every doorway.

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