About a task at a tycoon management game that you don’t really try to apply.
Starting something new is usually harder than to keep working on it. It’s the initial motivation you need to find. When I joined the team as the producer, Good Company already had some basic game data in place: There were recipes for modules, some settings for our crafting tables, and even some requirements for the in-game products. At the time of my arrival, the game was already in development for around a year. However, there wasn’t anyone on the team who was primarily responsible for game balancing. Until then, rudimentary balancing had been done by our lead designer Paul. While mainly taking care of the frontend code and game system design, it was hard for him to find the time to balance the game systematically. As a result, the game parameters were very loosely connected. It did not work out when trying to play the game for more than a few minutes.
One of my first tasks after being hired was communicating with potential publishers and getting a publishing agreement done. Good Company made quite an impression due to its design, mechanics, and its visuals. So we’ve received several opportunities for publishing deals. Half a year after being in a lot of exchanges with publishers and eventually signing a deal, we wanted to deliver a version of the game that wasn’t just a collection of systems, and that was properly playable. The problem was that systems changed and developed further, while the balancing remained very shallow and didn’t work in a closed game loop. One day after finishing the work on delivery milestone, we internally agreed to have some playtesting and discussing the next steps. We completed a build on a Friday and had a test run over the weekend before we shared it with our publisher.
Very spontaneously, I decided to dig into the balancing of the missing parts of the game data like sell prices for modules and products, as well as product features. But it was quite a challenge for two reasons: First of all, I’ve never balanced a game from the bottom up. I had my fair share of balancing in MMORPGs, specifically for regional events, sales, and such. But having a management game without an initial system in place was a beastly endeavour. Secondly, I noticed quite early that we were not only missing a system but also the in-game product features were not designed with the overall balancing in mind. For example, when selling a product in the game, you could only sell it at a single price. If players would design better products, they simply wouldn’t gain anything from it. The only option for players to maximize their profit margin was to create the most simplistic products to keep production costs as low as possible.
Over the weekend, we preliminarily closed the gaps in the game parameters and systems, so we at least had a working game loop feature- and balancing-wise. After a test session and a call with our publisher, we realized that we needed someone who’s in charge of balancing. Ideally, it should be someone who is good with numbers and has a thorough understanding of the overall game’s structure. We were in our meeting room, sitting there in silence when I realized that everyone else’s eyes were on me. It became clear that I wasn’t only the producer on this project, but from now on, I was also in charge of game balancing. Like most people on the team, I was going to wear multiple hats. This is how the balancing started.
Fundamentals
I’m far from being an expert in this field. Finding a proper method was a struggle. My first approach was quite a silly one: looking at things top-down and trying to figure out proper settings backwards in the balancing chain. I was looking at what products I wanted and tried to mould the steps it takes into a form until they fit the desired result. Eventually, I realized that it was too much of a struggle that way. At first, it seemed very logical as the declared goal was to sell products and not crafting modules. I quickly realized that the path is the goal. Starting to balance from the bottom and trying to make the game progression fun seemed more important to me. Creating a product had to feel rewarding. But until then, the only reward was the money the player got from selling a product.
Finding the direction in which the balancing had to happen was the first thing. The next one was finding the actual path. The underlying game design defines how the various systems are connected to each other. While working on the balancing, I came across many issues where the system design made balancing the game very difficult. At first, I accepted this and tried to work with what was there. But later, after several iterations, I got more involved in the design process and requested changes that would work well with my balancing process. I will return to this point later, but for now, it’s just important to understand that my process didn’t consist only of finding the right parameter values for an existing system but also influencing the system design in a way, so it offered more options for proper balancing.
After I’ve laid out a ‘roadmap’ for the balancing, which included additional iterations, I had to make some fundamental decisions. The duration of an in-game day has been changed several times during development. It is a central parameter responsible for the entire game’s pacing. Things like the frequency of buying and selling goods were bound to the duration of days. After we found the right cadence, balancing became a lot easier, especially after selling goods became less frequent. Even today, we frequently get requests from players to increase the sell frequency from once a week to a daily basis. The reason why we keep selling on a weekly basis is that an average ingame production line won’t produce enough units within a single day (20 real seconds) to have an impact on market demands. Sales and market demands only work with integer values. You cannot sell half a product. Let’s assume you have a market with a daily demand of 3 units. Your sales depend on the market rating of your product which is within a range of 0.0-1.0. This would mean that any change on your product’s rating smaller than 0.33 wouldn’t have any effect on your sales. This low granularity would make exploiting the system very easy if understood and frustrating if not. Changing a single module in your product’s design must have a noticeable effect on its market performance. Allowing more than 20 products within a single selling period fixed a lot of balancing issues. Of course, a slower selling cadence introduced other issues, since the player only received payments once a week. Still, this change was also quite interesting for the later added challenge levels in which the player should never drop below 0 financially in order to succeed.
Besides the cadence, the other two crucial parameters were the base salary for employees and the pricing of base materials. Finding either would not have been particularly tricky, but finding the right balance between those two was. In other production line games in which you mine your raw materials and don’t have to pay wages, a standstill of the production line has no real negative impact. In Good Company, however, a production line halt means that you are losing money due to running expenses. We moved back and forth between having quite high wages which could lead to bankruptcy when failing to optimize your setup and low wages which didn’t feel that important at all. Throughout the iterations, we’ve adjusted employee wages in a range between 10% and 50% of your total expenses.
Hitting 50% meant that small errors could mean a drastic loss. The 10% area quickly turned out to be negligible, so the player could just spam employees. On the other hand, it meant less potential to increase profits by optimizing the geometrical layout of your production and logistics. Only recently, with the automated logistics, we’ve found a well-working balance. We slowed down the production time and distributed the value gain to be more significant for modules at the beginning of the production chain. We also realized that production efficiency was significantly impacted by the walking distance between workers’ tables and the storages they obtained base materials from. Ideal setup with the storage right next to the crafting table had 0% productivity loss while having the shelf 5-6 tiles away meant a 30% or more drop in productivity. Our goal was to reduce this distance-based productivity loss. Since we couldn’t increase the employee walking speed any further, we increased the time workers spent picking up items and crafting. We doubled the time it took to craft the average module and counterbalanced this by buffing the module values. As a result, the player would require fewer modules in order to make the same quality and quantity of products. At the end of the day we reduced the average productivity loss from 30% to 15% while increasing the maximum profits from 20% to 40%. Having to rebalance the whole game because we changed the cadence, wages, and material costs show how significant it is to get the basics of your balancing right since it affects everything.
Making every step count
We’ve figured out the fundamentals of our balancing, but there was still a long road ahead of us. By that time I’ve established an important design principle: As players try to achieve a goal in our game, e.g. building a profitable production line, there are critical steps the players need to take, and there are steps that are purely optional. For example, in Good Company players are required to design a product and to deal with modules and research in order to progress in the game. These are critical steps. Optional steps are actions or choices players can make in order to play the game in their preferred individual style. For the sake of variety, optional steps are more numerous than critical ones. During playtests and feedback analysis, we found that critical steps should always give the player a significant reward. Optional steps, on the other hand, should feel rewarding, but their overall impact should have a lower impact within the game system. The magnitude of the reward for each step shouldn’t vary too drastically within each of these two categories. That way we can focus the bulk of the balancing effort on the critical path while giving the player a sense of agency.
In the earlier balancing iterations we made the following mistake: Building and selling finalized products was associated with a much higher reward than crafting the modules for said products. At the same time, setting up crafting chains for modules required much more effort on the players’ part than setting up a product assembly. Even if players didn’t bring up this issue directly, we could look at their production lines and see that this part of the game felt off. Designing a product felt rewarding. That reward, however, was diminished by the prospect of having to put in all that tedious work into setting up the production line for the designed product.
We had to find ways to remove the friction from setting up and, more importantly, changing production lines. For that we completely changed the recipes of all modules. Initially, we thought it was a good idea if module recipes would require the modules from previous tiers as input. That way players could reuse previously established production steps and extend their production lines organically as they progressed in the game. It was very similar to the crafting graph in Factorio where each later product was based on previously crafted items. We also assumed that dead-ends in a production graph would be disadvantageous. Eventually, it turned out that it can be quite fun to have dead-ends if you make exploring them more rewarding. In the current balancing iteration, only a very few modules can be used in other recipes. However, they can still be sold or used for research. We’ve introduced another item category we call ‘components’. Unlike modules, they cannot be used in product designs. They are intermediate items that are more widely used in recipes and represent the heart of the production graph. Since they are required in most recipes, it is always a safe bet for the player to optimize their production. In addition to the simplified module recipes, we increased the benefits of researching new modules and using them to upgrade product designs. That way progressing through the research tree became more rewarding, and we increased the motivation to expand one’s production line in order to incorporate newly attained technology.
Driving Factor
Another important aspect was the reward players would get for selling products. In earlier balancing iterations product pricing only consisted of a base price on which players could apply a discount in order to increase their sales or compensate for lower specs on their products. Generally, the interaction between market demands, discounts, and sales worked quite well. But we had another big issue: The base price was also the highest price players could charge for their product. This led the profit margins to be capped within a slim value range. It made overachieving market expectations futile and did not feel rewarding at all. To solve this problem, we changed how product prices are calculated. Product sales are driven by product features which depend on the modules used in a product design. We decided that each feature point should also contribute to the final product price. So the final maximum price consists of the base price plus all price bonuses from product features. After this change players felt compelled to design more advanced products and progress further in the research tree.
The markets in Good Company are changing over time in order to pose new challenges for the player. With each new market phase the feature expectations increase and the demand changes as well. Initially we intended this mechanism to be the main driver which motivated the player to progress continuously. However, it turned out that pushing the player via the market progression led to a frustrating experience. Players felt like constantly being on the clock and having to figure out an efficient production setup while being pressured by increasing market expectations. The required effort for setting up a production line and logistics added to this frustration. Our solution to this was to remove the automatic progression of the market phases. As soon as players would meet certain requirements, they could choose to progress a market to the next phase. This ensured that players could play at their own pace and at the same have the possibility to up the ante if they felt like they wanted a bigger challenge. Entering a new phase is rewarding because products yield higher profit margins and increase the revenue. If a player feels uncertain about entering a new market phase, they have the opportunity to prepare, for example, by overfulfilling the current market expectations of the current phase. It reduces stress while maintaining the challenge and progression.
But this mechanical change also required another complete rebalancing pass on all markets, including campaign levels and challenges. It also affected the earlier mentioned rebalancing of modules, since they now had an additional influence on a product’s price. The feature points a module could potentially contribute to a product now had to be taken into consideration while determining the module’s price. This might sound like we went back to a top-down approach, but actually, we just added a fundamental parameter that had to be taken into account: The monetary value of feature points.
The Extra Mile
In the management game genre players usually want to achieve things beyond what’s required to stay afloat. Those additional steps the player can take are quite easy to balance once the core balancing is right. They are many small things that we often don’t even realize, but they significantly add to the fun of a game. In simple terms, you could describe it as the optimizing part of the game in which you try to push your profit margins even further and gain a better understanding of the game’s inner workings.
In Good Company, you can upgrade workplaces, optimize logistics, reduce walking times, update outdated products with new and more efficient modules, and even get rid of employees and focus more on machines.
All those features are relatively easy to balance if you stick to the following rules: Players should always benefit if they take advantage of these features. However, players who do not pick up on them should never feel like they are at a disadvantage. If this applies, the balancing of those systems is a matter of iterative playtesting and adjustment.
What one should consider in this regard are soft gains and hard gains. For example: When you upgrade a table in Good Company, the hard gain is that you can produce more modules with the same employee within the same time. This would effectively reduce the wages paid per crafted item, which is a measurable benefit.
The soft gain is less measurable and more of a feeling. Two tables of the next tier produce the same number of modules as three tables of the current tier. This allows you to save space, which is not a direct benefit, but as your company grows, space efficiency will become an increasingly important issue.
Changing The Mechanics
Sometimes I got stuck while balancing the game. I felt that some issues were simply not being solvable by adjusting the game parameters alone. The aforementioned market system was such a case. I could try to do my best to balance the market, but without making the market price depending on the features, I didn’t see a way to find a proper pricing model for products. It was necessary to make market dynamics feel right for the majority of players, regardless of their play style. While I was involved in game design discussions, I was not the one coming up with the systems. But lately, it happened more often that game balancing informed adjustments in the game design in order to create a more enjoyable experience.
This didn’t only happen with the market system. It also happened with research. While balancing the research system, we found out that the structure of our research tree was the actual problem. For a long time, we clung to the idea of having a classic branching research tree to unlock everything in the game. Relatively late in the development, shortly before the game was released, we switched to the tier-based system we have right now in which modules are arranged in lanes, one lane per category. The main issue was dependencies, where we required one module or component to build another. With over a hundred modules, at some point, it became hard to keep an overview. So we changed our research tree to just contain modules instead of including every unlockable item. It makes the system simpler to compensate for the number of possibilities as we thought that it would be better to unlock each module at the time when needed and making the research steps smaller. It was done to make it possible for the player to react more quickly to required changes in the production line.
But often it also happened the other way around. We just had to change a system because the system was not working out well. And if this happened, it also meant that the game balance in its entirety had to be adjusted. This pertained most significantly to the middle parts of the balancing chain, so everything between the base and the ‘end’ had to be rebalanced continuously for these changes. Ripping out whole systems also means throwing away a lot of balancing work. What remains is the knowledge you gained from it. Luckily the most significant changes that would have affected the balancing were made quite early.
The Right Tools
Last but not least, I’d like to touch on the tools we used for balancing. What would be an essay on balancing without the mention of Excel? So here we go: We didn’t use Excel. However, we did use the spreadsheets of Google docs. Granted, that’s not a big difference. What is notable, though, is that most of our balancing was done using a Django DB, written in Python. We used Django Templates to analyze data and perform sanity checks. We started this way, and while using our self-made tools has significant advantages, it also has some disadvantages.
The advantage is that you can make complex calculations and present them nicely in a neat format. You work directly within a database that only contains the data you use while everything else is just temporary. We can quickly export the game data to a format which is directly used by our game. So whenever we make a small change, there is no risk when applying it to the game.
The significant disadvantage is that we can not quickly iterate through many quick changes in a short amount of time, and to operate this tool, you need someone who at least has some coding skills.
Final
Luckily anyone involved in the balancing could code, but we sometimes had to iterate quite quickly through the balancing, and that led us to neglect the maintenance of our Django DB.
Eventually, we’ll need to bring it back into a state we can follow up the balancing within this tool as the advantages outweigh the disadvantages in the long run. At some point, we were also able to do some prototyping for our product design system in javascript directly using the data from the DB within a day.
All in all, while it was sometimes stressful balancing the whole game from scratch, it was also a fun and exciting experience for me. I’ve learned a lot more about how to design a decent game just by fiddling and thinking intensively about the numbers that drive it.