Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
Improving Player Choices
View All     RSS
November 27, 2020
arrowPress Releases
November 27, 2020
Games Press
View All     RSS

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


Improving Player Choices

March 10, 2004 Article Start Previous Page 3 of 3


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.

Figure 7: Medal of Honor

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 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?


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.

Figure 8. Sim City

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,"

3 Bill Fulton, "Making Games More Fun: Tips for Playtesting Games," Game Developers Conference 2003.

End notes


Article Start Previous Page 3 of 3

Related Jobs

The Gearbox Entertainment Co.
The Gearbox Entertainment Co. — Frisco, Texas, United States

Enemy Designer
Insomniac Games
Insomniac Games — Burbank, California, United States

Senior Designer
The Gearbox Entertainment Co.
The Gearbox Entertainment Co. — Frisco, Texas, United States

Senior Game Designer
Lawrence Technological University
Lawrence Technological University — Southfield, Michigan, United States

Assistant Professor of Game Design – Tenure-Track

Loading Comments

loader image