The key to the reasonableness of puzzles is to make their circumstances fit the world you have created. You wouldn’t have malfunctioning nuclear plants in a sword-and-sorcery fantasy game. Nor would you try to summon a magical wizard in a hard science fiction game. Good puzzle design involves looking around the world you have created, and using obstacles, objects, and characters that would naturally occur in that environment. Bad puzzles violate not only this, but potentially several other rules:
“Restore” puzzles
It is unfair to kill off a player for not solving a puzzle, and only then provide him the information he needed to solve it. For example, lets say a player innocently opens an unmarked door and walks into a room. The door swings shut and the room fills with poisonous gas. As he chokes and dies, he sees someone else entering the room wearing a gas mask.
It may be reasonable enough to have a gas-filled room at that point. And it certainly is easy enough for the player to restore (or “undo”) to the point before he entered the room and to find a gas mask. But it is not fair. You gave him no reason to think that opening the door was dangerous ahead of time. Ideally, a player should be able to complete a game without ever having to restore. In this case, you could put a warning sign outside the door, or show tendrils of smoke escaping from under the door, or any of a thousand other ways to avoid putting the player in a position where you say without warning, “Bang! You’re Dead.”
Arbitrary puzzles
Effects should always be linked to causes. Events shouldn’t happen because the designer decides it’s time for them to happen. This happens most frequently when the designer doesn’t want to let the player leave an area until he has solved all of the puzzles there. So he simply waits until the last of these puzzles has been solved, and then magically allows the player to proceed, without explaining how solving that set of puzzles logically led to his new capability.
“Designer” puzzles
Avoid, too, those puzzles that make sense only to the designer. Just because the connections are clear in your head does not mean they will make sense to the player. The best defense against designing these kinds of puzzles is a good testing corps. Bounce your ideas off people. If you have to explain how the puzzle works (or why) more than twice, you should either simplify or abandon it.
Problems also arise when the designer sets out to prove that he is smarter than the player. Perhaps you know some arcane bit of information, or are aware of a little-known relationship between two people or events. It is tempting to make this the core of a puzzle, and when the player fails to solve it, only then reveal the information. Resist this temptation. You are as much the player’s partner as his adversary. He is relying on you to give him the information he needs to play the game. He will admire you more for playing fair than for parading your storehouse of unusual knowledge.
Binary puzzles
Avoid binary puzzles. These are puzzles with “yes” or “no” answers that yield instant success or failure. If you open door #1, you die; if you open door #2, you win. It becomes but the work of a moment to try door #1, fail, restore, and open door #2. This is one of the most common errors that inexperienced designers make. They create “Lady or the Tiger” puzzles that gamers will blow right by without expending more than two seconds of creative thought. In cases where you give the player choices, give him lots of choices, and make it difficult to simply choose, fail, and restore.
“Hunt the pixel” puzzles
With the advent of graphical interfaces, another trap has been created for designers who don’t work closely enough with their artists - the “hunt the pixel” problem. Sometimes an important object on the screen is so small that it is easy to overlook. This is usually created by problems of scale. If the room is large and the object is small, the player may overlook it. Solutions to this problem are to a) Make the object stand out against the background through contrasting color or animation, b) Move the object into the foreground, or as a last resort, c) Make the “hot spot” for the object larger than the object itself. Thus, when the player is “scanning” the screen (running the mouse back and forth across the picture to see what object names light up), he has a better chance of stumbling across the item. This will also help reduce player paranoia, which I discuss elsewhere. It is very unsettling for a player to worry that the reason he can’t solve a particular puzzle is because there is some tiny area of the screen he has overlooked. If he finds out that this is the case, he will get mad at you.
“Restore” puzzles
It is unfair to kill off a player for not solving a puzzle, and only then provide him the information he needed to solve it. For example, lets say a player innocently opens an unmarked door and walks into a room. The door swings shut and the room fills with poisonous gas. As he chokes and dies, he sees someone else entering the room wearing a gas mask.
It may be reasonable enough to have a gas-filled room at that point. And it certainly is easy enough for the player to restore (or “undo”) to the point before he entered the room and to find a gas mask. But it is not fair. You gave him no reason to think that opening the door was dangerous ahead of time. Ideally, a player should be able to complete a game without ever having to restore. In this case, you could put a warning sign outside the door, or show tendrils of smoke escaping from under the door, or any of a thousand other ways to avoid putting the player in a position where you say without warning, “Bang! You’re Dead.”
Arbitrary puzzles
Effects should always be linked to causes. Events shouldn’t happen because the designer decides it’s time for them to happen. This happens most frequently when the designer doesn’t want to let the player leave an area until he has solved all of the puzzles there. So he simply waits until the last of these puzzles has been solved, and then magically allows the player to proceed, without explaining how solving that set of puzzles logically led to his new capability.
“Designer” puzzles
Avoid, too, those puzzles that make sense only to the designer. Just because the connections are clear in your head does not mean they will make sense to the player. The best defense against designing these kinds of puzzles is a good testing corps. Bounce your ideas off people. If you have to explain how the puzzle works (or why) more than twice, you should either simplify or abandon it.
Problems also arise when the designer sets out to prove that he is smarter than the player. Perhaps you know some arcane bit of information, or are aware of a little-known relationship between two people or events. It is tempting to make this the core of a puzzle, and when the player fails to solve it, only then reveal the information. Resist this temptation. You are as much the player’s partner as his adversary. He is relying on you to give him the information he needs to play the game. He will admire you more for playing fair than for parading your storehouse of unusual knowledge.
Binary puzzles
Avoid binary puzzles. These are puzzles with “yes” or “no” answers that yield instant success or failure. If you open door #1, you die; if you open door #2, you win. It becomes but the work of a moment to try door #1, fail, restore, and open door #2. This is one of the most common errors that inexperienced designers make. They create “Lady or the Tiger” puzzles that gamers will blow right by without expending more than two seconds of creative thought. In cases where you give the player choices, give him lots of choices, and make it difficult to simply choose, fail, and restore.
“Hunt the pixel” puzzles
With the advent of graphical interfaces, another trap has been created for designers who don’t work closely enough with their artists - the “hunt the pixel” problem. Sometimes an important object on the screen is so small that it is easy to overlook. This is usually created by problems of scale. If the room is large and the object is small, the player may overlook it. Solutions to this problem are to a) Make the object stand out against the background through contrasting color or animation, b) Move the object into the foreground, or as a last resort, c) Make the “hot spot” for the object larger than the object itself. Thus, when the player is “scanning” the screen (running the mouse back and forth across the picture to see what object names light up), he has a better chance of stumbling across the item. This will also help reduce player paranoia, which I discuss elsewhere. It is very unsettling for a player to worry that the reason he can’t solve a particular puzzle is because there is some tiny area of the screen he has overlooked. If he finds out that this is the case, he will get mad at you.
No comments:
Post a Comment