Game Balance: Solving the Brigadier Problem

5 Galaxy MapOnce upon a time, I built a web-based MMO called Galactic Impact. This was intended to be an async-multiplayer game in the spirit of such classic computer hits as “Master of Orion” and “Pax Imperia”. Build out your home planet, construct colony and war ships, dispatch them to neighboring planets, and respectively, colonize or obliterate them. Essentially 4X in a browser, with 3 hour turns, the ability to queue commands if you weren’t going to be around, and a modest tech ladder (the minimum-viable feature of a tech “tree” :))

Because this was multiplayer, and these games tend to have an exponential growth curve, there were some balance issues with first player advantage, and since it was meant to be an MMO with players signing up any time, this was a major issue. Solving this is what has, in the interim, stymied development on the project. However, during the game’s first small-scale playtest (25 active players), a really interesting situation arose which I think about often while developing and balancing board games. I’ve termed this the “Brigadier Problem”. Here’s what it was, and how I solved it.

My tech ladder was ten rungs tall. Each time a civilization had accumulated enough galactic credits, a new tier of more powerful, efficient ships and other technology became available to them. The stats for each of these ships, I made up off the cuff. Price, speed, crew size and combat capacity were the primary metrics for these ships, where crew size was really of primary import for colony ships and combat capacity of primary import for warships.

Screen Shot 2015-07-05 at 4.59.15 PM
Excerpt from Galactic Impact’s ship-design spreadsheet. Looks reasonably balanced from here.

I thought the stats I had made up were relatively balanced. Combat capacities and crew sizes trended upward with tech level, as did price. The stats all looked good in my spreadsheet. I unleashed the game on 25 incredible volunteers, one of whom, I quickly discovered, was a former World of Warcarft “min-maxer”, someone who grinds on the stats to find the literally optimal combo of tools at every level. His gamer handle is ‘npaw’, and he was really, really good at Galactic Impact.

I started getting offline questions from testers: “Hey! How did npaw get so many ships??” “Is he getting bonus money?” “He stole my homeworld! Is he cheating?”; I would answer: “He timed his attack really well.” “No.” and “No.” This was awesome feedback, as a game designer. Not only did A) people care enough about the game to get worked up and obsessive about in-game politics, but B) skill played an important role in determining success, in spite of several random elements of space combat.

The process by which the game updated “turns” was a cron script running on a 3 hour interval which would shut down access to the game interface; update ship locations, determine the outcomes of any battles caused by queued orders and new ship-to-ship ranges, and calculate new planetary populations based on birth and death rates in particular atmospheres. I expected this script to take longer over time as more and more game elements needed updating, with a view to making iterative optimizations as pieces of code became a bottleneck.

Then something odd happened. The run time of the update script suddenly spiked over a series of days. I saw that npaw had built a quite a few instances of a mid-tier ship, the Brigadier-class ship, instead of just a few of a higher-end ship he was more than capable of building and paying for. This extra ship load is what had caused the update to slow down, but I wasn’t alarmed. The next day, things exploded.

I got a few texts and emails “Hey the update is taking forever, did something crash?” so I dove into the logs. Not believing what I had seen, I checked the front-end (I maintained a neutral fleet of ships to patrol around and keep an eye on things). The galaxy was overrun by Brigadier-class ships. Hundreds had been built overnight (shipyard could turn them out pretty quickly being a mid-tier technology, and players tended to build multiple shipyards on each colony), and calculating their movement vectors and resolving the dozens of resulting complex combats was drowning the server.

In a panic, I tried to figure out why. I went back to the spreadsheet with all the ship abilities, and tried to take a hard look at the balance.

image (2)
(NB: The dip in damage for the Dreadnaught is made up for by a huge number of hitpoints.)

Things looked okay, then it occurred to me to look at some second-degree metrics to try and normalize relative values. I struck gold when I looked at “Damage / $”

Damage / $ graph. Brigadier shows an outsized peak.


Aah! Price-per-unit damage dealt, the Brigadier-class ships were practically the most powerful ships in the entire game, neck and neck with a ship three tech levels higher and nearly ten times more expensive. Clearly a strategy employing disposable Brigadier-class ships was the way to go. npaw had ferreted this out through experimentation, and everyone else had observed and glommed on to his strategy.

I nerfed the Brigadier-class ship by adjusting its damage slightly downward, and adjusting its price slightly upward. The new configuration wasn’t nearly as cost effective, and as the existing overpowered ships were destroyed in the melée, the problem sort of worked itself out over a few rounds. Ever since, I’ve referred to any type of accidental imbalance that lead to unintended player behavior as a “Brigadier Problem”. Obvious when calculated mathematically, and only thinly obscured to seasoned gamers with a keen eye for spotting a good deal.

Getting this type of thing right is vitally important for a board game, as there is ability to “tweak” the stats after it ships (excepting, for a moment, games with a digital tie-in like XCOM or Alchemists). This whole scenario came to mind as I read Seth Jaffe’s Balancing Game Elements post recently. Distilling your in-game economy to hard numbers is absolutely critical if you’re going to get the balance right.

Now, I see posts from time to time where someone (usually not a seasoned designer…) will decry balance because they’re after “imbalanced” gameplay, which I say is horserubbish — imbalanced gameplay is broken gameplay. Asymmetric gameplay, on the other hand, or varying player strengths are incredible mechanisms and can lead to extremely dynamic gameplay. But I think it’s an important distinction, if only from a lexicographic standpoint.

Have you ever encountered a “brigadier problem”, where a set of stats you assigned to some game element turned out to be grossly out of whack? Post to comments!