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!

How (not) to puzzle a player

by David Mallard

Quests and puzzles are popular features on many MUDs. In some games their completion is a requirement to advance to higher levels, while on others they are an option for the player who wishes to challenge their brain in ways that combat cannot. The quest may resemble something as noble as the Arthurian search for the Holy Grail, or something so simple as returning a lost library book. Whatever the goal, a good quest will test the player's wits, and their patience, as they attempt to find a solution to the problem at hand.

In this article, I will outline some of the types of obstacles that could be placed between a player and the successful completion of a quest. It is easier to point to obstacles that creators should avoid, rather than saying what makes a puzzle good, as by its nature a good puzzle will be original and introduce ideas that have not been used before. I will try not to make absolute statements about what is desirable or undesirable (with one notable exception) - after all, the more varied your puzzles are, the more enjoyable attempting to solve them will be for your players. My aim is not to tell you what to do or to avoid, but to raise some issues that you might wish to consider when using each obstacle in your game.

Obstacles in the player's way

Syntax

Kitty cat jigsaw

Puzzling.

I will get my one absolute statement out of the way first: if a player has the correct solution to the puzzle formed in their mind, have all the required objects with them, and are in the right place, then there should be nothing to stop them from solving it. A player who spends half an hour attempting every possible synonym they can think of for the action they wish to perform is going to come away feeling frustrated and unsatisfied. It is the creator's responsibility to avoid this - ensure that all the synonyms you can think of are covered, and then try to think of some more and cover those as well. If your MUD uses a centralised parsing system (such as the MudOS natural language parser) and the verb you are looking at using doesn't have synonyms that you feel are appropriate, you could suggest their addition to the mudlib coders. It's important that the obstacles in front of the player are part of the game world, not the user interface.

Distance

This is an obstacle that is commonly implemented to some degree - different steps in the puzzle, or objects required to solve it, are located in different areas. They might be three rooms apart, or three hundred. There is an important balance issue to consider when placing elements of a puzzle far from each other - if one group of players on your MUD can travel across distant locations easily (e.g., using a teleport spell) while others must walk room by room, then the effort required to complete the puzzle will be vastly different for the two groups. If this is the case, then you must decide whether this situation is acceptable. You may decide that it is necessary to devise an additional obstacle that will level the playing field. For example, an enchantment might block teleporting into or out of the area.Another possibility is that players may stumble across a magic-leeching creature in the area that has no interest in attacking non-spellcasters. Alternatively, you could intentionally restrict the puzzle to only a certain group of players - the quest may only be available to magi, thieves, orcs, etc.

It is my opinion that distance should not be the most important obstacle in most puzzles. Apart from the issues raised in the previous paragraph, walking long distances can be tedious, and the popularity of complex MUD clients introduces an additional bias in favour of players who use automapping and speedwalking. If you intend to place objects a long way from the place where they are useful, you should also give some thought to explaining why the object has ended up where it is; "to make things harder" works from your side, but the player will need the situation to be logically consistent within the game world.

Combat

This is an obstacle that many creators would find easy to include, as most MUDs are already populated with aggressive creatures. However, throwing nasty monsters (or people) in your players' way will have some ramifications for the puzzle. Firstly, it will reduce the number of players who can reach the puzzle's solution - only the characters strong enough to defeat the creature have any chance of finishing the puzzle. Secondly, binding questing and combat together may displease some players - solving puzzles is pursued by some as an alternative to combat, and it may be better to keep the two separate.

Specificity of solutions

You might ask yourself some questions about how specific the solution will be: If an object is required to solve the puzzle, are you going to code the puzzle to allow similar objects that others have coded to be used? If not, then can you justify the decision in game world terms? For example, if you need to give a bottle of alcohol to a guard and you have coded gin for the task, why won't he accept the whisky that can be bought in the nearest inn? You might account for this by amending the guard so that he expresses a preference for gin at some stage rather than making the player guess at which bottle is the "right" one.

You might also consider broader questions about how many paths lead to the solution of your puzzle: Are there any actions, besides the ones that you have allowed for in your code, that the player could reasonably assume will work? If so, and if you don't intend to allow these actions to work, what reason will you give the player? For example, if the puzzle requires the player to set fire to an object and your code supports using a torch to start the fire, will you also allow magic spells that produce fire to work?

Decisions

Players may be left with a direct choice to make from two or more options. The most simplistic (and horribly unfair) example would be a room with two doors - one leads to certain death, the other leads to the solution. In this case, the player's life is left to chance. A better puzzle would give the player a way of discovering which choice is correct - the traditional instance are the two guardians, one of whom always tells the truth whereas the other always lies. Hints may be subtle, but it's probably worth testing the clue out on people to see how many get it. It is also worth considering whether the player's choice is reversible, or whether there is no second chance. Your answer to this may be partly influenced by the level of persistence you have available in your objects - if the player can come back after the next reboot and start all over again, then choices are never set in stone.

Hidden objects and red herrings

The puzzle can also be made trickier by hiding the necessary objects from immediate discovery, or by throwing in an object that looks important but turns out to be useless. You probably should avoid overuse of red herrings, and ensure that there is a good reason why they turn out to not work. However, a carefully crafted distraction in the right place will leave the player amused and perhaps a little embarrassed when they discover that the actual solution was just around the corner. If the required object is hidden, then things must again make sense: Is it small enough to be inconspicuous? How did it end up where it was hidden? What hints will allow the player to discover the object? Hints should probably exist in a lot of cases, except when something has already made it reasonably obvious that the object is located in that region of the world.

Conclusion

In this short space it has only been possible to touch lightly on some of the issues involved in puzzle generation. My general recommendations to puzzle creators are:

Next month, I will address the process of inventing puzzles, including some methods that can be used to develop innovative challenges, and the issues of difficulty, reward, and sense of accomplishment.


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