Sponsored By

The Designer's Notebook: Preventing the Downward Spiral

Veteran design consultant Adams takes a look at mechanisms that send player fortunes down the plughole, as in a losing game of Monopoly, and what steps designers can take to ensure fair and fun play for all.

Ernest Adams, Blogger

May 12, 2010

12 Min Read
Game Developer logo in a gray background | Game Developer

"The rich get richer and the poor get poorer," my father used to say during the last stages of a family game of Monopoly. As he was the only one of us who really understood the strategy of the game when I was a kid, he tended to be the one who got richer.

Eight years ago I wrote a column called "Positive Feedback." In it I explained what positive feedback is in game mechanics: the tendency of a player's achievements to perpetuate themselves and strengthen the player. Positive feedback helps the rich to get richer in Monopoly. But what about the poor getting poorer?

Unfortunately, the terminology is rather confusing, because positive feedback that works against the player isn't called "negative feedback." Negative feedback is a mechanism that tends to keep things in the same place, preventing either growth or decay.

A household thermostat is a negative feedback device. If the temperature gets too hot, the thermostat turns on the air conditioning. If the temperature gets too cold, it turns on the heating. The thermostat tries to keep the air temperature at the same level all the time.

Marc LeBlanc illustrates the concepts of positive and negative feedback in game design very nicely with a combination of racing and combat -- think Mario Kart. If cars can shoot at each other with weapons that only fire backwards, the leader can shoot those behind him and they can do nothing to him.

This creates positive feedback for the leader and he tends to get farther ahead. If the weapons only fire forwards, the leader cannot shoot at anyone, while they're all shooting at him. This creates negative feedback: whoever is in the lead tends to be knocked out of it.

Negative feedback is a useful tool in game design; you can use it to put the brakes on positive feedback. (You don't want to make it too powerful, though, or you'll produce a stalemate.) But this column is about positive feedback in the downward direction: a mechanism that works to diminish, rather than increase, some value. In order to avoid confusion, I'm calling it the downward spiral.

In Monopoly the downward spiral begins when a player has to hand over properties to another player to pay a debt. The primary way that a player makes money is by charging rent when other players land on her property. When she has to give up a property, it deprives her of this source of income, which means that she is less competitive, and less able to deal with future bad luck.

Worse yet, the properties she once owned now belong to someone else, and have changed from being a safe place to stop (when they were hers) to being another place she has to spend money (if she lands on them in the future).

The downward spiral isn't completely bad, but it's depressing. (The Uruguayan persuasive game designer Gonzalo Frasca put this to good use in his brilliant Shockwave game, September 12.) Nobody likes the feeling that they have no chance of winning, and a slow grind down to failure isn't much fun.

I'm going to make some concrete suggestions about how to avoid creating downward spirals, and how to manage them if you must include one in your game.

Suggestion #1: Don't allow negative events (e.g. damage) to impair performance.

The most obvious video game example of the downward spiral occurs when damaged units in a war game fight less efficiently -- firing shots less often or less accurately, for example. When a unit fights less efficiently, it doesn't destroy its enemies as quickly, so it tends to take still more damage, and so on.

In practice, we seldom implement this. Most war games follow Suggestion #1: their units fight at full efficiency right down to the last hit point. Arcade-style fighting games usually work the same way. Otherwise, the first player to make a mistake, or catch a bad break, will probably lose.

Of course, real life isn't like this: a person who has been injured fights far less efficiently than a fully healthy one. There have been a few heroic counter-examples -- men who went on fighting even while dreadfully wounded -- but they are exceptional, which is why those men get medals.

In modern practice, military units try to get wounded soldiers off the front lines as soon as possible. The first reason for this is humanitarian, naturally, but there's a second reason as well: wounded soldiers slow down the whole unit. It's better to have all the soldiers fighting fit, even with one less man, than to have a squad rendered inefficient by the presence of a wounded man. They, too, are trying to avoid the downward spiral.

If you don't allow damage to impair performance, then damage is simply a measure of how close a unit is to destruction. It doesn't feed back into the system. This suggestion applies whether performance is defined as fighting ability, productivity (such as that of a factory), or the performance of a vehicle.

Suggestion #2: Include a repair mechanism.

Suppose that you really want to include a downward spiral for the sake of realism, but you don't want it to ruin the game. Consider a serious game about famine. Hungry people have little energy to tend their crops or their herd animals, so they don't get as much food from them, which makes them even more weak and hungry, and so on.

Eventually a starving person becomes so weak he cannot feed himself even if food is available, and so dies. In a serious game, you would probably want to include this downward spiral as a teaching tool.

You can slow down a downward spiral -- and perhaps even reverse it -- by building in a repair mechanism that tends to restore what the player has lost. In the famine game, this might be the effect of food aid -- if you give enough food to people to restore their health, then they can start producing food for themselves again.

(If you want to get politically controversial, you can also build in the "dependency culture" and create a mechanism whereby aid recipients decide that it's in their better interests to eat free food than to work to grow their own.)

Repair mechanisms work for conflict games too. In simulations of large fighting ships (or space ships), damage usually does impair fighting ability -- guns get knocked out, engines damaged, and so forth. By including a damage control facility that makes running repairs during combat, you can slow or reverse the downward spiral.

In Monopoly, the Go square works as a weak repair mechanism. The player is guaranteed to get $200 every time she passes Go, no matter what else happens. However, in the later stages of the game $200 is so little that it doesn't really prevent the downward spiral.

Suggestion #3: Define victory in other terms.

This is identical to the same item in my earlier column, but the point bears repeating. Even in a combat game, you don't have to define victory in terms of damage done to the enemy, or loss in terms of damage done to the player. If victory depends on a quantity or mechanic that is outside the feedback loop, then the feedback loop doesn't matter so much.

Losing a piece in chess creates a (small) downward spiral for the player who loses it -- she doesn't have that piece anymore and so is at a disadvantage. However, victory in chess is not defined in terms of the number of pieces remaining on the board. It can even be good to lose a piece at times, for strategic reasons.

In a serious car racing game (not Mario Kart!), if the player damages his car, he suffers a performance penalty. This is entirely appropriate. But victory is defined by crossing the finish line first, regardless of the state of the car.

A car can be terribly damaged and still win. This is a basic difference between race games and conflict games -- in race games, damage impairs performance, but there is no feedback loop that affects the victory condition.

Vehicle damage in a racing game doesn't actually create a downward spiral to failure anyway, because it doesn't tend to perpetuate itself. It impairs the car's efficiency, but it doesn't increase the likelihood that the car will be damaged further. It's a fixed disadvantage that doesn't get worse as long as the driver doesn't hit something else.

Suggestion #4: Avoid zero-sum games.

In a racing game, vehicle damage confers a disadvantage to the player, but it doesn't confer a direct advantage to his opponents. It's not like handing over your properties to another player in Monopoly. It makes the player's car slow down, but it doesn't make the other cars faster.

This is because racing is not a zero-sum game. In a zero-sum game, no resource actually leaves the game: every player's loss is some other player's gain. But the car damage takes something out of the game entirely -- aerodynamic efficiency -- rather than giving it to another player.

To put the suggestion another way, when your mechanics take valuable resources away from one player, don't give them to another player.

(Monopoly isn't a zero-sum game overall, but once the properties have been distributed among the players, they are zero-sum. They never go back to the bank. They must always belong to one player or another.)

Suggestion #5: Increase the influence of chance (and other factors).

I mentioned this in my earlier column as a way of limiting the upward growth of positive feedback, and of course it works here too. Backgammon has a weak downward spiral, because pieces that are hit and sent to the bar are not available either to obstruct, or to hit, the other player.

Furthermore, a player with pieces on the bar is not allowed to move any of his other pieces until all the ones on the bar have re-entered the game. This makes it slightly more likely that his opponent will be able to hit him again and send more pieces to the bar (if the first player has been foolish enough to leave himself vulnerable).

However, the role of chance in backgammon is so great that this mechanic doesn't guarantee failure. Having pieces on the bar is definitely a disadvantage, but the probability that more will be sent to the bar specifically as a result of that situation is not very high. A few good die rolls and smart play can easily overcome it.

Here's a more sophisticated example that will be familiar to computer role-players: blood aggro.

For those of you not in the know, "aggro" is gamer jargon for the tendency of monsters to act aggressively; the term is usually preceded by the name of the stimulus that provokes the attack -- sight, sound, the use of magic spells or items, and so on.

Monsters who exhibit blood aggro attack when they detect a character with reduced health nearby (presumably by smelling their blood).

Since the avatar's damaged condition attracts enemies, this tends to result in more damage, and so on in a downward spiral. For this reason, someone named Pteryx wrote to me proposing that blood aggro, at least as implemented in Final Fantasy XI, should be considered a Twinkie Denial Condition.

He argued that blood aggro punishes an inevitable consequence of normal gameplay: health loss. The only way to avoid it is to make sure that you're fully healed at all times, which promotes a very cautious and unheroic approach to playing the game.

However, I don't think the blood aggro mechanic is intrinsically wrong; it's exactly how sharks and other opportunistic predators behave in real life. The feature is just badly managed in Final Fantasy XI.

In that game, according to Pteryx, the monsters that exhibit blood aggro usually appear in mobs, are immune to magic defenses normally used to deal with mobs, and can smell blood a very long way off. All of these factors could have been tuned differently: do away with the mobs, get rid of the immunity, reduce the detection range, or some combination of the three.

You can also establish other factors that override the blood aggro. A smart monster might be lured by the blood, but then see that the injured character is armed to the teeth and accompanied by five big friends, and think better of it.

That's certainly the way creatures like jackals act: the smell of blood causes them to investigate, but their instinct for self-preservation helps to determine whether they actually attack or not.

(That's one of the problems I have with RPG monsters: most of them are suicidally aggressive, and the player has to be ridiculously well-armed to compensate. If the monsters had a few more brains, the players could spend more time exploring and less time buying weapons.)

Conclusion

Monopoly is a well-designed game, but its one big weakness is the downward spiral. From the point at which a player realizes that his position is hopeless, it takes upwards of another hour for him to actually go bankrupt... and that's a rather dull and depressing time.

Downward spirals aren't intrinsically bad if they're balanced properly. Generally speaking, it's better to do without them if you can, but as I've shown, sometimes a game needs to include them. Now you have some suggestions about how to manage them. These aren't commandments; you may find it appropriate to ignore any or all of them. But I think you'll find them helpful.

[Title photo by Kai Schreiber, used under Creative Commons license.]

Read more about:

Features

About the Author

Ernest Adams

Blogger

Ernest Adams is a freelance game designer, writer, and lecturer, and a member of the International Hobo game design consortium. He is the author of two books, Andrew Rollings and Ernest Adams on Game Design, with Andrew Rollings; and Break Into the Game Industry: How to Get a Job Making Video Games. Ernest was most recently employed as a lead designer at Bullfrog Productions, and for several years before that he was the audio/video producer on the Madden NFL Football product line. He has developed on-line, computer, and console games for everything from the IBM 360 mainframe to the Playstation 2. He was a founder of the International Game Developers' Association, and a frequent lecturer at the Game Developers' Conference. Ernest would be happy to receive E-mail about his columns at [email protected], and you may visit his professional web site at http://www.designersnotebook.com. The views in this column are strictly his own.

Daily news, dev blogs, and stories from Game Developer straight to your inbox

You May Also Like