30 April, 2016
On Google+, Paul Gestwicki suggested a topic: “How about a post on the relative merits of different balancing schedules during incremental development: balancing each feature as it is added, balancing periodically, balancing continuously.”
This seems interesting like an interesting topic, so let me go into some of my personal observations on game balance and when to balance a game.
Paul specifically uses the term “incremental development” which implies that the project is being developed in parts, one added to another. This brings certain assumptions: that one part can be finished and tested by itself. This is a good description of much of modern game development.
Games are complex systems made up of multiple subsystems, which may themselves be made up of other subsystems. So, a role-playing game (RPG) may have an equipment subsystem, a stats subsystem, a combat subsystem, a monster subsystem, an economy subsystem, etc. The economy subsystem may be broken down into a subsystem for earning money, and a subsystem for using/spending money in the game. The subsystem for earning money may include quest rewards, currency from monsters, currency from selling treasures, interest on money deposited in a bank, and so on. And it keeps going, talking about the treasure subsystem, bank subsystem, etc., until we get down to very simple elements like a the concept of “a gold piece” in a fantasy economy that is used within a system rather than being a whole system in itself.
Balance can be difficult because you have to consider how all these subsystems in the game work together. For example, In an RPG, the design and implementation of a subsystem for equipment will greatly affect the combat subsystem of the game and perhaps others. Therefore, a change to equipment will have consequences for how the combat plays out and it is vital that a designer understand how changes in the one subsystem affects the others. We can also see second order effects, such as a change in what treasure a monster drops indirectly affects the combat system because of what gear is available to the player. This means not only considering the consequences in design, but also testing for those differences in how the game actually plays.
In addition to design considerations, it is also important that you have a good method in place to make sure different parts work together on a technical level. Features of the game tend to be designed as specific subsystems, then each subsystem is implemented by a programmer. Especially on larger projects there may be very little interaction between different groups working on individual subsystems, relying on a tech lead or a producer to keep the different parts in harmony. It is often important to have a strong technical design that defines a specific interface between the different parts. But, if you don’t have either good management, a solid interface people follow precisely, or good communication between different programmers or teams you often see the different subsystems not work together as they should. If this happens, balance adjustments are even harder to balance against.
So, let us consider the the three options Paul offered for how to balance a game.
Balancing as a feature is added
The benefit of balancing each feature as it is added is that it precisely defines what you need to balance. Adding the equipment system to an RPG that assumed generic stats before allows you to have a focus for investigating balance. You need to see how this new system interacts with all previous systems as you balance.
Except it’s not quite that easy because a new system could have second or third (or even deeper) order effects; therefore, it’s not enough to simply test the new feature against each of the old subsystems, but you also need to see how the old subsystems interact with each other after being adjusted by the new feature. So, an equipment subsystem may interact fine with the stat subsystem and the combat subsystem directly, but the stat subsystem and the combat subsystem may have some unexpected interaction because of the way the new equipment system works; perhaps some multiplier in the equipment subsystem makes a stat too high which trivializes combat.
As you add more features and more subsystems, the number of systems you will have to test against each other will explode if you are doing proper regression testing on each of the old subsystems. This means that testing will get more and more involved as you go along, until you are likely spending more time testing than developing as the game get complex, particularly for large games. However, this combinatorial effect is likely to happen regardless of when you test.
Balancing periodically has the advantage that you aren’t stuck into a set schedule of testing when a new feature is released. Instead, you can take plan out the a specific time period to test the balance of a game, and you can better schedule the duration of the balance testing. This can help deal with the combinatorial explosion of how subsystems interact as you can focus on the major issues at hand within a limited schedule.
The downside is that this may leave you with a lot of little lingering issues that could add up in the end. A small problem with how your stat subsystem interacts with the equipment subsystem may become a lot more important as you add in a level subsystem and the stats grow to much larger magnitudes. The geometric stat progression that worked well enough when you had a static level of ability suddenly becomes an issue that makes the game unbalanced at the high end.
The extreme of this would be having one balance period: one at the end of the game’s development. In this case, all the systems would be developed and then the game tested for balance. This has the advantage of not prematurely balancing subsystems that will be impacted by future subsystems added to the game. On the other hand, it can make balancing feel like a slog as you have to deal with all the problems at once, and if you’re on a set schedule you may not be able to adequately address enough of the issues to truly balance the the game in the time allowed.
Balancing continuously means that you no longer have to worry about set schedule, but rather have to deal the finite nature of time and development schedules. Having a separate group continuously test the balance of the game on a continual basis means that you test things independent of other schedules related to adding features. Small issues can be found as the game develops and reported to the designers and developers to address.
However, this can cause problems if you don’t also schedule time for the testing to be incorporated into the design and for those changes in design to be addressed in implementation. I’ve had experiences where a quality assurance (QA) department hunts for bugs on a continuous basis, but then the development team is focused entirely on implementing new features. Feedback from testing is always put off until “later”, which usually never comes. This can cause an adversarial relationship between the testers and the developers, where the testers feel the developers aren’t paying enough attention to the issues they discover, and the developers seeing the testers as an interruption to their primary job of implementing new features.
Bonus round: balancing for a live game
Since I have a background in MMO development, I’ll add another wrinkle to balancing a game: how do you balance a live game with ongoing development? This includes MMORPGs as well as mobile games that update on a regular basis.
Balancing a live game adds an extra dimension as you have active players in the game, and imbalances (even perceived imbalances) can create a negative impression of your game. It’s the nature of the game that some players will becomes so invested in your game that any flaw, such as a gameplay imbalance, because an unforgivable sin. Players will demand that issues be address, and any issues addressed will often be
immediately replaced by some other “game-breaking” issue that must be addressed.
There are sometimes major game-breaking problems with game balance that must be addressed sooner rather than later. This is especially true for an unbeatable strategy because of a design flaw or exploits like item duping. These issues often need to be addressed sooner rather than later in order to maintain the integrity of the game.
This is further complicated by the fact that players will often take a self-centered perspective and demand balances based on their individual experiences even if their perceived problems are okay on a holistic level. For example, the player playing a character type that is “scissors” will often complain that “rock” is overpowered and “paper” is fine; in reality, the three may be well-balanced when taken as a whole. And, if this is a competitive game, the player motivations to get any advantage they can is even stronger.
In this case, dealing with imbalances on a periodic or continuous basis takes on an added dimension. Since you are dealing with a live service, it can seem like a continuous balancing schedule makes sense. However, since your playerbase will probably never unanimously agree that a game is perfectly balanced. And, especially if your game is licensed in other markets, it may make sense to balance on a periodic basis where the periods coincide with when content is handed off to the licensee. But, in the case of game-breaking problems, those might be better addressed immediately rather than waiting for the next period of adjustment.
Which is best?
In the general case, I don’t think any one system is universally better than the others. A lot of it depends on the type of game you are making and the type of development team you have. A lone indie working on an action game with few sub-systems, it might make a lot more sense to balance things as new features are added so that they can work in blocks. A live game with ongoing development may need to use a hybrid of continuous balancing for vital issues as well as periodic balancing through patches that can be delivered to licensees.
What do you think? If you are a developer, which do you prefer? As a player, which one makes more sense to you?