Gamasutra is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them. Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Gamasutra: The Art & Business of Making Gamesspacer
View All     RSS
July 28, 2021
arrowPress Releases

If you enjoy reading this site, you might also want to check out these UBM Tech sites:


How to Tune a Simulation Game

by Robert Zubek on 04/24/15 01:43:00 pm   Expert Blogs   Featured Blogs

6 comments Share on Twitter    RSS

The following blog post, unless otherwise noted, was written by a member of Gamasutra’s community.
The thoughts and opinions expressed are those of the writer and not Gamasutra or its parent company.


(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

Related Jobs

Mountaintop Studios
Mountaintop Studios — San Francisco, California, United States

Lead Tech Artist
Fred Rogers Productions
Fred Rogers Productions — Pittsburgh, Pennsylvania, United States

Digital Production Coordinator
Remedy Entertainment
Remedy Entertainment — Helsinki, Finland

UX Designer
Remedy Entertainment
Remedy Entertainment — Helsinki, Finland

Senior UI Designer

Loading Comments

loader image