« Home | Game for Hire - last chance to submit » | Why we Talk About System - a Manifesto » | Systems Thinking Chapter 3: Cthulu Ate my Game » | Systems Thinking Chapter 2: Green Slime » | Systems Thinking Chapter 1: Introduction » | Magicians of England Playtesters » | Mathematica Revisted » | Game for Hire » | Administrative: Forum for Further Discussion (?) » | Monsters Outside the Polis »

Chapter 4: Fixes that Backfire

Before I start on Fixes that backfire, I want to talk about how I've been using systems thinking to help me clarify my design goals for my current project, Magicians of England.

In Magicians, potential narrative control is represented by poker chips. Players make play choices that either increase their store of chips or reduce it. Adding tension to the story gives you more chips. Resolving tensions takes chips away (but you get to decide how it's resolved). One of the design goals of the game is to create a balancing loop between chips (potential narrative control) and resolution (narrative control exerted). Thus the design is built around a balancing loop. Knowing this gives me a better idea what to look for in the actual play and how to identify the source of the problem when actual play goes awry.

So on to fixes that backfire...

Fixes that backfire are characterized by a problem that goes away when a fix is applied, only to reappear more strongly after a short delay.

Actual Play Example
The only really clear example I can think of to demonstrate fixes that backfire in action is the practice of nerfing in MMORGs. MMORGs often face serious problems of balancing classes and equipment. When one class or item is seen as too powerful, MMORG administrators face a strong temptation to weaken the offending thing. The goal is to re-balance the game so that no one play strategy is optimum. The problem with this is that they almost always weaken it to the point of being unviable, particularly to the most competitive gamers, who are always the ones using it the most. This reduces the number of viable options in the game, further exasperbating the imbalance problem.

Fixes that backfire are all about balancing situations that create pressure for a quick fix. One place I see a potential for fixes that backfire is when a designer slaps a reward mechanic into a game because a certain behavior is perceived as desirable. If the behavior they are trying to reinforce is part of a balancing loop, the fix can easily backfire.

In fact, the archetype diagram for fixes that backfire shows this - a balancing loop that is "short circuited" by the fix:

Labels: ,

Do you have an example of a reward paste that backfires? Even a hypothetical would be helpful. I'm not sure I quite grasp this.

Someone would have to ask... :)

An example that comes to mind is when we used to try and "fix" our D&D campaigns by offering XP rewards for "role-playing" (i.e. acting out non-combat situations). This isn't necessarily a bad thing. In our game, however, we had a delicate balance between people who wanted to act out their character and people who wanted to bash monsters.

One of the unintended results was that the combat player retreated even further into his shell, refusing to take part in many encounters. In this case the fix actually reduced the behavior it was meant to encourage.

It's not a perfect example. I'm actually finding it quite hard to find good examples of fixes that backfire.

Giving greater rewards for challenges solved in an original or creative way can backfire. I had a GM give a 10% bonus to a challenge if it was solved by a creative method. It sounds innocent enough, and a nice way to encourage creativity, but... it lead to players always trying to come the most creative solution to a problem, which in a tactical game like D&D, leads to use of poor tactics just because they haven't been done before. In the short term this was interesting, but in the long term it lead to serious problems in a game system that isn't built for it, and could have bordered on the ridiculous had we not dropped the rule.

Thanks, rogert. That's a good example, and that definitely helps me visualize the problem in a reward cycle (I could see it in the class balancing much more easily).

Post a Comment