How To Design Puzzles Part 1

Intro

This one has been a long time coming. I’ve spoken at great length about taking lessons from puzzle games, and also about utilising puzzle mechanics to create incredible dungeons, but in all that something’s been missing.

When I’ve brought up creating puzzles I’ve just sort of laid it out there as ‘when you make a puzzle do this’. I’ve never gone into the how. Today I’m going to do that.

The Fundamentals

The way to make a puzzle is to more or less work backwards. First we’re going to work backwards from how a puzzle is meant to function so that we know what we’re doing when we design puzzles. Once we’ve done that we’ll go through the application of these concepts so that we can actually design a puzzle from the ground-up.

So first of all, there are 3 things a puzzle needs to be: Solvable, Intuitable, and Logical.

Solvable

This one seems obvious on the surface. Of course a puzzle needs a solution! But that’s not quite what I mean here. Just because a puzzle has a Solution doesn’t mean it’s Solvable. A puzzle only becomes Solvable when that solution can be reasonably reached.

A puzzle that has 12,000 possible outcomes and only 1 correct solution with no way to approach it except for ‘guess-and-check’ is not Solvable. The solution cannot be reasonably reached. It also wouldn’t be fun, for what it’s worth.

So in order for the solution to be reasonably reached, the puzzle must be Intuitable.

Intuitable

This really just means that the puzzle’s rules can be reasonably interpreted by the party. They don’t have to fully understand the rules to begin with, but they must be discoverable, and it must be possible to interact with the puzzle without having to guess what to do.

Firstly, our descriptions of spaces, objects and scenes go a long way toward making this part happen. Let’s say as a part of a puzzle there is a hand-held lantern with a switch. If we describe the lantern as having a switch, the puzzle is now Intuitable as there is an obvious point of interaction and the players’ natural inclination will be to say ‘I thumb the switch’.

If we were to simply describe there being a lantern and never mention the switch, then we are relying on the players to randomly guess that there is a switch they can interact with. This would make the puzzle not be Intuitable.

Secondly, the way a party interacts with the puzzle must be easy for them to figure out. If you describe the switch, but actually the way to turn on the lantern is to hit it with a sword, your puzzle is not Intuitable.

Essentially every part of the puzzle has to be easy for the party to interact with. The challenge should be figuring out how to solve the puzzle, not how to interact with the puzzle in the first place. The net effect of this is that the puzzle needs to be Logical.

Logical

Intuition follows a kind of logic. If a lantern has a switch then the logical conclusion is that the switch will affect the state of the lantern, probably by turning it on or off. The rest of your puzzle’s mechanics must follow a similar thread of logical interaction.

Let’s say the lantern casts a directional beam of light. It would be logical for an obstruction to this beam to cast a shadow. If a part of the puzzle’s solution requires you to create a shadow of a certain shape using objects around the room then this would be a natural extension of the Logic of how both the lantern and light itself works.

If the aim of the puzzle was to use the lantern to bash someone over the head then it would not be a Logical extension of the mechanics introduced.

Teaching Mechanics

Fundamentally, to navigate a puzzle and eventually solve it the party must learn the mechanics of the puzzle and how they are applied. This means we need to grade the difficulty of the puzzle in a natural progression. I’m going to use what I consider to be the gold standard of this as an example: The Witness. This will contain light spoilers from the first 5 minutes of the game.

The Witness is a game about drawing lines on screens to satisfy rules. Here’s how the first few instances of this plays out.

The first puzzle looks like this:

It solves like this:

This has taught us that we will need to click on screens to draw lines from a bulb to an end point. The second puzzle is much the same, but it includes a corner.

This has also taught us something. Actually it’s taught us two things. First it’s taught us that lines can bend. Second it’s taught us that even though that fact might have already seemed obvious, the game will go out of its way to teach things like this to us. If something is a logical extension of a mechanic in this game, the game will confirm for us that this is the case. Therefore we shouldn’t make any assumptions that we cannot later confirm. An unconfirmed assumption must be considered to be false until shown otherwise.

Now we get this:

This shows us that a panel may have multiple paths, but only one is drawn to the solution. Similar to that is this:

Which shows us that a puzzle may have multiple valid solutions, and understanding what each solution achieves will be important to navigating the world.

Finally we’re ready to leave the starting area and are immediately met with a short branching path that naturally inclines us to stop and look at this:

What the hell? Multiple start points, multiple end points, plus a whole bunch of other shit. We might try and draw some lines, but this contains a bunch of random symbols that we haven’t seen before. There’s nothing useful to be gained here, so we go back down the main path and we see this:

And then also this:

Between these two sections we are taught the mechanics of these extra puzzle elements, and the teaching sections also require you to confirm that you fully understand the mechanic before you can progress to the next one. Once we’ve solved both areas we can go back to that crazy puzzle from before and solve it.

The game has just taught us that if we encounter something unfamiliar then there will be somewhere else in the game where we will get taught how it works. We will never have to brute-force something or otherwise guess how a mechanic works.

Like I mentioned above, this is the absolute gold standard of how to progress through a puzzle. Everything is taught, but we are required to examine our solutions to understand what it is we have learned. We are also never required to make any leaps of logic. We may make assumptions which we then check the validity of, but at no point do you need to brute-force a solution.

What lessons Do We Take From That?

There’s a pretty major thing that’s going on under the hood with these puzzles, and it’s something we need to apply to our own puzzles too. I even mention it a couple of times in the above section.

The game will not let you progress until you can demonstrate you truly understand the rules and mechanics.

The reason for this is simple. If you continue and do not fully understand the mechanics, or have made a wrong assumption about a rule, then you will struggle or be completely unable to solve puzzles later in the game.

Gated Progression And Graded Progression

Let’s now take a look at Gated Progression. This is when an area cannot be accessed until something else has been done. D&D actually has a lot of gated progression, though it’s often the soft kind. An example is a bridge over a river that has an ogre guarding it. This is a gate. You cannot continue until this obstacle is dealt with.

This is a Soft Gate because it can be dealt with in multiple ways, but it is definitely still a gate. Many parties will opt to fight and slay the ogre in order to pass. Some parties may choose to negotiate with the ogre in order to pass. A small few parties may seek to cross the river in other ways. All of these are valid ways to get past the gate.

Puzzles are what I would call a Hard Gate. They block access and progression, but there is also only one way to get past them and that is to solve the puzzle. Usually people in D&D decry the idea of Hard Gates with a single ‘right’ solution. The fear here is that if players can’t get to that solution then they can’t keep playing through that area, and also that they’ll stop having fun. I want to make one thing completely clear:

This is only an issue if the single solution is not Solvable, Intuitable and Logical.

A well-designed puzzle can very much have a single solution that prevents progression until it is found.

Now let’s talk about Graded Progression. Graded Progression is where progress is easy but becomes incrementally harder. An example might be crossing the bridge, only there’s 3 enemies guarding it and each fight is harder than the last.

Puzzles utilise Graded Progression a lot. The main thing when Graded Progression is a factor is puzzles must also have a smooth difficulty curve. In the combat example we can have spikes. The last combat can be significantly harder than the first 2 and it isn’t an issue. It is simply a part of the challenge. For puzzles this is not the case.

Each puzzle must be harder than the last, but it cannot be significantly harder than the last.

My Greatest Failure

To end off this part I’ll talk about the worst puzzle I have ever designed. It is even infamously named ‘The 4-Hour Puzzle’ at my table. This puzzle involved breaking a cipher that an enemy faction was using. The previous cipher had been cracked by the party already (and was reasonably simple). The consequence of this was the enemy faction had developed a more advanced cipher that could not be broken so easily. This makes a lot of sense until you consider one thing:

A cipher that is designed to be hard to break does not make for a good puzzle.

This cipher was extremely similar to the last, but it required about 3 major leaps in logic. This is where things broke down. The puzzle required several leaps in logic based off the last cipher. The progression was not correctly Graded. The difficulty spike was too steep. Also, because of these required leaps the puzzle was no longer reasonably Logical. Because the logic broke down, it was no longer Intuitable. The net effect of this? The puzzle ceased to be Solvable.

Now eventually the party did solve the puzzle, so one could argue that it was Solvable, but let me ask you this: Does 4 hours seem reasonable? Worse, does it sound fun?

I can even answer that last one for you. It was not fun. It was awful.

Outro For Now

So now we have some pretty high-level concepts of what puzzles need to be, which can themselves help inform us how to make them. However I will concede that I still haven’t done a step-by-step ‘How’ yet. Well fear not, because in the next part that’s exactly what I’m going to do

The next part of this is going to focus on an extremely successful puzzle of mine that underpinned the most complicated dungeon I have ever built and run. If you guys remember The Grave of the Lantern Keeper, this trounces that. It was the next dungeon in the same series: The Scrivener’s Tomb.

I’ll be walking through how I designed a key puzzle of the dungeon from the ground up, applying these concepts along the way.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

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