Creating Challenges

Game designers can intentionally hobble one or more of the seven stages to purposely make an interaction more challenging for the player. This is a valuable design tool; to give you an idea of how omissions might create a good challenge, here are some examples:

Omit Stage 3: Many types of puzzles provide players with the goal (Stage 1) and the intention (Stage 2), but hide the means of solving the puzzle by omitting Stage 3: Specify the action. Once the player figures out the secret, it's a trivial task to manipulate the puzzle (Stage 4: Execute the action) to complete the challenge. The game can then give good feedback for the rest of the stages since the challenge has been successfully overcome.

Omit Stage 4: Another standard type of puzzle provides the goal (Stage 1), the intention (Stage 2), and the means (Stage 3), but then the trick is in the execution (difficulty in Stage 4: Execute the action).

This is common for instance among jumping puzzles in the action/platforming genre, where the player can easily see why and how he must complete a series of jumps but may find it challenging to execute the distances and timings without falling to his death.

Omit Stage 5: Have you ever played a game where you activated a switch but were then left with no idea what might have changed in the game world? If so then that was because the game's designer, whether intentionally or not, did not provide any feedback that might have helped you perceive the state of the world after the switch was thrown. This sort of challenge could be good or bad, depending on the context.

Omit Stage 6: Let's build from the above example. What if, after throwing the switch, you'd heard long, deep grinding sounds coming from somewhere down the corridor? It sounded like a large, heavy stone object had moved.

At this point, you have perceived a change in the game world (Stage 5), but may not be able to interpret exactly what that meant -- was it a platform, a door, etc.? This equates to a difficulty with Stage 6: Interpreting the state of the world; in order to interpret the new state, more exploration is warranted.

Knowledge in the Head and in the World

Another important concept put forth by Norman is the difference between "knowledge in the head" and "knowledge in the world," meaning that either the user knows what to do based on what the world is showing him, or he knows what to do based on knowledge that he's brought to the situation on his own. It's important to determine what information you can count on players to already know and what information you must teach them, because getting this wrong can create a situation that unintentionally hinders the player.

In the World

"Knowledge in the world" implies that the game is actively giving a player the information he needs to perform an action, as opposed to expecting him to already know (or leaving it up to him to figure out) without any help from the interface. In other words, the necessary information is already baked into the game world for his reference.

In a GUI, for instance, knowledge of what a widget does can be conveyed in several ways:

• By giving it a text label to describe what it does
• By offering "tool tips" or other context-sensitive help
• By providing visual cues as to how something should be manipulated -- things that can be pressed should look like buttons, things that slide should have a grip icon, things that can be grabbed should have a handle

Concerning game world entities, there are limitless methods of baking in knowledge depending on the specific situation. Some examples:

• In an RTS, don't make the player click and read each unit's property sheet in order to find out whether it can build structures. Instead, design the unit's graphics in such a way that it looks like something that can build structures. A player would know right away if the unit had a saw in its hand or a hammer in its belt.
• In an FPS, don't make the player remember which hotkey switches to the shotgun -- show the available weapons on a HUD along with their associated key mappings[2].
• Friendly NPCs can give hints and tips that ramp up in complexity as the player learns his way around the realm.

Naturally, you'll want to omit knowledge from the world when you're purposely trying to create a challenge for the player. But players are too often challenged by things that aren't meant to be so, such as a ledge that looks accessible but is not, and that leads to frustration -- or even worse, to a perception that your game is clunky, not user-friendly, or has an unnecessarily steep learning curve. Help your players understand the game by baking adequate cues into the game world wherever they may be needed.

[2] If you're scoffing at how ugly this might make your beautifully minimalist UI, you can offer the option to hide that display once he's memorized the necessary keys - that is, once the knowledge has been loaded into his head. In the meantime, he'll thank you for the handy reminders even if they aren't as pretty.