|
Features

Improving Player Choices
Progress
Nothing is quite as satisfying as seeing the choices you make result
in progress. It's part of human nature to derive joy from the act
of advancing towards a goal. The small payoffs along the way are
often sweeter than the final victory. The same is true in a game.
Allowing players to feel they are moving forward is the best way
to draw someone into a game and keep them engaged.
One approach for structuring progress is to design milestones for
the players. These are small goals along the way to the grand goal
of winning. Advertise these milestones to the players so that they
know what they're striving for, and reward them after each accomplishment.
Many games do this well. In Medal of Honor, the milestones
come in the form of missions. They give you a map and let you see
where you're headed and what you have to achieve to get there. This
helps the player feel like they're making progress throughout a
long campaign. The same is true for games that use story to block
out their single-player levels, preparing the player at each step
and setting out clear and obtainable objectives, and then rewarding
the player at the end of each sequence with graphics, praise, and
another chapter of the narrative.
No matter what the game, whether it's an arcade shooter or a simulation,
providing a path for the player to follow gives a sense of achievement.
Be creative in finding new ways to represent progress for your players.
Don't limit yourself to just one system. There's no reason you can't
measure progress in several ways at once.
When you consider the pacing of progress that players can make
in the game, you might also consider the typical amount of time
a player spends with a game. Veteran game designer Rich Hilleman
with Electronic Arts says that their designers plan "mini-arcs"
of about one hour into the overall game progress. This is because
that is what they have found the length of time the average gamer
plays for in a single sitting.
At the end of each mini-arc, the designers try to make sure the
player encounters a "memorable moment" of gameplay, which
makes sure they will return for another play session. These mini-arcs,
when aggregated, form the overall dramatic arc of the game.
|
|
Exercise: Progress
Take your original game prototype. Is the ultimate goal
clear? Is the player always moving towards this goal? Make
sure that you have milestones established along the way.
Does your system help motivate the player to reach the final
goal? Describe how.
|
 |
 |
 |
|
The end
By "the end," we're not talking about when a player dies;
we're talking about the moment when the play completely resolves.
After investing hours, days, weeks, or even months, this is the
instant when your most loyal players deserve a reward for all their
effort.
Multiplayer games have their own reward built in: the satisfaction
of beating the other players, or, if you have created a cooperative,
unilateral, or team interaction structure, the satisfaction of having
worked together to beat the game or the other side.
But what of your single-player game? After all the conflict, struggle,
and time invested, make sure to give the player a satisfying reward.
Too often, the end of all that work is a fluffy animation, where
the hero is showered with praise and adulation. If you're going
for an ending like this, why not build the reward into the story?
Make that animation a moving moment in your hero's quest for whatever
he lacks.
|
|
Exercise: Endings
Is the ending or resolution of your original game prototype
satisfying? If not, how could you make it even better?
|
 |
 |
 |
|
Fun "Killers"
For all your efforts, you may have implemented some features that
"killed" the fun in your original concept. Here are just
a few we've seen come up in first-time games over and over.
Micromanagement
Micromanagement is a classic example of forcing your players to
make decisions that don't feel important. Game designers can fall
into a trap of believing that the more control they give the players
over their universe, the happier they'll be. On some level this
is true. Hardcore strategy gamers love control. They want to tweak
everything and dissect each element of the game. But there is a
fine line between granting your players control and burdening them
with chores.
As a designer, how do you know when you've given them enough? Start
with the basics. Is the task necessary? Make sure the decision the
players are given is not obvious, hollow or uninformed. If it passes
these tests, it still may fall into the micromanagement trap. Micromanagement
takes place when a task becomes repetitive or tedious. If you're
asking the players to make too many small decisions and not enough
large ones, then you have a problem. The best way to know this for
certain is to bring in fresh playtesters. If they complain that
it's too much work or too tiresome, this is a red flag.
The solution in almost every case is to simplify your game. Micromanagement
comes from breaking up a task into too many small pieces. The overall
impact of the combined decisions may be important on a strategic
level, but each individual decision is too burdensome to be worth
the effort. The solution is to combine the micro-decisions into
one macro- decision. For instance, if deploying an army requires
choosing what weapons each unit will use, what supplies they're
going to carry, what form of transportation they'll utilize, and
what route they'll travel, you're probably asking too much of your
players. You can solve this by making some of these choices for
them. Set default values that make sense and leave only the most
important decisions, like what route to travel, up the players.
In addition to eliminating lesser decisions, you can give the players
ways of automating certain tasks, like resource management, troop
deployment, and logistics. This provides players with the degree
of control they desire. Some players may chose to do everything
manually, while others will prefer not to deal with the details.
You'll find that different people want different things from your
game, and the more flexible a system you can provide, while still
keeping the game relatively simple, the better.
|
|
Exercise: Micromanagement
Are there any elements of micromanagement in your game?
If so how can you streamline the choices players make so
that they are not bogged down by unimportant details?
|
 |
 |
 |
|
Stagnation
Some games fall into a pit of stagnation, where nothing new seems
to be happening for a long period of time, choices stay at the same
level of importance and impact.
A common source of stagnation is repetition, where players are
caught doing the same task over and over. For instance, if the players
are forced to fight the same type of battle repeatedly, the game
can feel like it's at a standstill. The players may actually be
advancing in levels or moving closer to their ultimate goal, but
the actions they're performing are so repetitive that they mask
any progress being made. In this case the solution is twofold. First,
you should vary the type of action being performed. Next, you need
to communicate how each action is bringing the player closer to
victory.
Another type of stagnation is a balance of power. For instance,
you have three players competing to conquer the world, and whenever
one player gets ahead, the others gang up and smash the leader down,
thus creating an endless cycle where no one is able to achieve victory.
The solution here is to create a condition that tips the balance
of power so far in favor of the winner that she can defeat the combined
strength of the opposition.
A third type of stagnation is the endless loop syndrome. This type
of stagnation occurs when a game device traps the players in a cycle.
For instance, in a business simulation game, a player may get caught
in a trap where all his profits are being eaten up by debt payments.
No matter how long he plays, he cannot get over this hump. One solution
is to shake things up with an unexpected event, like a windfall
or natural disaster that will either push the player over the hump
or knock him into bankruptcy. Of course, you could also tweak the
game so that players never get stuck in this type of situation.
Give the player debt relief or jack up interest rates--whatever
it takes to move the game in one direction or the other.
The last type of stagnation is where it feels like nothing is happening,
because nothing is actually happening. In other words, no progress
is being made, either because the game is poorly designed or because
there's no clear goal. An example of this might be an adventure
game with a poorly defined objective. The players roam around but
have no idea where they're supposed to go or what they're supposed
to do. In this case, the solution is to go back and design the game
so the objective is clear.
|
|
Exercise: Stagnation
Is there any point in your original prototype at which
the game play stagnates? If so, determine what is causing
this problem--do you have a repetitive loop? A balance of
power? How can you break the cycle and improve the progression
of the gameplay?
|
 |
 |
 |
|
Insurmountable obstacles
Another problem area to avoid when designing a game is insurmountable
obstacles. Despite the name, these may not actually be impossible
situations, they just seem that way to a certain percentage of players.
Whether this occurs because of a dearth of information, a missed
opportunity, or lack of experience or intuition, the result is always
the same: your players wind up banging their heads against the same
obstacle over and over and over. Look at your watch--how long now
before they shut the game off in frustration, never to return again?
Most of us have been trapped by insurmountable obstacles at one
time or another and wound up going in circles looking for that hidden
doorway or secret panel. As a designer: make sure that and the game
has some way of recognizing when a player is stuck and providing
them with just enough assistance to make it past the obstacle without
diluting it's challenge completely. Of course, this is easier said
than done. Nintendo adventure games, such as those in the Zelda
series, are typically good at providing info when players are stuck.
Game characters are placed in strategic spots to provide clues and
other information that will help you overcome the obstacles. Like
with other variables, clues have to be balanced to provide an appropriate
level of difficulty for the players.
Building this kind of intelligence into the game is costly and
time consuming. Sometimes, it doesn't need to be that sophisticated.
In his presentation at the 2003 Game Developers Conference on making
games more fun through user-testing, Microsoft User-Testing Manager
Bill Fulton used an example from the opening moments of Halo
to illustrate how a task that seems obvious to the designer may
seem like an insurmountable obstacle to the player.
Immediately after the introductory tutorial of this first-person
shooter game, your character is asked to follow a guide character
to the bridge of the spaceship you are on. Of course, you do, but
seconds later, the guide character is killed in an explosion right
before your eyes, leaving you trapped behind a partially open doorway
with no guide, and no clue how to open the door.
As part of his presentation, Fulton showed a videotape of just
one of many user tests in which a playtester stumbled around the
corridor, pressing every button on the controller, trying everything
he could think of to open the door, all the while talking out loud
about how he didn't know what to do. This went on for several minutes
until it became clear from his tone of voice that if this player
were at home, he would have given up--only five minutes into the
game. As Fulton pointed out humorously, "I hope you all recognize
this as 'not fun.'"3
The goal of the Halo designers, in leaving you guideless,
trapped behind the door, was to create a sense of confusion and
vulnerability that lasted only a few seconds for dramatic purposes.
They assumed the player would immediately realize the door wasn't
going to open, see the alternate exit to the corridor they had planned,
and be on their way. User-testing proved that most players needed
a little help past this obstacle.
In the final product, a second explosion, timed a few seconds later,
drives the player instinctively away from the half-opened door that
will, in fact, never open. A text prompt pops up showing the player
how to jump over objects, and a carefully designed floor mat points
toward another opening in the corridor. The opening is blocked by
a set of pipes, but if you know how to jump, that's no problem at
all. With just a few modifications, the opening moments of the game
were changed from an exercise in frustration to an exciting scene,
filled with drama and tension.
Arbitrary events
As much as random events can be used to good effect in certain
circumstances, like fortuitous surprises and unforeseen dangers,
badly designed randomness can be the downfall of a game. Many games
involve some form of randomness--we've seen how randomness can affect
combat algorithms in real-time strategy games, and how it can stop
movement mechanics from becoming predictable in boardgames. These
types of randomness add to gameplay.
But there's a big difference between utilizing randomness to change
up gameplay and allowing for totally arbitrary events to disrupt
the player experience. For instance, if you've spent weeks building
a sophisticated character in a role-playing game, and then suddenly
a plague, for which there is no cure, kills your character; you
had no chance to defend yourself, and all your hard work has gone
down the drain. It's hard not to feel cheated. We all know that
life is full of unexpected events, some of which are devastating.
So why shouldn't games include them?
The problem is that, as in life, good surprises are welcomed by
players, but bad surprises are not. So, how can you include random
events that are negative in nature without alienating the player?
Whether it's a meteor storm that levels a city, an economic fluctuation
which bankrupts a company, or a surprise attack that wipes out an
army, you have to make sure it fits into the players' expectations
of the game. Prepare your players in advance for the possibility
of such an event and give them options to mitigate the damage--just
don't tell them when it's coming or how bad it's going to be.
If we take the example with the plague, you should warn the player
about the possibility of diseases, and allow them to purchase an
antidote in advance. If they choose to ignore the warning signs
and take no action, then when the event does come, it's their fault,
and they'll know it.
A good rule of thumb is to caution your players at least three
times before hitting them with anything catastrophic. Random events
that have a lesser impact require smaller warnings, or even no warning
at all. It's fine for a player to learn through experience to expect
events of smaller consequence. But the bigger the impact, the more
of a heads up you should provide. If you follow this rule, the events
won't appear arbitrary, and your players will feel like they are
in control of their destiny.
Predictable paths
Games with only one path to victory can become predictable. Linear
or simple branching structures often lead to this type of predictability.
If you want to add a greater sense of possibility to your design,
consider treating the structure in a more object-oriented approach.
Giving each type of object in the world a simple set of rules for
interaction, rather than scripting each encounter separately often
leads to creative and unusual results.
An example of this type of thinking is Grand Theft Auto III,
which has a level structure and story line that the player can follow,
or he is free to wander the world, stealing cars, committing crimes,
or running a taxi service if that's what he wants to do. While wandering
the world doesn't advance the player very far in terms of the overall
game objectives, it does give the sense that the world of the game
is responsive and unpredictable. At any moment, you might attract
the attention of the police and wind up in an unscripted high-speed
chase. Simulation games are other examples of this type of design--games
like the SimCity series can evolve in many directions, all
based on the choices of the players.
Another way to keep game paths from becoming predictable is to
allow players to choose from several objectives. For instance, in
Civilization III, the player can choose between six paths
to victory: conquest, space travel, cultural advance, diplomacy,
domination, and overall score. Each choice takes careful planning
and will cause the player to weigh each choice anew, making the
game not only interesting the first time around, but extremely replayable.
Simply choose another path to victory and the game takes on an entirely
new twist.
Not every game has to have the scope of a Civilization or
a Grand Theft Auto, but when finding the balance between
too much possibility and too much predictability, it's usually best
to err on the side of greater possibility.
|
|
1 Steve Bocska, "Temptation and Consequences:
Dilemmas in Video Games," Game Developers Conference
2003.
2 Nick Yee, "EQ: The Virtual Skinner
Box," http://www.nickyee.com/hub/home.html.
3 Bill Fulton, "Making Games More Fun: Tips for Playtesting
Games," Game Developers Conference 2003.
|
 |
 |
 |
End notes
|
______________________________________________________
|