# balancing a building game

I'm working on a building game (the usual, build house X to produce resource A, which then lets you build house Y...) and I am now in the stage of balancing the various resource needs and productions.

Since I'm by far not the first person doing this, but couldn't find much practical advise on how to actually do it, I'm asking around: How to do the balancing math?

I thought about using a spreadsheet, but the main issue is not in the pure numbers but in the dependencies - if A then B. How many X are needed for Y to become available and does that fit to the stage of the game I want it to happen?

Which better ways than just playing for hours and tweaking the numbers exist? What approaches do you use to balance your economics games?

The game is a static build-your-village game. "static" means that time is not a factor - buildings provide a fixed amount of resources, not "x per minute". So a house provides housing for some peasants and a farm needs some peasants to work it, providing food.

So the things to balance against each other are resources. One trivial example: Farms need to provide more food than the peasants working on the farm plus the lumberjacks required to provide the wood for building the farm eat.

The goal of the game is resource-optimization. Doing the most with the resources available on the map. It is closer to a puzzle than to a clicker game.

Trivial early-game elements (see farm example) are easy to balance. But once you get into dependency trees (e.g. a 3rd level house needs A and B which are provided by X and Y, who need resources created at X2 and Y2, etc.) my intuition fails. Is X2 and Y2 balanced correctly or should they produce less? more?

I am not looking for specific answers, but for methods to approach this problem in general.

• Balance is a question of what inputs give the desired outputs. In order to propose a method/workflow to balance your game, we need to know what your desired outputs are. What characterizes a "well balanced" version of your game, or what symptoms of "poor balance" are you trying to detect and remedy? – DMGregory Mar 19 '18 at 14:07
• The main purpose right now is to make sure no resources are too easy or too difficult to attain.# – Tom Mar 19 '18 at 16:02
• And how should we measure "too easy" or "too difficult"? Since there's no standard mathematical definition these terms, you'll need to unpack what that means for the game experience you want to create. – DMGregory Mar 19 '18 at 16:03
• I'm asking for general advise, not a specific scale. The exact numbers are going to change anyway during testing. So I don't have a precise definition of "too easy" at this point. – Tom Mar 20 '18 at 7:56
• @Tom here is also a great GDC speech on this topic youtube.com/watch?v=tR-9oXiytsk – Candid Moon _Max_ Mar 20 '18 at 18:27

EDIT: Since you added to your question that the resources are static, I’ll talk a bit about that specifically. I’ll leave the previous answer below the line as it might be useful to other people.

If your resources are static, there is going to be some limiting factor on them. This may be your starting resources or worker count that determine how many generators you can maintain. Those have to be distributed in such a way as to multiply them and invest them in other resources efficiently enough to get to your goal. In such a game there isn’t really “growth” per se, just different configurations and combinations. Like you said it resembles a puzzle more than a management game.

The method of balancing is similar though. First, you determine the win condition (what I called production goal before). This might be a certain amount of resources and/or buildings (e.g. have X free workers and X swords to arm them to overthrow the king). Next, calculate the ideal configuration to reach this goal with your current numbers (e.g. X swords need Y smithies which need Z workers, Q charcoal and V iron, which means you need W mines and R charcoal burners, which require resources and workers again and so on down to the most basic resources). You can partially automate this by using a script or spreadsheet that automatically adds the minimum amount of supporting generators for everything you add manually. Beware of loops (workers come from houses, houses need food, food comes from workers) as they complicate the math quite a bit.

Next, and this step is a bit more difficult, see if that configuration can actually be reached in forward play, i.e. can you get there from your starting resources. It’s possible to have a theoretical end configuration that can’t be attained in practice, because at some point several things require each other and you can’t build either of them first without already having the other. You can pretty much only find out about this through test playthroughs. In other words, since the order you buy things in is relevant, you can’t perfectly infer the solution from the result. Still, as you’ll likely understand your own methods of resource management you should be able to use the optimal strategies (e.g. build level 1 houses, use those workers to unlock level 2 houses which are more efficient, then replace all level 1 houses (or leave just as many as you have resources for them left over that you can’t use anywhere else)). Wherever necessary, add or remove buildings. You now have a new writeup of a solution that you know to work.

Once you have found an optimal or near optimal solution, you can begin to think about tweaking the numbers. Examine your spreadsheets and look for the following things:

• Numbers that stand out or don’t make sense, because those make the solutions unintuitive and harder to find (e.g. you need 200 mines but only one charcoal burner to support a furnace).
• Numbers that are directly proportional but at weird ratios (e.g. one mill supports exactly 3,791002 bakeries which produce enough for 2,1452 houses each), because those will irritate players who like to line up everything to work out exactly. Such ratios can be unavoidable if either multiple resources require the same resource or vice versa or because you want a little overhang, since exact numbers make it too easy to see how many you need.
• Opposite direction: numbers that are too simple. If you can just buy 1 or 2 of everything and the numbers line up, it’s too easy. Introduce small overhangs with simple numbers (one building gives 5, next needs 4 or vice versa) and make multiple things require the same resource in different amounts.
• Numbers that are needlessly large. You should only have big numbers, if it’s one of the basic resources that’s used by so many other buildings that high level production requires that much. If you can divide an entire production line by a natural number, probably do that.

Then consider how strictly you want your players to follow your solution. It’s probably advisable to include a little flexibility here, which means your starting resources (the limiting factors) should be a bit more generous than they have to be for a perfect solution. Also consider what exactly the challenge of your game should be. If it’s about finding the right combinations it might be too easy, as they might only have to build their way up the tech tree and slightly balance the numbers. If it’s about little tricks (like replacing lower tier buildings with more efficient higher tier ones) then this could be completely nonobvious and on the other hand is trivial once you’ve found out you can do it – you’d need several of such tricks to discover. If the challenge comes from different maps providing different starting conditions or supporting different generators, you need to balance these starting conditions against the solution every time.

My general approach is to try and find a single unit to balance for, as this greatly simplifies the mathematics involved. In your case this could be time spent.

Your variables will be something like amount of each resource, number of resource generators, resource gain per time per generator, resource use per time per generator (these two can be combined by using negative numbers), resource cost per generator and time spent. If your game includes something like generator efficiency (e.g. farms produce more/less depending on irrigation/space) assume an average value and wherever it makes sense also assume an average value of generators. The latter can be achieved by calculating the minimum number of generators to generate a stable output of the highest order resource (e.g. if you're calculating swords which need iron which needs ore and coal which needs lumber you can calculate the minimum number of mines, charcoal burners and lumberyards to support one smithy without going into negative production for any resource) and scaling up from there.

Whether you'll stay on the minimum depends on the amortisation rate of the generators, but I'd avoid going down that rabbit hole. Maybe do a second calculation afterwards with twice as many and see how the timing scales. If your game has something like research unlocks you can figure in the one-time cost of these as well, but only do so if the cost is high enough to make a perceivable difference in playtime. Don't try and factor in upgrades that increase production rates for now - if your game has them, just factor them in as a higher average production rate. Only upgrades that make a massive difference should have a place in your equations. You want to balance a game, not write a thesis in mathematics. Replace all variables with constants wherever you can.

Now set a production goal that represents player success and solve the equations for how long it takes to get there. If you don't actually have numbers for all of these things yet, reverse engineer from time by working your way up. How long should the player have to work to get stable tier 1 production lines, how long for tier 2 all the way up to a complete tech tree. By working your way up you already have the numbers for the prerequisites of the higher levels.

Once you've done you can try and experiment with external factors, such as space and terrain. These are usually mission specific, so they're as much a part of level design as systems design.

Now, how long a player should need to achieve something in order for the game to be engaging, that's something you'll need to playtest for and it heavily depends on how much the player has to do during playtime and how interesting the decisions they make will feel. That's where you might consider changing your numbers, for example by reducing the production of some generators in order to increase player actions per time (because they have to build more now) or by making the numbers line up imperfectly so it's not as clear how many buildings are ideal.

You won't ever get around playtesting a lot and with different people, but doing the spreadsheets first can give you a head start on what might make sense.

• Nice, have you published a game like this or are you working on one? – user114632 Mar 20 '18 at 10:50
• @JimmySmith No, I'm just a game design hobbyist with a specific interest in systems design. I guess the small incremental I'm working on at the side counts as a game like this? I actually mostly design tabletop roleplaying games. – Pahlavan Mar 20 '18 at 11:30