[Game Design] Balance in the Age of Machine Learning

by Blake Propach​

An Introduction to Balance

We’ve all played games that have felt like they had never been tested a single time before getting put on the shelf. Some of us have been lucky enough to fall in love with a game that felt like a strategic masterpiece, maybe simple, maybe complicated, but every part of it felt honed and complete. I personally take balancing very seriously. A truly competitive game is built on pillars that those playing the game expect to be solid. Not all players may be aware of the pillars. In fact, a game is best when no matter what level of scrutiny a player or group assesses it with, it should be just as competitive.

One, choices must matter. If the player is not inputting meaningful choices, they aren’t affecting the game enough to make it more than chance that they’re winning or losing.

Two, these choices should be reasonable. Reasonability for me comes in two steps. I should both understand the question, and the solutions that I have choice of. In an economy game, it should make sense the difference between constructing a resource building for later use, constructing a unit for immediate use, etc. I should have some idea of why I would build a unit before I make it.

And three is why I’m writing this. Choices must be equal. If I were playing some form of chess where I can add any piece to the board at any time, I’d want an equally good reason to choose a bishop or rook over a queen. When an obvious solution appears to a game, it becomes unbalanced.

It’s important to note that when a game is unbalanced, that doesn’t mean the game is inherently less competitive than other games. At the top level of any game, no matter how broken and unbalanced, the playing field is even. The problem with a lack of balance is the lack of choice that is left to the players. If the top ten players of Magic: The Gathering are playing the exact same deck that exploits a certain combo that is impossible to beat, the game is denying those players the choice to play something different, because the power level of all other decks is too far below this new standard.

Trading card games like Magic can constantly adjust and ban cards from their constantly evolving game. Most board game manufacturers do not have the luxury to balance their games after production, so to make a good, unbreakable game prior to print, they must test it extensively, with as many different types of people as possible. My first, second, and third iterations of my games are often broken by game testers on their very first playthrough, games I thought were polished masterpieces. To avoid this tedious process of crafting and recrafting my babies after my friends and family tore them apart, we turned to nonhuman methods.

​
Computer Randomizers

From our first game, Michael and I turned to the computer to solve some of our balancing problems. This was before either of us was confident enough with our projects to share them with anyone other than our close friends and family. It began small, with simple code to run basic randomizer simulations so that we could adjust frequencies thousands of times faster.

The first game we applied this to was a (still unreleased) board game with a randomized board. Unlike Settlers of Catan or similar economy-based board games that start with the same resources scattered in random ways, our game revolved on dice that had a chance to entirely remove certain resources from some starting boards entirely. Additionally, each die was unique, so each needed to be individually balanced against a hundred other unique dice. Each time we rolled the board, it was a different game, and I mean that the game itself was so different that you felt like you were playing a different game. The biggest problem about it (yes, there was an even bigger one than those mentioned) was that one of the win conditions of the game was based on a certain tile type that even had a very small chance never to appear on the board at all. More likely than not, the board randomization would favor one player’s spawn heavily over another’s for this reason.

It’s probably not hard to see why that game hasn’t made it to market yet. But stay with me for another paragraph. Michael created a board randomizer for us, and we had it run a few thousand iterations of the board. Next we defined what a ‘balanced’ board looked like, ‘player favored’ board looked like, and what an ‘unplayable’ board looked like (one where the win condition was not frequent enough to justify the game). We had the computer analyze the percentages of each outcome, and quickly flipped through some board states to look at ourselves which the computer decided were good and bad. In this way, we could very quickly balance and adjust hundreds of dice and set up hundreds of boards in the time that it would have taken us before to make a single physical board.

We now apply this computer randomizing aspect to the balancing process of each relevant game. Panic Buy! is a good example because it has four decks that contain the same cards in differing quantities. To keep with my balancing rules and avoid hypocrisy, I want the game to have meaningful choices. Each turn, players choose one deck to draw cards from that turn. To give the decks variety while keeping them balanced we recreated the decks with a randomizer so that we could quickly deal hundreds of hands and adjust quantities on the fly. We adjusted the quantities of Panic Buy! in their entireties about five times before ever testing the game in person with another person.

​
Machine Learning

We haven’t stopped there with our use of computer tools for balance. Michael has also tried his hand creating weak AI bots to ‘solve’ our games for us.

For Fashion Cents, we created a few bots with different goals. It is a deckbuilding game like Dominion, so we had to worry that certain strategies were not simply better than others. One bot buys as few cards as possible to win, one bot buys as many cards as they can each turn, and others had combinations of those two strategies. It should be noted that at this stage we didn’t implement game logic. It simply bought cards that we assigned expected values to, had it run a simulation until meeting our simplified win condition, and then told us how many turns it took to arrive at that victory.

For Two Old Men Fight on a Glacier, an abstract game I designed where players maneuver around each other in a magical battle of wits to toss the other player off the iceberg, we brought in the big guns. A friend of mine constructed the entire playable game online so that we could play with each other before we had a physical prototype, and we worked with him to build an intelligent bot that not only could play against humans, but consistently beat us. Like a very weak version of Stockfish (the most powerful chess computer in the world, at the time of writing), we played our bot against itself to try to answer the question: Is this game solved? Short answer, we don’t think so. But we wouldn’t know that without the use of computers. We simply don’t have the time or understanding to brute force and solve an abstract game without the help of our mechanical friends.

Implementing computing tools is just one way we’re trying to take our game balance to the next level. If you want to learn more about HFB’s online testing tools and strategies, I’ve also written about that.