Cyclic Design for Dungeons

I saw this article recently. It's about video games (specifically "roguelikes"), but the logic seems to apply to RPG dungeons. It's got some interesting ideas.

@Adam_Dray , I thought you might enjoy the notes on a potential "megadungeon" design, given your City of Brass campaign. :)

Have you ever used such principles in your dungeon design?

If not, what principles do you use?


  • Oh man, Joris Dormas' dungeon grammars. This is very closely related to my thesis research!

    He used to have more details about how it worked on his website. It looks like his old site has down now, but let me see if I can find an archive version...

    Aha, here it is. (Dungeon Run was the working title of Unexplored at the time...) He has a few published papers on the topic as well.

    As for whether this stuff is interesting for tabletop RPG design... eh, maybe. My feelings it that procedural level generation research is still at the stage of jumping through hoops to train the computer to do things that human designers do intuitively.

    I am not sure this kind of level is ideal for a D&D game. Generally the goal here is to generate a dungeon with a lot of lock-and-key puzzles that all have to be solved to proceed. It is like a classic Zelda dungeon where each puzzle has one solution and once you solve all the puzzles you can continue the game. But D&D puzzles are less likely to have a single solution or so much of a lock-and-key structure.

    Then again, I recall that Longwinded Angry GM's series on the megadungeon he was building has a similar inspiration, with lots of lock-and-key gates. Maybe it has some promise with the right interpretation of locks and keys.
  • Gating is actually a central design notion for megadungeons, because it is what provides tension structures for exploration. It's just a particularly crude design if the gates are all doors that you need a key to open because magic door, ehe ehe.

    Rather, good megadungeon gating involves "a powerful monster lairs in the eastern quadrant, let's not go there unless we have to" and other similar fuzzy logic elements.

    "We cannot go west because we don't have rope."
    "We don't want to go south because it'll anger the natives."
    "We don't want to go north because it's a one-way entrance."

    Lots of things that one can do in the fiction rather than literal locks on literal doors. Without them the dungeon would be just a bland expanse of uniform doors and rooms.
  • Hm. Thinking about that, the difference I see is that in Dormans' approach, the solution to every gate is a key hidden somewhere else in the dungeon. The whole dungeon is structured (using graph expansion) so it is possible to find the keys in the right order. There's a chasm, so make sure there is a rope hidden somewhere accessible before you cross it.

    Whereas in D&D, often a puzzle is just there and the solution is something the PCs will bring from the surface world or else pull out of their class powers. There's a chasm, so I'll cast feather fall or go back to town and buy more rope.

    There's no reason you couldn't do the other thing, e.g., hide a ring of fire immunity with the intent that players will use it to get past the lava region. I think old tournament modules tended to do this a lot because it was very controlled what resources the party would bring in.
  • I've had a section of my megadungeon go unexplored for months because the group encountered a swarm of giant ants there twice and they are waiting for the half-orc (half-giant-ant) to be able to attend and help out.

    They crossed a 100-foot-deep chasm without a lot of forethought and almost died. The next time, they had the right tools and made it easy.

    There was a passage blocked by rubble and a warding circle that they ignored until last night. Finally cleared it and dealt with the wight trapped back there.
  • Stepping slightly aside from the locks and keys, I think the most interesting thing about Dormans' dungeon generation methodology has to do with using graph expansion rather than graph extension.

    A graph extension approach would be where you start with one room and keep adding more rooms outward. In spatial terms it would be a "start in the middle of the grid paper and draw" approach. If you implement this approach with the computer, it will tend to make a lot of disconnected areas, in a tree-like structure.


    Once rooms have already been drawn, then it is hard to add connections between distant areas of the dungeon because there are too many other rooms in the way. A human being following this approach is more likely to join the rooms up as they go, but it is still possible to draw yourself into a corner because there is no overall plan.

    By contrast, a graph expansion approach is to first start with a small number of nodes that represent the entire dungeon at a very high level. Then you recursively replace each node with a group of nodes that represent that area in slightly more detail. Eventually you decide you have enough detail and each node on the graph becomes one room.


    So for example, like in this picture, we replace the blue node on the left with a cycle of five blue nodes on the right. These nodes could themselves each represent a large area of the dungeon. By building top-down in this manner, you naturally end up with a dungeon with many loops and connected areas. The connections are built in from the start.

    Dormans performs this expansion using a graph grammar. This is series of rules saying what are all the different structures that one node may be replaced with (e.g., the ring of five nodes that I drew above). This technique is part of what is responsible for the "cyclic dungeon design" that they talk about in the article Paul posted.

    I am not sure how well this graph expansion technique would work for a human dungeon designer. It would be tedious repeatedly redrawing the whole graph in the way the computer does it. But if you thought of each redrawing as working the map out at a different scale, it could make sense. E.g., first draw an overall graph of super-regions. Then draw a map breaking each super-region into a series of regions, then draw each region as a series of sub-regions, then each sub-region as a series of areas, and finally each area as a series of rooms.

    For computer level generation, a difficulty is in translating the abstract graph into a spatial map when you are done. Topologically it is guaranteed to be possible based on the rules used to generate the graph, but if you are not careful (and you are a computer blindly following rules) you might end up with crossed lines or with some extremely long hallways. I think to avoid these problems is why Dormans uses rooms on a square grid in Unexplored. But I think the layout problem would be much easier for a human designer to solve, allowing more interesting levels to be designed.
  • edited February 2018
    I don't think an algorithmic approach is necessary for a human, but I liked his approach to graph expansion (I've fooled around with designing dungeons this way) and basing the design on loops instead of straight lines. Seems like handy stuff for RPG design, too.

    The description of "gates and keys" in the article talked a lot about how those things didn't have to be literal (they could be monsters or puzzles or hazardous environments), which, again, seems more relevant to RPG play to me. I like the idea of creating connections between different parts of the dungeon which clever players can find ways to leverage.

    For instance, put an angry tribe of ______ on level 7, but put their lost Chief on level 3, held captive by some other monsters. It gives the players some interesting considerations, depending on what order they explore things in.

    Thanks for the links! I'll check those out.
  • Mm, good points. I like the example of the lost chief, and Adam's examples above. For some things perhaps it is better to think of mystery and clue or story and resolution rather than lock and key.

    Probably I am focusing too much on the algorithmic aspect since it is my research... Though, come to think of it, it could be an interesting experiment to try playing with partially computer-generated and then human-completed dungeon designs, using some more interesting algorithm than traditional maze drawing approaches. (Especially if you then had some story about how a mad robot king had started to build the dungeon before he was killed and it was finished by mortal hands!)
Sign In or Register to comment.