Dungeon Generator (Part 1) – Node-Based Approach


In this blog post, I’ll describe an algorithm for procedural generation of 2D dungeon levels with a predefined structure. I won’t go into implementation details today as I plan to make this into a (mini) series and cover it in the next post.

All posts in the series:


The algorithm was written as a part of my bachelor thesis and is based on the previous work from Ma et al (2014). The goal of the thesis was to improve the speed of the algorithm and enhance it with new features. I’m quite satisfied with the result as we were able to make the algorithm fast enough to be used during game runtime. After finishing the thesis, we decided to transform it into a paper and submit it to the Game-ON 2018 conference.


To produce a game level, the algorithm takes a set of polygonal building blocks and a level connectivity graph (the level topology) as an input. Nodes in the graph represent rooms, and edges define connectivities between them. The goal of the algorithm is to assign a room shape and a position to each node in the graph in a way that no two room shapes intersect and every pair of neighbouring room shapes can be connected by doors.


(c) and (d) demonstrate layouts generated from the input graph in (a) and building blocks in (b).

Through the connectivity graph, a game designer can easily affect the flow of gameplay. Do you want a single main path to a boss room with some optional side paths? Simply start with a path graph and then pick some nodes where the player can choose to either follow the main path or explore a side path with possible treasures and/or monsters waiting for him. Do you want a shortcut? Simply choose two nodes in the graph and add a shorter path that connects them. The possibilities are endless.

Examples of input graphs. Main path is shown in red, optional paths are blue and a shortcut is orange.

Not only does the algorithm allow game designers to control the high-level structure of generated layouts, it also provides ways to control the look of individual rooms and how they are connected to each other.

Different room shapes for different rooms

I mentioned having a boos room at the end of the dungeon. But we do not want our boss room to look like every other room, right? The algorithm supports defining room shapes on a per-room basis. For example, we may have a spawn room and a boss room that should have their own sets of room shapes and then one generic set for other rooms.

Two layouts generated from an input graph that has a special room shape assigned to the room number 8.

Explicit door positions

Imagine having a really nice script for our boss encounter and that we need the player to enter the boss room from a specified tile. Or we may have a room template with some tiles reserved for walls or other obstacles. The algorithm allows game designers to explicitly specify possible door positions of individual room shapes.

But sometimes our goal may be the opposite. We may design our room templates in a way that they can have doors virtually anywhere. By doing that, we put less constraints on the algorithm and it therefore often runs faster and generated layouts may feel less repetitive and more organic. For such situations, there is a possibility to simply specify length of the doors and how far from corners they should be. The distance from corners is kind of a compromise between manually specifying all doors and having doors anywhere.


(a) illustrates different types of door positions – the square room has 8 explicitly defined door positions, whilst the rectangular room uses lenght and distance from corners. (b) shows a simple generated layout with room shapes from (a).

Corridors between rooms

When we talk about dungeon levels, we often imagine rooms connected by narrow corridors. It would be tempting to think that connections in the input graph represent corridors. However, these connections aren’t corridors – they just ensure that all neighbouring nodes can be connected directly by doors. If we want to have rooms connected by corridors, we have to insert a new node between all pairs of neighbouring rooms and pretend they are corridor rooms (with specific room shapes and door positions assigned).


Illustration of how we can modify the input graph to add corridors between rooms. (a) shows an input graph before adding corridor rooms. (b) shows an input graph created from (a) by adding a new room between all neigbouring rooms in the original graph.

Unfortunately, by doing so we make the task a lot harder for the algorithm as we often end up with twice as many nodes. Therefore, I implemented a version of the algorithm that is aware of corridors and can reduce the performance loss of laying out corridor rooms. The algorithm currently supports either having corridors between all rooms or not having corridors at all, but I plan to make this more customizable in the future.


Several layouts generated with different sets of building blocks and corridors enabled.

Several layouts generated with different sets of building blocks and corridors both enabled and disabled.


You can find a .NET implementation of the algorithm on my github. The repository contains a .NET DLL and a WinForms GUI application which is controlled by YAML configuration files.

What’s next

In the next post I’ll describe how the algorithm works under the hood.

I’m also working on a Unity plugin for procedural dungeon generation that will incorporate this algorithm. The reason for that is that even though this algorithm can be directly used in Unity (as it is written in C#), the user experience is far from ideal. It is quite time-consuming to design room templates without a GUI and there is also quite a lot of programming needed to transform the output of the algorithm to a representation that is usable in a game.

As I’m not a game developer myself, the goal is to make the plugin good enough for someone else to use it. If everything goes well, I’ll try to post updates when I have something interesting to present. I’ve also got quite a few ideas regarding the generator itself and testing its possibilities.

Screenshots from the Unity plugin (WIP)

If you have any questions or suggestions, please let me know in the comments! Also this is my very first blog post so any feedback is appreciated.

5 thoughts on “Dungeon Generator (Part 1) – Node-Based Approach

  1. Excellent resource.
    I had always wanted to re-make an old Dos game by Microprose called Sword Of the Samurai.

    This will help tons ( you could probably use it as an example too )


  2. Hello again, I have been trying to port this to java but without any success, I think this method is absolutely perfect for the game I’m working on.

    You can see the game here https://twitter.com/OkaeriStudio

    Can you port it to java or make a small example? I don’t need the corridors so, maybe is not too hard to do.

    I’m open to give you credit or pay a commission for it, thank you 🙂

    1. Hi Alpha,
      I think it very much depends on what portion of the library you want to port. The whole library’s written so that it’s extensible, which makes some parts of the code more complex that they need to be (and therefore harder to port). However, if you focus only on some part of the library and know that you’ll never need some additional features, I think it’s possible to port a simplified version to Java.

      As I said in the blog post, I plan to write another post that’ll cover the implementation of the algorithm and provide some tips & tricks regarding what to be aware of, etc..

      The problem is that I’m currently preparing for my final exams so the amount of free time I have is very limited and it’ll be like that for 3 more weeks.

Leave a Reply

Your email address will not be published. Required fields are marked *