DunGen - Procedural Dungeon Generation

[Aegon-Games]

Current Version (Asset Store): 2.17.1
Current Version (Beta): N/A

DunGen - Procedural dungeon generation for Unity

Description

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

Considerations 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

[Aegon-Games]

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.

[BrUnO-XaVIeR]

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.

[Aegon-Games]

@BrUnO XaVIeR

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

[Alphalpha]

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?

[Aegon-Games]

@Alphalpha

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.

[DAC]

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

[Aegon-Games]

@DAC

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.

[Aegon-Games]

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.

[Eyehawk]

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?

[Aegon-Games]

@Eyehawk

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.

[Aegon-Games]

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.

[Sitting_monk]

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.

[Eyehawk]

The new webplayer2 looks great!

[Aegon-Games]

Thanks! Sorry for the late response.

@Sitting_monk

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.

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.

[Eyehawk]

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

[Aegon-Games]

@Eyehawk

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.

[Eyehawk]

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.

[Aegon-Games]

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.

[c-Row]

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