How to Tune a Simulation Game

(Repost from the SomaSim blog)

A while back I got asked a question about tuning simulation games. Another developer wanted to know: is there a better way than just tweaking and playtesting? They were working on a simulation title of their own, and dreading the cycle of tweaking numbers and playing and tweaking numbers some more, especially since the cycle wasn't very fast - simulation tuning problems tend to only show up after a while of playing, and a turbo mode cheat only gets you so far.

This is something we dealt with recently, as we were balancing (and rebalancing) our game 1849, which is a gold rush era city builder / management tycoon game. So I figured I'd repost my answer here as well, in case it helps someone else in the future.

First, a bit of background: 1849 is all about managing the city's economy. There are about 50 different buildings, and 20 different resources - and each building can produce raw resources (wheat field produces wheat, hunting camp produces leather and meat), convert them (brewery converts barley into beer, gold mine produces gold but consumes pickaxes in the process), or consume them (houses where people live consume all sorts of food and goods resources). On top of that, you have to pay workers' wages at each resource building, so you want to make sure it's not sitting idle, otherwise you lose money. Finally you get money by having houses buy resources and consume them (or by trading with neighboring cities). So most of the game is all about optimizing your resource chains and production logistics, and not producing too little or too much.

During the design phase, we mapped out all resource chains as a big graph, to make sure there were no surprises. I no longer have a photo of that anywhere, but it was exactly what you'd expect: a directed acyclic graph, where each node was a building, and each edge was a resource (eg. wheat edges going from wheat farm to the bakery and to the distillery). We did this to verify that we had a variety of chains from sources to sinks, some shorter and some longer, as well as at least one feedback loop (in our case, iron mine consumes pickaxes and produces iron ore, smelter converts that into iron, and blacksmith converts that into pickaxes, which get consumed again by all mines).

Once we settled on resources and buildings, we had to figure out our tuning values: how much wheat is produced per turn? or how much wheat do you need to make one unit of bread? If the values are too generous, the player accumulates a surplus and the game becomes too easy; if they're too hard, you can fall into a "death spiral" where the player keeps running out of everything, and the workers move out, causing the economy to collapse.

The "brute force" approach would be to just make up some tuning values, and play the game a bunch of times and tweak. That can work sometimes but it's slow, and we wanted to do it much faster. So we turned to the game designer's best friend: Microsoft Excel. :) (And I'm not joking about the "best friend" part.) We built stationary models of a number of test cities - some for small cities, some for large ones, some with specific building combinations in them. By a stationary model, I mean: a model of how much of each resource is produced and consumed on a single turn.

First, there was a master sheet that listed all buildings and all of their tuning values (production and consumption levels, cost, population produced or required):

(click through for a full sized version)

Then there was one sheet per simulated city, which lists all the buildings and how many instances of each we expect to be built:

Each city sheet would then pull tuning values from the master spreadsheet, and calculate all resource consumption and production, as well as how much money you're making or losing, how many workers you need (and therefore whether you have enough houses) and so on. As long as all the numbers stayed around zero, the city was pretty well balanced. If they went too far into positive or negative, they would get highlighted in red or green on the spreadsheet, and it was a signal that this part might need extra attention.

This also made tuning almost instantaneous: if you changed a tuning value in the master spreadsheet, it would propagate intantly to all city spreadsheets, and you can see right away if this helped or harmed any of the test scenarios.

So that's how we did tuning of all buildings and resources together in a single city. Then to set up difficulty progression between cities in a campaign, we did what a lot of tycoon games do: as the player goes through the game, increase sinks and resource consumption, which puts pressure on the player to produce more and more (while also giving them more money to work with). This was also verified with the tuning spreadsheets - we could tune the master sheet and immediately check how that's affecting various cities in a campaign.

Also, there were additional details that turned into additional challenges, like adding one-shot timed quests for the player to complete, but those we usually tuned by brute force, since there were few of them and their effects were not as easy to model in our fairly simple spreadsheet.

Hope this is interesting - and maybe even useful!

Follow me on Twitter at @rzubek