[In a detailed design article, Griptonite Games' Jason Bay uses classic usability concepts to break down the gamer's use of in-game weapons, objects, and puzzles, suggesting how this can make everyone build better video games.]
A designer's most
important job is to craft unique and interesting challenges for the player. Too
often though, we discover that players are unexpectedly challenged by aspects
that should be easy or even invisible during gameplay.
These might be the workings
of the user interface, or an in-world interaction that should be a snap to
figure out but somehow just isn't. When these things get in the way of normal
progress, players become frustrated and can stop playing your game altogether.
As developers, we try to discover
these problems early and rework the objects in question until they approach a
better semblance of usability. But the journey from "this sucks" to "hell
yeah!" can take a lot of work and iteration and the goal is often reached
more through intuition than on established process.
Rather than running on gut
instinct, we could benefit from a reliable method of understanding of how
players interact with the game so we can consistently predict potential problems
and adjust accordingly -- before the game ships.
In classic usability book The Psychology
of Everyday Things, author Donald A. Norman describes a system of assessing the
usability of objects by examining the psychology behind how people perform
tasks. Although his discussion is oriented for real-world
objects like doors and clock radios, we can apply his methods
to our game worlds to find out whether each game object is truly intuitive and
easy for the player to learn and use.
In this article, we'll examine how this
idea can be applied to build more intuitive (or more challenging!) objects,
puzzles, GUI controls and other game world interactions.
The Seven Stages of Action
Norman defines that each person goes through seven stages of action when
using an object, from the time he forms his goal to the time he evaluates
whether he's successfully accomplished it:
Stage 1:
Form the goal
Stage 2:
Form the intention
Stage 3:
Specify the action
Stage 4:
Execute the action
Stage 5:
Perceive the state of the world
Stage 6:
Interpret the state of the world
Stage 7:
Evaluate the outcome
You can assess the usability
of any game entity by mentally walking through this list, in order, and examining
whether it's possible for a player to engage in each step. If it seems like a player won't be
able to perform one or more of the steps, then that's a red flag indicating a usability problem you should
address before your design is perfected. Conversely, you can intentionally omit
a step in order to create interesting challenges for the player depending on
which one you leave out.
The Seven Stages in Detail
To help illustrate how you
can check these stages to analyze a game entity's ease-of-use, let's run
through a simple example. Let's say a player thinks the in-game explosions are
too loud (he likes 'em loud, but he's at risk of waking his daughter who's sleeping
in the next room). If we were to analyze the game's Settings menu, what sorts of
things might this player be doing or thinking during each stage of the action?
1.
Form the goal: This is the stage where the user forms the overarching end-goal they'd
like to accomplish. "Here's the
Settings menu. That seems likely to offer an option to lower the volume of the
explosions."
2.
Form the intention: In this stage, the user starts to drill down on
how they could go about advancing toward the goal. "There's a control
labeled 'Effects' -- I'll bet I can manipulate it in some way to affect the explosion sounds."
3.
Specify the action: During this stage the user identifies specific
actions that can be taken. "The 'Effects' control looks like a little
handle on a horizontal track -- it looks like I could grab the handle and drag
it along the track to change the volume. The right side of the rail has the icon of a large speaker and the left side has the icon of a smaller speaker, so I'll drag it
to the left to decrease the volume."
4.
Execute the action: (He grabs the little handle with his pointer and
moves it along the track to the left.)
5.
Perceive the state of the world: In this stage, the user first experiences any
feedback that resulted from his change to the system. "I've dragged the
handle to the left and then released it there. The game played a sample sound effect."
6.
Interpret the state of the world: This is where the user interprets the meaning of
the feedback he received in the previous step. "Now the handle is closer
to the icon of the smaller speaker and the sample sound seemed to be quieter than what I heard in-game
before I moved the handle, which probably means that the explosions will also
be quieter."
7.
Evaluate the outcome: "I wanted to turn down the sound volume, and
that's what I did. Success!"
A typical user would move
through these stages subconsciously in a couple of seconds, but if he isn't
able to smoothly move through each and every one then it can lead to confusion
or frustration. It's your job to make sure that doesn't happen.