Tools for Balancing

We have spoken at some length about the act of balancing games. In order to round off this chapter, we are now going to cover some of the techniques that the game designer can use to actually perform this balancing. We will also be exploring some new ideas for balancing games that, even though they are not currently in use, might be useful in the future.

It is beyond the scope of this chapter to go into more than cursory details of these techniques. In some cases, however, they are adequately documented in other places and repeating that information here would be superfluous. Where this is the case, we will attempt to provide pointers to more information on the subject in the appendixes.

Design for Modification

When designing a game, it is sensible to design a core set of rules that the game adheres to and then design the game entities to conform to those rules. This is often a simpler and more intuitive approach than designing entities that each requires its own special considerations. Not only does this make matters simpler when it comes to programming the game ”the developers can concentrate on implementing the core rules and then adding entities on top of those core rules, rather than coding each entity separately ”it also simplifies tweaking the design.

As long as the core rules are balanced, tweaking them slightly will probably not affect the balance in wild and unpredictable ways. However, if each entity adheres to a separate set of rules, then in all but the simplest games, modifying one entity is independent of any of the others, which could potentially cause balance problems.

Take a game such as Ensemble's Age of Empires (see Figure 8.22). All the game entities are governed by the same rules; they have a large set of parameters used to configure those rules to distinguish each entity class. A change to one of these parameters does not require a corresponding code change. During development, the parameters were stored in a Paradox database. This allowed the designers to tweak parameters easily.

Figure 8.22. Age of Empires.

This is an excellent technique to facilitate the easy modification of game balance. Describing implementation techniques is beyond the scope of this book, but this separation of code and data also helps to enforce good development technique. The parameters can be stored in a database during development and then migrated into a custom format for the final release.

Tweaking and Experimental Methods

One of the most important rules to bear in mind is that tweaking parameters randomly is an inefficient and wasteful way to modify balance. A brief digression into correct experimental method is required to ensure that you are making the best use of your time.

The first, and most important, point to remember is to modify only one parameter at a time. Although it may be tempting to tweak a whole bunch of parameters in order to force a result, unless you are extremely lucky, you won't get anything useful. And even if you do, you will have no idea which of the parameter tweaks got you there. Correct experimental method dictates that one parameter should be modified, and then the results should be checked. When initially modifying parameters, don't bother with small changes; Brian Reynolds (of Big Huge Games) suggests doubling or halving the parameter and seeing what it does. From there, you can iteratively move toward the ideal value as efficiently as possible. This makes sense. By changing by such a large factor, you can easily zero in on your optimum setting.

Design Prototyping

Developing a prototype of the gameplay in a simple yet powerful programming language such as Blitz Basic (www.blitzbasic.com) can act as a very useful test bed for new gameplay techniques.

There are two main reasons for using a language such as Blitz Basic for prototyping gameplay instead of a more complex language such as C++. The first of these reasons is the ease of use: C++ is complicated and has a steep learning curve. Blitz Basic is simple and has a low-entry barrier . It's easy to learn and is fairly intuitive for the nonprogrammer. A designer could reasonably be expected to pick up the basics in less than a week, and the benefits of being able to test out gameplay concepts without taking time away from developers are incalculable.

The second reason is that it is always a dangerous practice to code any form of prototype in the same language as the main development. The temptation to incorporate the prototype code into the main project can sometimes be overwhelming and is, without fail, a recipe for disaster.

Future Potential

We're going to finish this chapter with a little bit of a blue-sky wish list that we'd like to see. In the games industry, much effort is expended on new technology, but most of this effort is spent on producing in-your-face flashy results. Plumbing ”the infrastructure and grunt work of development ”just isn't considered as sexy.

Consider this: Manually tweaking parameters to balance a game is, at best, tedious and, at worst, an inefficient use of resources. Although we have not heard of any previous attempts to do so, we feel it would be worth considering the possibility of automating the process to some degree.

In a number of cases, including most of the games that Blizzard Entertainment has produced, the patches for those games have addressed balance issues. One thing that we have considered ”and we know of no companies that have tried this ”is the possibility of collecting gameplay statistics from players and uploading them (with the player's permission, of course) to a central server, where the results from all the players can be analyzed to determine how well the game is balanced. A further feature could be the automatic downloading of any tweaks to the balance to the player's machine.

In a sense, half of the technology is already in place. Many games now feature auto-patching technology that automatically upgrades a game as soon as an update is available. It's not impossible to imagine that this technology could be implemented as a worthwhile investment if it were produced as a reusable module. There is certainly no reason why it couldn't even be used to customize the data downloaded for each player, based on a profile the player specifies: shift the balance to a harder position for the more advanced players, and vice versa for the novices.

Whether any system such as this has been or will be implemented is not clear, but we feel that it would be a useful tool in the game designer arsenal. After all, it's very difficult to get game balance exactly right on the first few passes . A method by which we could continually tweak a game after release with minimal intervention would be an extremely exciting and useful development.

Internal Economy Worksheet

1. If the game involves conflict between opposing forces, are the capabilities of the forces symmetric or asymmetric? If they are asymmetric, in what ways do they differ , and how will they be balanced? By adjusting costs? By changing rules or probabilities to compensate?

2. Will the starting conditions be symmetric or asymmetric?

3. Are the relationships in the game largely transitive, intransitive , or a mixture? Do you intend to assign shadow costs to balance your transitive relationships?

4. Try to devise a payoff matrix for your game, if possible. Do any dominant strategies appear?

5. Are the challenges in the game solvable only by predefined means, or can they be solved by emergent means?

6. Does the game include positive feedback? If so, what features will it include to avoid runaway victory for the first player who gets ahead? A time delay? Negative feedback? A random factor?

7. Is the player's goal in the game to restore, maintain, or destroy a balance of some kind?

8. Do the game's challenges increase steadily in difficulty, or are there peaks and troughs, or spikes, in the difficulty level? If so, where are they?

9. Does the game contain any elements that the player might perceive to be unfair? If the game must cheat in order to provide a decent challenge, can you disguise the cheating in such a way that the player does not notice it?

10. How will the player know what to do next ? What features does the game include to prevent stagnation?

11. To what degree is the player required to micromanage the game? Is the player obliged to look after trivia? Are there mechanisms by which the player can delegate some of these responsibilities to an automated process? If so, can the player be confident the automated process will make intelligent choices?

12. What mechanisms, if any, will there be for changing the game's difficulty level? Hints? Shortcuts? Cheats? A difficulty setting? How will the difficulty setting change the nature of the challenges offered ? Will it make the enemies tougher or weaker, smarter or more stupid? Will it add or remove challenges entirely?