I’m going to talk about game balance specifically in the context of a video game that I made. You can play this game for free in browser, or pay for an expansion. But statistically most of you have not done that, and I’m not telling you to try it. To serve this discussion, I will assume that the player has zero knowledge, and is not interested in playing the game. (I also wrote a design post-mortem, but that assumes you’ve played it.)

In a strategy game, the intuitive meaning of “balance” is that when the player is presented with several options, the options are roughly equally strong. But that’s not exactly right. If every option were equally strong, then player choices wouldn’t matter very much. So the way I think of it, balance is not the end goal, it’s just a means to an end.  The true objective is to present the player with interesting non-trivial choices.  If one option straightforwardly dominates the other options, then player may eventually figure it out, making the choice trivial.

That concludes my context-free discussion of game balance. Balance is a context-dependent idea, and it can be more deeply discussed in the context of a specific game or genre.

My balance objectives

My game, Moon Garden Optimizer, is a single player economic strategy game with zero randomness. The total absence of randomness is a significant design challenge.  If the player finds a winning strategy, then they can reliably execute it 100% of the time, which obviously wouldn’t be very interesting.

This problem is addressed in two ways. First, the game isn’t focused on a binary win/lose state; instead, players are assigned a score. So there’s a high ceiling for how much the player’s strategy can be improved.

Second, the game has variable setup rules. Each game presents the player with 8 cards, and the player tries to figure out a decent strategy using only those 8 cards. With 63 distinct cards, there are about 4 billion distinct combinations, each combination generating a different subgame. Even if the player solves one subgame, there are still billions of other subgames remaining.

In this context, “balance” seems to mean that the 63 cards should be roughly equal in power. But more specifically, my goal is to prevent the player from solving too many subgames all at once. This requires that the cards are neither too weak nor too strong.

For example, suppose I included a card that was very strong. In all subgames that include this card (half a billion, or 1/8th of all subgames), you just use the card and you’ve more or less solved it.

Alternatively, suppose I included a card that was very weak. In all subgames including this card, the strategy is to ignore the card, and use the other 7. This doesn’t directly solve any subgames, but it may make some subgames collapse into one another.  This reduces the number of meaningfully distinct subgames.

That’s the general idea, but there are a couple tricks I can pull to allow strong cards. One method is to give a card self anti-synergy. The more you use the card, the worse it gets. So if the card is available, then yes you use it, but you can’t exclusively rely on it, you have to use the other cards too. In every subgame with that card, the player makes a decision about how heavily to rely on the strong card vs other cards available.

The second trick is to make a card strong, but only when used in conjunction with other cards. There are several cards that basically count how many distinct cards you’ve placed nearby. These are some of the strongest cards available, because I can allow them to be strong without hurting the game.

Managing synergies

Mark Brown once discussed Slay The Spire, arguing that what makes the game fun are card synergies. Synergies make choices more interesting because rather than cards being generically strong or weak, card strength becomes dependent on context. It also adds a lot of depth because, e.g. if there are 63 distinct cards, that’s 63*62/2=1953 distinct pairs that can exhibit synergies or anti-synergies.  That’s not to mention synergies between three or more cards.

Discovering synergies can be an interesting puzzle, but there should be a few caveats. First, synergies are only interesting to discover if they aren’t obvious. Second, the game should continue to be interesting after the synergy has been discovered.

Some of the examples that Mark Brown discusses are really obvious. There’s a card that gives you “strength” and another card that says “This card is affected by strength 3 times”. The synergy is pretty explicit, and not very interesting to discover.  (In fact, the more interesting thing, is that this synergy isn’t actually very good.) This is not the fault of Slay the Spire, but a limitation in Mark’s video—Mark needs to explain synergies quickly, so he highlights the most obvious examples. Most examples are far less obvious, by design.

We might distinguish between scripted synergies, and emergent synergies. In a scripted synergy, cards explicitly call out what they synergize with. Emergent synergies arise without explicitly being named. For example, in Slay The Spire, playing cards is good. Playing a card typically requires drawing the card, and then spending its energy cost. Immediately, this creates a synergy between cards that draw, and cards that have low energy cost.

In my game, there is no such thing as drawing cards, but there is a resource that I call gems. Gems, unlike other resources, get saved from turn to turn. So you can accumulate them over time and spend them all at once. Some cards are cheaper if you build a bunch of them in one turn, so if you accumulate around 90 gems you often just win. The trouble is that the gem storage cap is only 10. This creates a synergy between three classes of cards: Cards that produce gems, cards that increase the gem storage cap, and cards that get cheaper when you build many in one turn. This is a very strong and complex interaction, and that’s entirely by design.  I want the player to jump through a lot of hoops to get there.

Note that I am now talking about synergies between classes of cards, rather than individual cards. For instance, suppose the cards in column A synergize with cards in column B. Individual cards will still all have their nuances that strengthen or weaken the synergy.  But the class synergies fill out the larger texture of the game, often incentivizing the player to seek a mixture of cards from each column.

There are also class anti-synergies. Anti-synergies present the player with a big dichotomous decision. The player makes a choice between column A or column B, even though the two strategies may follow wildly different paths.

When synergies are emergent, that not only makes it harder for the player to identify them, it also makes it harder for the designer to identify or control them. The designer does not have complete control over emergent synergies! So there’s a lot to gain from understanding and refining the larger class synergies, rather than micromanaging every card pair.

But individual card pairs do need some management, because some pairs can be problematic. You can have a “broken combo”, a synergy that isn’t very interesting after you have discovered it. For instance, suppose my game has cards X and Y, whose combo is so powerful that it dominates every subgame they’re in. This allows the player to solve a bunch of subgames at once, roughly 55 million of them. This isn’t a dealbreaker, but it’s undesirable. On the other hand, if a combo requires 3 or more cards, that’s fine because the combo may be difficult to discover, and only comes up in a tiny fraction of subgames.

Data-Driven Design

Next let’s talk about refining the game balance through playtesting. I used an approach called data-driven design, where I recorded data on a bunch of games and used that to inform changes.

This was a small project, so I mainly logged my own games by hand. This is not good practice, it was just a matter of convenience for me. I liked playing my game anyway, so I just used that to collect data and improve the game. At the very least I should have automated data collection, but shrug.

I only recorded a few different pieces of information about each game. First, what cards were available? Second, what cards did I actually use? Third, what was my final score?

To assess card strength, I looked at the average score among all games including that card, and compared to the average score overall. If a card was too far above the baseline, I’d nerf it.  If it was too far below, I’d buff it. But this isn’t necessarily the most important metric, and there’s room for variance.

The more important metric is the percentage of games where I chose to use a given card. Relatedly, how many distinct cards did I use in games including the card? My objective is to generate many distinct subgames, so I want the player to use most of the cards most of the time. If a card hardly ever gets used, it desperately needs a buff, or a complete redesign. If a card generates games where relatively few cards are used, that might mean it’s too strong.

Data-driven design has some limitations. Ideally, a game should be balanced for a wide range of skill levels. If a card seems dominant and boring to beginners, but advanced players understand that it’s weaker than it looks, that’s still undesirable for beginners regardless of what the advanced players think. If most playtesters are a particular skill level, the designer may not see the problems that exist at other skill levels. There can also be broken combos that are not immediately recognized by playtesters, but identified later on.

I also found that the data needs to be versioned. Obviously the whole point of data-driven design is so I can adjust the design. But once I’ve made adjustments, it invalidates older data. So I was always working with small data, supplementing it with subjective experience and theorizing.

It may be obvious that I like to think analytically. Balancing a strategy game requires a lot of analytic thought, more than just playing the game. This was the most fun part of game development in my opinion.