Back to index

The copyright situation for this article is unclear. It does not belong to the author of this site. Please see the copyright notice. If you have information about the copyright contact me!

Setting the mind to work

by David Mallard

In last month's article on puzzles I suggested a lot of issues to consider in deciding whether your puzzle provides the right type of challenge to your players, and I listed many of issues that I believe go into making a bad puzzle. This month, the topic I am going to address will be less precise, more chellenging to conceptualize, but infinitely more important - how to go about making good puzzles.


MRI image of a brain

Brains! I need brains!

We should begin by defining what a puzzle is. My Macquarie dictionary provides a nice starting point: a toy or other contrivance designed to amuse by presenting difficulties to be solved by ingenuity or patient effort. The words "ingenuity and patient effort" are worth noting - to require these qualities of the player who attempts to solve the puzzle, you will need to demonstrate them yourself when designing it.

I will offer my own definition of a puzzle in the context of mudding: a part of the game world that requires the player to set their mind to work in order to determine the right course of action. What constitutes a part of the game world is entirely up to you - it may be a single room or character, a large area like a maze, or a broad story arc that spans your globe (or plane). Puzzles can be made from just about anything, anywhere - you just need to search in your own mind for the right ideas!

Let me start with the bad news - I won't be revealing any mystical secret puzzles that you can inject straight into your mud. A good puzzle will require persistence and clever thinking to solve, and by its very definition you will need to find your own original ideas to make them something that no player will have seen before. Riddles copied verbatim from The Hobbit will be unrewarding for hordes of your players. I could fill your screen with categories of puzzles - word puzzles and cryptograms, figuring out mechanical contraptions, mazes and hidden passages, searching and noticing details, getting others to do something you can't, and so on forever. But none of those would give you a puzzle of which you can be certain that no player will recognise as another version of something they encountered in some other game. Instead, I want to suggest ways to approach coming up with your own puzzle ideas, and ways to check that they are good ones.


The object-based approach

I use the term object to refer to any item in the game world - a monster, weapon, door, statue, room or anything else that exists in your world. LPMud coders should be used to this concept, and it seems to be understood intuitively by most other people. In this approach, you pick an object that you would like to base a puzzle around. The objects you base your puzzles around do not need to be valuable or special in any sense. In fact, having a puzzle based around a unique, important object might make it much easier to solve, since many players in the game will know of it by reputation.

Once you have an object in mind, the next step is to decide what the player must do with it. This is the stage where you need to be innovative. If you base your puzzle around an everyday object and then decide that players need to perform an everyday action with it, most players will come to the solution with very little effort. We want to make the player think about how they need to use the object, to be perplexed and confused, to have to think and explore until they find the solution. And once they reach that point, it is important that the player should be able to look back and think, "That was so obvious..."

If you are beginning with an object as the centre of your puzzle, I recommend writing down a list of all the possible uses you (and anyone else you speak to) can think of for that object. Even the simplest of objects tends to have several uses other than the one that it was designed for. Take mirrors as an example - they show reflections, but they can also be used to direct the sun's rays at a target, and they become foggy with condensation when breathed on. Once you have your list of uses, cross off the everyday, mundane ones, and start thinking about how some of those others might be applied (the Discworld adventure game combines both "uncommon" uses for a mirror in one puzzle). Think about what else the player will need to use the object, and then turn your attention to those other things. Links will begin to form between objects, and you will be able to let your puzzle grow outward until you are satisfied that it will give the player a suitable challenge.

The problem-based approach

Rather than having some object in mind that you think would be interesting in a puzzle, you may instead have an abstract idea for a problem that you would like to put in the player's path. Maybe you have invented a riddle that you think is extremely clever, or you know a number game that will challenge them. While using a problem-based approach allows you to put any mind-bending puzzle you can conceive of into your game, it is important that the player does not feel the puzzle was put there just for the sake of it. Puzzles need to relate to the game world and should not seem arbitrary. Therefore, you need to think about objects that may provide a suitable context for your puzzle. People rarely approach strangers in the street and ask them a riddle, so you need to develop a situation where it is logical for the player's intelligence to be challenged. Doorkeepers are one logical (albeit cliched) option. Once you have linked the problem to the world in this way, you can again produce more links that extend the situation. Why is the door guarded, and what lies behind it? From one small puzzle, big things can grow.


Unlike code, which needs to be written before it can be tested, you can begin testing your puzzles from the moment the first seed of an idea sprouts in your mind. I believe it is important that you do this, as what seems a reasonable solution to you might be utterly incomprehensible to others. Thus, testing puzzles is not a solitary task. You will need to explore your ideas with as many people as possible. Talk to your fellow creators as much as possible. Describe the fundamental parts of the problem, and ask them what they would do if they were playing on the mud - they might surprise you by discovering a perfectly logical action that you had failed to consider. You might even decide to add a second path to solving the puzzle, which adds a great deal of flexibility to the game.

Once the code is written and the puzzle is in the game, encourage playtesting and ongoing development. Try to keep an eye on what people are doing when they encounter the puzzle, and how many people are solving it - if people have been consistently failing to find the solution after a period of weeks, then perhaps the solution is not as apparent as you thought. Discovering how people are failing is just as important as determining how many are failing - players may be attempting actions that they believe are a logical solution to the puzzle. In this situation you might choose to add this solution, or you may develop an explanation for why the action fails.


There is no single way to come up with great puzzles. Every time you try to create one it should be different, and the approach you take might be equally different. Whether the initial idea for your puzzle is a game object or an abstract problem, I believe it is important to think about the links between these elements, and to ensure that the puzzle is logical and feels like a part of the game world. I also believe that the only way to be sure that the puzzle will prove an acceptable challenge for others to solve is by testing it before you unleash it on your players. With a thorough approach, a lot of ingenuity and no shortage of patient effort, your ideas can be fleshed out into extremely perplexing puzzles.

David Mallard administrates an LPMud project that aims to make advances in the interaction between human and artificial intelligences. He can be reached at