Puzzles (Part 2, The Good)

So rather than griping more about what puzzles don’t work in D&D, this time let’s go over making puzzles that do. Last time I outlined four points that I feel make puzzles worthwhile:

Good puzzles challenge players, not characters.

“Challenge the players, not the characters” is something of a mantra around these parts. It refers to the distinction between a difficult encounter in-character versus a difficult encounter out-of-character. An enemy with astronomically high numbers and terrifying powers is a challenge, but one that normally relies on pure luck more than any effort or investment from the players (unless you expect your players to realize this early and flee, which is very rarely a safe assumption). Instead consider an enemy with tricksy powers, an environmental advantage, or a weakness that’s difficult but rewarding to exploit. This becomes more of an exercise for the players themselves, interacting with the enemy via their characters, and it gives their choices some weight that “I need to roll a 16” doesn’t.

To give an example of how this relates to puzzling, consider a room full of lore that the party must translate and interpret to find some important artifact. This is an intellectual exercise for sure, and it seems like a break from running and jumping and fireballing. But if the translation is resolved by a Linguistics check and the interpretation by Religion, it’s no different from any other skill checks except that the bard is good at them. This isn’t a puzzle, it’s a trap where failure causes lost time or story stagnation instead of damage.

Instead give the players something to do. Write the document you want them to read in a text editor, then change the characters around via a substitution cipher. If you’re being fancy, change the muddled text to a fantasy font before printing it. Let the players do the translation instead of leaving it to a roll, and let them perform their own interpretation (and, if theirs is better than yours, steal it). Give them a chance to exercise their own minds instead of their characters’.

If this sounds like more work on your end than adjudicating a die roll, that’s part of designing a puzzle. And if this sounds like it will take more time at the table, good:

Good puzzles take time and/or effort to resolve.

Nobody’s satisfied by a combat that only takes five seconds unless the explicit point is that there’s a huge power gap or extreme luck involved. Similarly, nobody’s satisfied by a puzzle that they solve at a glance. A one-minute puzzle isn’t really part of a session for the same reason DMs don’t schedule a certain amount of time for Monty Python references.

Puzzles that take time but no effort are actually worse: they consume a valuable part of the play session, but there’s no engagement on the part of the players. It’s like fighting the same goblin encounter for the sixth time. Puzzles like this generally require taking rote actions over and over until a solution occurs; examples include a fifteen puzzle and the Tower of Hanoi. The first time a player sees them they’re interesting, but once you’ve solved one you’ve solved them all. The older your players are, the more you can assume they’ve already seen the puzzle and the more likely it is that at least one player has a solution or method memorized.

Most rote puzzles have some more interesting version that let players think instead. If you’re dead-set on having players push blocks around, consider a Sokoban or any of the innumerable sliding puzzles with blocks of multiple sizes like Klotski. Puzzles where the players build towers aren’t as common, but any sort of pentomino usually works.

Good puzzles have points where the players can feel they are making headway.

Players (read: humans) like knowing when they’re doing something wrong or right. If the wizards hits the robot with a lightning attack and it takes extra damage or shuts down for a round, it rewards the player for finding the robot’s weakness and encourages them to try it again. Equal and opposite, if the robot instead takes little damage or immediately responds with a lightning attack of its own, this discourages further lightning attacks but still rewards the players (if they survive) because they’ve learned about the monster. A party should know when their cause has an effect, even if it’s as simple as “I killed the orc, so now we only have to fight three instead of four”.

In a sense, I think this is actually part of the design aesthetic of 4E. Since my first campaign players have asked me “how damaged do I think the enemy is?”, something the rules don’t cover at all. We ended up deciding that a Spot check could give the players a rough idea, and good Spot checks gave more specific health information. In 4E players are allowed to know when a monster become bloodied and vice versa, and healing is more static and thus more predictable.

Puzzles are the same way. This is why mazes are much-reviled even though every DM tries them at least once—there’s no way to know whether a character is any closer to the exit and no sense of accomplishment until the very end. In games where puzzles can span more than one room, a lot of moon logic puzzles fall under this umbrella; the party knows they have the rooster key, but they have no idea whether that’s something they need to open the moon door or if they needs to explore the eastern wing of the dungeon first. The party could be tantalizingly close to the solution (shine light on the rooster key so it crows, turning the moon door into the sun door, which the key opens) but there’s no way of knowing it unless they’ve exhausted their other options. And if they shine light onto the rooster key in another room, they even don’t know which puzzle they’re solving.

If the players shouldn’t know exactly how close they are to a solution, they should be allowed to know that they’re getting closer. Sometimes this works by giving the players a map and letting them see the whole room at once, like the aforementioned Sokoban. When the players have five crates out of six on solution squares, they’re closer than when they only had two out of six. If a puzzle has multiple rounds, each success brings the players closer to a goal and may increase the difficulty to underscore the advancement. It’s about the ability to look back at the puzzle and say “at least we’ve done something” rather than “we’ve been here a half-hour and all we’ve determined is that orange is not green.”

Puzzles with progress also serve a secondary goal in that they make it much easier for you to give hints. A frustrated player has every right to point out that their wizard is very smart and should be able to figure out something about the puzzle. You can say something like “for a second you think you visualize a workable solution, and before your brain gets it muddled with every other possibility you latch onto the fact that this crate needs to be over here” without giving away the whole thing.

Good puzzles let everyone have fun.

Of course a puzzle lets players have fun. That’s why we’re here. The important word in this item is “everyone”. A puzzle is not good if it’s printed in small font on one sheet of paper. This means that one player actually works on it while everybody else strains their eyes trying to catch up. That’s swell if you’re dedicating the cleric to the document of religious lore while the rest of the party explores the room or talks to the ghost librarian, but lousy if it’s supposed to be a task for everybody.

This came into stark contract for me when a player complained about one of my puzzles. To me, it was a puzzle I really liked and one that the party solved after some significant effort. To her, it required a way of thinking that she couldn’t quite follow, so she wasn’t able to participate at all. It was like I’d paralyzed her for an entire combat, or left her to stew for an entire session in a hag’s larder while the rest of the party got to have adventures. A puzzle that only part of the party can solve is not a successful puzzle.

It’s why my puzzles rarely require small handheld props that only one player can manipulate at a time, and why they more often take place on our gaming screen or drawn large on the mat. One well-received puzzle from The Great Tower of Oldechi involved jumping over pits from one side of the room to the other. Though the party was all in one location, half of the players started solving the puzzle from the entrance and the other half started from the exit. When they met in the middle they knew they were onto something. It’s also why I tend to prepare two smaller puzzles rather than one big one, because it lets a player jump from one to another if they’re up against a wall. If the party knows they need to deduce the sequence of two locks before the door opens, it makes perfect sense that a character can cross the room and see what the other lock looks like.

Just as with combat, few puzzles survive contact with the players. There’s a chance that a player blows through the puzzle quickly, or that the party gets stuck early, or that one player you thought would love the puzzle came to the session very hung over. Usually if a puzzle only meets three of the above criteria I still consider it a partial success (but just in case, I try to prepare some variants of the puzzle with varying difficulty in case I need to change my plans—for every puzzle my players end up seeing, I have at least one they don’t).

Now we know what puzzles work and what puzzles don’t, at least theoretically. That still leaves the question of integrating them into the game. In the next post I’ll give some examples from my sessions, touch on reskinning stock puzzles to fit your session, and provide some links to my favorite puzzle sources.

This entry was posted in DMing. Bookmark the permalink.

One Response to Puzzles (Part 2, The Good)

  1. ScottM says:

    I’m looking forward to your next article; puzzles are something I struggle with as a GM. Finding the sweet spot of hard-enough to feel rewarding when you solve it and interesting enough to engage people for that long is tricky.

Leave a Reply

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

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