Dungeon Architect: Dungeon Meta

Previously I have outlined my thinking about what counts as a dungeon. Now we can get to the more practical problem: how does one design it?

As usual, if you are confused about any terms, make sure to check out the glossary, and if you are looking for other posts, check out the blog map.

Several things have to be done to finalize a design of a dungeon. Obviously, you need a location for it. You need some content that will fit inside. And you need some kind of link from the players to the dungeon (the hook), in order to serve the content to them in a natural manner.

Note that I do not use words like “first of all” to enumerate this list, and this is because none of these have to come first. Design process can start from any point, and proceed from there to any other.

For example, you can start with an idea for a cool location, and add content to turn it into a dungeon. Alternatively, maybe you already have the location - a city hub, the house of some NPC - and all you need is the stuff to put inside. Another approach could be to start with the content. Maybe you have an idea for a cool boss fight, or some really clever puzzle. Then you can design the location and the link to the players around the content. Finally, some dungeons make sense to start with the link to the players - some crucial plot hook they provided.

What part of the design process you start with will depend on context and the way your own creativity flows in the moment. Furthermore, depending on how well you want the finished product to function, you may need multiple passes through each step to finalize the design. After all, specifics of combat encounters depend on the environment, but environment determines what kind of enemies may be available, so it isn’t possible to draw a strict separation between concerns here.

I will discuss the specifics of location, content and the hook in their own separate posts. For now let’s talk about the problem from a somewhat more distant scope. Let’s start with a simple question: when should you put a dungeon into your game?

Given my definition of a dungeon, and my definition of the purpose of PNP RPGs, the question answers itself. You should put the dungeon in your game when you believe that your players have utility functions that would be efficiently satisfied by a package of fast-paced experiences, and the form of those experiences should depend on the utility functions of your players.

Let’s say that your players primarily enjoy combat, puzzles, and other activities that typically happen in dungeons. Then you should structure your games in such a way that dungeons take up most of the time. On the other hand, maybe your players are more into strategic decision making and roleplay: then you would either modify your dungeons into a form that wouldn’t be traditionally recognized as a dungeon, or you would use them only sporadically, on rare occasions when your players want a change of scenery.

There is an important caveat to make here in regards to the inconsistency unfun type. Let’s say that your players keep doing things that would result in e.g. combat, but do not derive that much enjoyment out of the actual process. For example, say that they keep sneaking into various locations in order to steal key objects (because their characters are well-suited to this task and it’s an effective way of achieving their objectives), but the actual process of sneaking or of combat if the sneaking fails isn’t engaging. Furthermore, let’s say that one or more of the players have the inconsistency unfun type, so you can’t directly steer the game away from these situations without causing annoyance: you can’t e.g. move the items to less defended locations because this wouldn’t make sense to your players. In effect, the circumstances force you to create dungeons despite them being unsatisfying to your players, because the alternative is even more disappointing.

One option I would recommend here is to abstract the process away, so that e.g. combat becomes just several rolls directly on some form of outcomes table instead of a detailed round-by-round process. That should help you avoid the boring parts while preserving the consistency. If this too is unsatisfying to your players (because of e.g. concerns that any kind of outcomes table you can quickly design would be a highly inaccurate model of the results of that boring round-by-round process you wanted to avoid), then you should do a cost-benefit analysis between the three options here (dungeons, world manipulation, outcome tables) and choose the least bad one.

Outside of this one edge case, I think there is no reason to create a dungeon unless your players want a dungeon.

Now let’s consider the next key question: how much work should you put into creating the dungeon?

Based on my philosophy of JIT, you should only do additional work on the dungeon if either:

• You enjoy it for its own sake

• Or you suspect the players are decently likely to interact with some piece of information you could prepare in the next session - as in the one in the immediate future - and you don’t trust your improv abilities to adlib a good enough answer on the spot.

• Or you suspect you will need to do some extra work to make sure information about this dungeon will be consistent with other information about your game, and ad libbing on the spot will most likely be inconsistent, and your players or you will hate this.

If the information won’t be used until at least the session after the next one, you should delay work on it until after the next session. If the players are unlikely to interact with the information at all, you should consider risking it and not do any work on it. If your players are fine with a little inconsistency in regards to some feature of the dungeon (e.g. they don’t care that much if building materials aren’t consistent with what you’d expect based on the prices on the local market), then there is no reason to think a lot about that part.

This brings us to an even more specific question: how many dungeon rooms should you be making?

In my opinion, at most five.

The reasoning here is pretty simple, and consists of several arguments. First of all, in my experience, five rooms are about as much as a party can go through in a single 3-4 hour session. This means creating any rooms beyond that would be a mismanaged effort: see above, if you won’t need the sixth room for your next session, you shouldn’t make it.

Secondly, it is difficult to estimate player preferences in general, because they change over time and depend on temporary moods. Estimating player preferences two weeks from now, after whatever happens in your next session, is more difficult still. There are decent chances that any work you do now in preparation for a session two weeks from now will be wasted, because your prep won’t fit their desires. Ideally, you want every session to end on a point which doesn’t lock you too much into what you will have to do next session, so that you could freely pivot based on aforementioned change in moods.

Thirdly, extending a dungeon is easy, but shortening one is hard. Unless your dungeon is pretty linear in design, every door your players pass by puts a lower bound on the size of the dungeon: every closed door has at least one room behind it. If you want the door immediately before a “final” encounter to look special, and your players didn’t get to that door last session, their observations put down another limit. Any kind of keys that help them bypass locks later in the dungeon, or extra information they may need, likewise put lower bounds on dungeon size. This means that shrinking the dungeon beyond the view of your players becomes harder, because you can’t shrink it without violating consistency with already revealed information.

On the other hand, extending a dungeon is as easy as adding a single additional door - possibly a secret one, at that - to any one room in the dungeon. This puts a very low burden on consistency. This means that if you think your players will want to explore a dungeon next session too, great - and if they don’t want to, you can easily pivot. But if you designed too much last time, you risk running into an issue where your players are forced to go through the rest of the dungeon, even if they don’t really feel like it.

My conclusion is supported by more “traditional” techniques in PNP RPG space, like the eponymous five room dungeon.

Hopefully this gives some clarity in regards to more “meta” concerns surrounding constructing a dungeon. Next up: what you should consider when building the location itself.

Meanwhile, if you enjoy what I write, you can subscribe to receive updates by email: