As you are balancing, you must be keenly aware of how the different values you
change affect each other. You may change one weapon in order to make one combat situ-
ation a lot of fun but end up making another location in the game actually unbeatable.
The more complex your game, the more impact the changes you make may have on
systems you might overlook. As you are balancing you must fully consider every part of
the game that your changes are affecting and make sure you do not break the game. The
only way to be truly sure you have not thrown off the entire game is by testing it thor-
oughly. As a result, making significant changes close to your ship date is a
nerve-racking experience. What if the changes you make break something that no one
catches before the game is sent to the duplicator?
Of course, the method for balancing I have described above necessitates that the
data that affects the behavior of the game’s different entities be accessible and modifi-
able by the designer. This means that the code needs to be written in such a way that
makes changing this information easy. This last point may seem obvious, but I have
seen many engines in which changing information such as weapon statistics was far
from easy to outright impossible. From the very beginning of the game’s development,
the programmers must keep in mind how the designers will go about balancing the
game at the end of the project. If, instead, they bury a collection of “magic numbers” in
the code, the game will become “locked” in a particular state, making balancing it
impossible. Though balancing can only take place once the game is largely complete,
the programming team must start preparing for that balancing from the very beginning
of the project or effective balancing will be impossible. If the designer is to have any
chance of balancing the game well, this balancing information must be broken out of the
code through configuration files, level editing tools, or other designer-accessible
formats.
Your Game Is Too Hard .........................
When I wrote the first edition of this book, I included the following paragraph:
While balancing your game you should keep one rule of thumb in mind
at all times: your game is too hard. Regardless of the type of game you
are making or how talented your development team may be, by the
time your game nears completion and enters testing it will be too hard.Having just completedThe Suffering, however, I can now say that this is not always the
case. Following the “your game is too hard” rule of thumb, we managed to makeThe
Sufferingtoo easy, at least according to the press and many of the fans. This was in part
because we did not allocate enough time to balancing the game, as I mentioned earlier.
Nevertheless, I still think the above paragraph holds a lot of truth, since most of the
time games are too hard when they enter the balancing phase.
Games usually turn out too hard because, up to the point at which testing starts,
only the development team has been playing the game consistently. The development
team has been working on the project anywhere from nine to eighteen months and dur-
ing that time they have honed their gameplaying skills and have become quite good at
the game, probably better than 90 percent of the players who will ever play the game. In
order to keep the gameplay interesting for themselves, the development team has
made the game somewhat challenging for themselves to play, which in turn means it
Chapter 25: Playtesting 495