3 (+1) ways to approach game economy simulations

This article was originally posted on Medium.com, you can find the link here.

One of the most crucial yet overlooked parts of game design is the simulation of game economies. Why do we need economic simulations? The one-word answer to that is — validation — specifically validation of design intent. As creators, we aim to ensure that our game aligns with our intended design concept. This is the same for a game’s economy.

As an economy designer myself, I have always needed help finding reliable resources in this area. However, after working on several games over the years I have identified different approaches to simulations which I aim to translate through this article.

So, what does it mean to have an economic simulation?

It means to have a step-wise journey of the player’s progression coupled with economic activity and content unlocking. The step-wise journey can be in the form of a match, session, or day with limiting factors that gate progression. Upon analyzing these steps we can accumulate resources and predict the player’s journey.

A robust economic simulation helps us to achieve the following :

• Ensure a solid onboarding and player journey to maximize retention

• Understand the value of the player’s time relative to in-game resources and items

• Gate player progression and optimize the periodic distribution of content

• Create pinch points that can drive effective monetization

• Measure the spending depth which can offer estimates of revenue potential

Take an example of a game like Monopoly GO.

• A single game session can serve as the step we measure

• The limiting factor of the session is usually the number of die rolls

• We then measure the progress that can be undertaken based on these limited rolls

• We count the coins, gems, and cards earned and spent.

Upon aggregating this over multiple steps we can get a session-wise and eventually day-wise journey of the player. We then consider the different features that get unlocked in this journey and measure their impact as well. At the end of this, we can get the long-term economic impact of the resources we distribute each session and the costs to upgrade buildings which result in economic sinks.

While this is a simplified example as we get more and more features the simulation gets complex. To manage this complexity we utilize charts and graphs to analyze these long-term trends of economic activity — e.g. source vs sink, player level progression, feature unlocks, completing card decks, and so on.

Now that we understand the need for economic simulations, the next step is to implement them using various tools and methods. From my learnings in economy design, I offer three ways to approach simulations. Each of them has its strengths and weaknesses and can be mixed up to cater to the specific needs of your game. I also have a fourth one which may surprise you.

Approach 1: Spreadsheets

To quote Eric Seufert — “Spreadsheets are corporate poetry; when constructed elegantly enough, they can be used to communicate sophisticated ideas to audiences who wouldn’t otherwise be receptive to details”

The best part of this approach is that the tabular format provides easy readability and structure.

For the most part, I have used Google Sheets for my simulations, while Excel can be used as well. The dynamic nature of spreadsheets means that any change can be seen immediately allowing you to have live simulations with editable inputs.

To utilize this approach in spreadsheets you make your steps as the rows and the resources to be tracked as the columns. The availability of graphs and charts also allows you to visualize the trends of your simulations.

While this might seem overwhelming to undertake, clever use of named ranges and functions can improve readability and be reused as modular building blocks. For instance — I store a single source of all my data as named ranges and export it in other sheets when its needed to be reused. This kind of referencing along with functions that perform specific tasks (e.g. convert gems to gold) allows me to ensure that all my operations in the simulations remain consistent.

The default library of functions provides a robust toolkit to utilize conditionals, lookups, and randomization. As a bonus, the Apps Script API can be used to create macros and custom functions that simply workflow and can perform complex operations.

However, spreadsheets are limited in the amount of computation you can undertake. For most of my complex simulations, I have noticed that beyond 5–15k steps there are significant performance issues like lags, crashes, and long calculation wait times. This limit of steps is higher on Excel as compared to Google Sheets owing to larger cell computation per spreadsheet.

Additionally, not all operations can be performed in this format as you might find yourself limited by the function library (especially functions that require loops). Beyond the functional issues, readability can also be cumbersome when collaborating with others as you are limited to comments and notes.

Approach 2: Machinations

Machinations is a tool created specifically for modeling game systems and economies. I have personally used the free version of Machinations with limited premium access.

Machinations are highly visual, which makes it easier to translate communication across various development teams. The diagrams can be referred to as algorithms for implementing actual game systems.

The function library is quite extensive as well with additional features like Math.js functions, custom variables, and easy graphs. The premium version also offers the ability to export your data as CSV files, multiple sources of data ingestion, and unity integration.

The syntax of the tools in Machinations also aligns well with what is common knowledge in the industry with terms like sources, sinks, and converters. All of these tools are backed by comprehensive documentation as well.

The team at Machinations also provides additional support which is specific to your game’s use cases. They bring in expertise to help you in the validation process of your designs.

Nevertheless, as a free user, you are restricted in the feature usage. To start with all your diagrams are public, there are limits on the number of steps and components that can be used. The step limits and lack of privacy make it difficult to extend your economic designs to bigger systems.

One of the biggest drawbacks of Machinations is the fact that the library is not adequate for complex operations and lookup functions of data are difficult to manage. It is also difficult to track the step-wise data unless you have the option to export CSV files.

Despite the easy learning curve, it is an entirely new tool which means that not all your team members will adopt it simultaneously.

Approach 3: Scripting

If you can leverage some programming know-how, making your custom simulations through code can be immensely powerful. This is my go-to method for larger complex simulations that require non-regular upkeep.

There are several ways you can utilize scripting to create simulations, I will elaborate on what has worked for me.

Being a game designer I am familiar with the Unity game engine and C#. I utilize the property drawers and inspectors as a front end to feed simulation inputs. These inputs include the source and sink at different steps, the number of steps, and the progression levels.

Through editor scripting, one can quickly create buttons that can execute these simulations without pressing play. Loops of operations can be run to model the outcomes and eventually give us results in an exported CSV file.

Loading these CSV files on an analytic tool like Power BI allows the study of a larger set of data. The visual tools in Power BI offer detailed dashboards that are editable and can be shared with the entire team. This approach is highly scalable and can be validated when the game is in post-production/live ops as well.

This approach also offers multiple levels of collaboration. While the source code can be put up on git for multiple editors, dashboards can be shared with a larger team thus creating layers of abstraction.

Scripted simulations can be large-scale scale providing results of over 50–100k steps if written in an optimized way. To get the maximum out of this data, it is best to track both the aggregate results and each of the simulated steps. This gives a wider understanding of the correlations between the results and the trends from each of the steps.

The main challenge in this method is the time it takes to build the infrastructure. The technical entry barrier also means that the economy designer is either supported by a programmer or is adept with the know-how.

Bonus Approach : None

That’s right sometimes not doing simulations may also make sense. Not every system needs to have accurate predictions and quite often it is difficult to entirely simulate complex systems. As long as you track the inputs and the data received from the players, you can understand the impact of your design intent.

It is critical to ensure the consensus of your entire team to not have a simulation system early on in the production cycle. Since creating a system after the game is live can cause an unnecessary production block. Regardless of this decision, there is no substitute for tracking of player data.

In conclusion, simulation systems can be approached in several different ways depending on the requirements of your game and development team.

To summarize -

• Spreadsheets might be apt for ease of collaboration, lower complexity, and editable live simulations.

• Machinations are great for visual communication, quick prototyping, and integration with multiple tools.

• Scripting your simulations makes sense if you need deep customization, larger data modeling, and future scalability.

• Ditching simulation systems can also work as long as you are tracking the inputs and player data effectively.