Building Better Dungeons Using Puzzle Game Design: Lesson 1

Intro

Hi folks. Due to popular demand I’m consolidating a number of my posts from r/DnDBehindTheScreen into a blog. For now, all of my content will also be posted on that subreddit, but this should stand as a place to more easily find other articles I’ve written for other DMs.

This here is the first post in a series that is going to discuss some of the tenets of puzzle game design (video games, if that wasn’t clear) and how they can inform your dungeon design in DnD.

A Series of Disclaimers

First of all I want to make it clear that this is part of a series. If the ‘lesson 1’ in the title hadn’t made that apparent then this is your final notice. As a result, this first post is ultimately going to be light on applicable lessons and is going to be more about laying out the groundwork that the other lessons will build on. It is those lessons that will have more content that focuses on actually implementing these concepts into your games of DnD.

The second disclaimer is that I am currently running a game in Pathfinder 2nd Edition, and throughout this series I will be using as a case study a dungeon I recently designed for this game that utilised the lessons I will be outlining here. This will only come up sparingly, but sometimes I will be bringing up systems that do not exist in 5e when discussing this particular dungeon.

The final disclaimer is that this is simply a design philosophy and not the be-all-end-all for how to make a great dungeon. I think there are multiple different ways excellent dungeon design can be approached.

With that all out of the way, let’s get stuck in.

Levelling Up Your Dungeon

With that third disclaimer in mind, I want to say that I think there are 3 broad tiers of dungeons in DnD, and this series is designed to help you reach the highest of those tiers. They are roughly as follows:

Tier 1 – My-first-dungeon. A bunch of thematically-disconnected rooms where puzzles exist in a vacuum and enemies are all but randomised. In one room you fight skeletons, in the next you fight drow, in the next you fight a yeti. There is no overarching theme tying the dungeon together, and possibly no deeper a goal than ‘get to the last room to grab the loot there’. This is where many DMs start out. There’s nothing wrong with it, but it’s important to recognise it as the entry-level stepping stone that it is.

Tier 2 – The nine-to-five dungeon. This baby is a real workhorse in Dungeons & Dragons. There is a thematic tie that informs the puzzles and enemy encounters. Perhaps you are clearing kobolds out of a mine so it can resume operation. The fights are against kobolds, the traps and puzzles are mechanisms built by the kobolds to keep intruders out, and maybe the final fight is a group of fanatical kobolds protecting a dragon egg and trying to warm it in the heart of the forge. This is the tier that 90% of all dungeons fall into, including those in published adventures. I want to be clear, this is not bad design. In fact it’s really good design. It’s immersive, satisfying and ultimately creates a positive gameplay experience. But there’s still something better…

Tier 3 – The Holistic Dungeon. The dungeon is fundamentally defined by a theme or mechanic, and every facet of the dungeon ties back to this theme or mechanic. Everything from the way encounters must be approached to the integration of puzzles and how they must be solved. Tucker’s Kobolds is a classic example of the Holistic Dungeon, wherein an entire philosophical approach to building and running encounters defines everything that takes place in the dungeon. It is also not the only form of implementation of the Holistic Dungeon, and my aim here is to discuss one of the other major forms the Holistic Dungeon can take.

Here Begins Lesson 1

Great puzzle games have a few underpinning philosophies that we can use to inform our dungeon design, and the first is exceedingly simple:

Have One Underlying Mechanic

Think of the best puzzle games you’ve played. To take a classic example let’s look at Portal. Portal has just one mechanic: the portal gun and the rules that govern its use. There are additional elements that are introduced, like cubes, switches, and even enemies, but fundamentally the sole mechanic is the portal mechanic, and it informs how you interact with every single one of those other elements. When I talk about the Holistic Dungeon this is what I’m talking about.

Now I’m going to get into the DnD example using a recent dungeon of mine: The Grave of the Lantern Keeper.

In this dungeon the party has to retrieve 4 lanterns of different colours, and once a lantern is retrieved it is used to help retrieve the others. The lanterns have a few simple rules governing them.

1. A lantern must be carried to be used and takes up 1 hand.

2. A lantern can be turned on and off with an action and fills the room with coloured light.

3. While a lantern is on, magic from its relevant arcane tradition cannot be used.

That’s it. That’s the rules. Every single puzzle, every single combat, every single element in the dungeon right down to how it’s navigated ties back to those 3 rules. All of the dungeon’s challenges relate to some facet of them.

Just like in Portal, where every challenge relates to how you can use your portals.

(Two notes, Pathfinder 2e has a 3-action system, so for the purposes of 5e think of a lantern as requiring a bonus action to activate. Also, Pathfinder 2e has 4 arcane traditions (in addition to the various schools of magic), Arcane, Divine, Primal (Nature), and Occult. Naturally this can’t translate wholesale to 5e. Again, this is not a guide on how to run my dungeon, this is a guide on a design philosophy for making your own dungeon in your system of preference.)

What Exactly Gets Tied To The Mechanic?

Let’s start with puzzle games again. Portal has 3 different sequences of gameplay, each of which are informed by the core mechanic of portals. The first is solving puzzles in a controlled environment. The puzzles are solved with your portals, and you interact with the various elements of the puzzles also by using your portals. The second is escaping the controlled environment. We go from a puzzle sequence to what is essentially an action sequence, but again the way the action unfolds is informed by the fact that you have a portal gun. Finally there is a boss fight, and the way the fight works (and is ultimately won) is once again informed by the fact that you have a portal gun.

In DnD this manifests more simply. We think of puzzles as existing almost in a vacuum in DnD. The party more or less stops, learns the mechanics and rules of a puzzle, then they solve it and move on. The mechanics rarely come up again. Even if the puzzle encompasses multiple rooms or indeed the entire dungeon there is the fundamental fact that the rules of the puzzle are relevant only to the puzzle. In the multi-room or dungeon-wide puzzle combats are often an obstacle in the way of continuing to solve the puzzle, not a part of the solution themselves. This would be like if Portal had only the test chambers and then the game ended, or if the fights had you pick up a regular gun just for that fight and then afterwards you went back to solving portal puzzles.

To design more holistically we need to tie it all together. We need to introduce a mechanic that doesn’t just inform how the puzzles can be solved in this dungeon, it also needs to inform how the combats take place and are won, and needs to inform how the dungeon is navigated on the most fundamental level.

Outro For Now

Lesson 2 is going to begin to focus more on that last bit, and I’m going to be using the Lantern mechanic as a case study on how I have implemented these lessons.

To summarise this post, one approach to great dungeon design is to tie everything back to a single, simple mechanic rather than have a number of disconnected mechanics (even if they are thematically related), just like in a puzzle game.

4 thoughts on “Building Better Dungeons Using Puzzle Game Design: Lesson 1

Leave a comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.