Balancing Multiplayer Games - Intuition, Iteration and Numbers

Overview

As games become far more complex, so does the task of balance. This article explores a number of methods used to obtain balance within complex games, concluding by offering some techniques to aid in the process.

The Process of Balance

During my time at Relic Entertainment, we have tested out a number of methods in our attempt to establish balance within our games. The first method is what I believe to be a very traditional gut and feel approach. This approach requires the designer to go through a constant iteration process using player feedback and their own understanding of the game to achieve the final result. The more complex the game, the more difficult the execution of this method becomes. Additionally, this process is inherently subjective, each designer will have their own unique perspective of what feels right and what does not. It then becomes very difficult to maintain a level of consistency if any other designer is ever to take over the effort. This approach can produce great results if you are willing to put in the time and effort, but often times this is simply not possible. Play testing and iterating is also its own unique skill set, as most designers know gathering meaningful feedback from peers or anyone else for that matter is not always a simple task.

The next method attempts to quantify each variable within the game and assign said variable an in-game value. For example, if a unit has only a defense or attack value, we can determine the value of adding 1 defense or 1 attack to the unit by comparing the values against one another. A simple way to compare the unit value in this example is to multiply attack by defense and square the resulting value. This method was adopted from the work of Tom Cadwell, a great reference article can be found here.

Unit A vs Unit B

2D  vs  1D
1A  vs  2A

2x1 = √2 = 1.41
1x2 = √2 = 1.41

The next example shows more variation in a units stats and how that breaks down:

Unit A vs Unit B

4D  vs  4D
4A  vs  8A

4x4 = √16 = 4
4x8 = √32 = 5.66

In this example, we can see that Unit B with 4A and 8D is 1.42 times the value of Unit A with 4A and 4D. If Unit A cost 100 resources, this method would assume the cost of Unit B is 142 resources.

This works fairly well when dealing with very basic systems and interactions but begins to break down as the complexity of the game increases. Additionally, it lacks the ability to quantify inherently subjective values. Despite its challenges and limitations, I believe this approach provides very meaningful insight into the game's mechanics, systems, and interactions. This understanding has greatly improved our capacity to balance the game as we are better able to relate the impact of a change within the complexity of the game.

We spent a great deal of time at Relic trying to completely understanding the relationships within the game entirely through the process of mathematics. I remember days were a group of us would compete to find the best way to formulate unit performance, with countless hours of debate and research in between. I think we later came to realize that although this method had value, it was not appropriate given the complexity of our game. There were too many instances were our numbers looked great in theory but failed in practice. We finally concluded that there had to be some middle ground in how we approached balance, a process that used a combination of mathematics and designer intuition to achieve a state of fair play and meaningful choice.

A Hybrid Approach

After coming to this realization, we sought to identify what pieces of our second method could be combined with the first to create a more balanced approached. This method starts by creating a baseline unit for each unit archetype. Archetypes in Relic's RTS, Company of Heroes 2, include infantry, light vehicle, weapon teams, medium tanks, heavy tanks, etc. In a FPS, archetypes might include carbines, submachine guns, or light machine guns. The next step is to tune each unit archetype until you are satisfied with the way it performs. Try to make all considerations at this point, even if they are roughed in and not completely representative of your final intent or goals. The point is to create a baseline which can be compared to other similar units to get a relative value. This enables the designer to better understand the impact of adjustments throughout the course of development.

The image below demonstrates the value of this approach. Category adjustments will result in positive or negative fluctuations within the Raw Unit Value column. (click to enlarge)

The next image demonstrates the impact of doubling the Conscripts damage, changing the Raw Unit Value from 68 to 96.2. Below I'll explain how this value is converted into a projected resource cost.

Converting Raw Value into Projected Cost

Raw Unit Value is simply a relative comparison of one unit’s value against others, given the variables you choose to compare. When choosing your variables, remember to select values that function within the same systems and mechanics. Otherwise, the value becomes meaningless. In the context of Company of Heroes, unit functionality is based on the same game logic. Infantry move at the same pace, have similar formations, react to weapons in the same manner, etc. We can therefore ignore these variables. Our typical analysis therefore focuses on damage and durability, as these two factors have very direct impacts on the unit’s performance. It is important to note that this step is not seeking to precisely define a unit’s value. Instead, we are more interested in getting a rough idea of how each unit compares; thereby, creating a baseline.

Raw unit value is calculated by taking the root of average damage * effective health; similar to the Unit A/B example above. This value alone is sufficient to compare a unit’s performance. Within the context of an RTS, it makes sense to convert this value into a cost. We use these converted values as a starting point for unit cost but do iterate on these values through play tests and iterations.

On Company of Heroes 2, we choose a value of 240 resources for infantry. This value has a significant impact on pacing; increasing it for example would cause infantry to accumulate slower within the game. For reference, the conversion in COH2 for infantry is done by dividing the unit’s raw value by the raw value of Grenadiers (our baseline for the infantry archetype) and multiplying it by 240.

There are a number of cases where this projected value does not translate well into the game. For example, we found close quarter units to be 25% less efficient then their cost indicated. As such, when we calculated their projected value we took this into consideration and adjusted their cost or performance accordingly. The projected cost is just that, a projection of a unit’s in-game value. Only through play testing and iteration can the real value be determined. This is where the two methods are fused together. The first part of the process attempts to create the baseline, where the second part attempts to test those assumptions and iterate as needed through play tests. By introducing the baseline, we are able to significant reduce the amount of time it takes to get a solid final product. The best comparison to a baseline is an index within a book, it provides you with a quick reference to everything that is included within the bindings.

I think more needs to be said on how some of these iterations occur, but I will likely cover that in more detail in a future article.

Conclusion

Our means to balance is a process which compares relative unit values to create a baseline followed by an iteration process to correct for any shortcomings within the baseline. This enables us to fine-tune and customize each component while maintaining an understanding of the impact of changes within the game.

Interestingly enough, this process has proven itself time and time again. Companies of Heroes 2 players have picked up on even the slightest cost efficiencies or inefficiencies. This in turn resulted in players min/maxing their build order; greatly impacting the meta-game on numerous occasions. If players are able to pick up on these nuances, then it shows that the tool is working in its functionality. It than becomes a matter of how we as designers use this tool and our own design intuition to craft our games.

Link to the original article can be found here.