Is Your Game Accessible?

---

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. Ifyou’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 10.8: 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 10.9: 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 usertesting, 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.

Figure 10.13: Tape from Halo user test: stuck at a broken doorway—note video insert of player's hands trying different control combinations, lower left

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. As we discussed in Chapter 5, 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.

^[3]Bill Fulton, “Making Games More Fun: Tips for Playtesting Games,” Game Developers Conference 2003.

---