Introduction

Our goal at Machinations is to help game development teams gain insights quickly and iterate on their design, empowering our users to craft and simulate intricate game mechanics and economic systems with ease. However, mastering Machinations goes beyond simply understanding its language and features; it requires adopting a whole new mindset.

“By using Machinations diagrams, a designer can observe game systems that would normally be invisible” J. Dormans, creator of Machinations.

Machinations was conceived and developed with a profound understanding of System Thinking principles at its core, and to unlock the tool’s true potential, we must embrace a broader perspective emphasizing interconnectedness, feedback loops, and holistic analysis.

By studying feedback structures within your game your can better grasp how your project might behave as a whole: changes in one aspect can trigger cascading effects throughout your systems. Understanding these connections allows designers to predict and optimize their systems’ behavior, ensuring the desired outcomes. And as you delve deeper into System Thinking, you’ll begin to appreciate the inherent complexities of interactive systems, which further enriches your experience with Machinations.

Moreover, adopting this approach can extend beyond game design and into other domains. Designers who internalize these principles become better equipped to tackle complex challenges in diverse fields such as economics, social sciences, and environmental simulations. This versatility highlights the broader impact and utility of both Machinations and System Thinking.

That’s why, in this article, we will explore the symbiotic relationship between Systems Thinking and Machinations. Presented below is a framework – a method for modeling and simulating complex systems in Machinations.

Also, It’s crucial to acknowledge that all models are inherently imperfect, representing simplified versions of reality. However, despite their imperfections, and considering that the simulation’s purpose is not to be right but rather a tool to identify and enhance optimal courses of action for your projects, some models undoubtedly prove helpful in practice.

Systems Thinking 101

Let’s start with some basic lenses through which Systems Thinking sees the world:

Our world is a collection of Systems: your body, the environment, transportation network, the economy,…
Systems are made up of Subsystems: your body comprises the cardiovascular system, immune system, and so on.
Subsystems work together to create a larger system, often greater than the sum of its parts: you are more than the sum of your cardiovascular, immune, and nervous subsystems.

Systems Thinkers picture the world as made up of Systems. They envision a hierarchy of systems, where systems are made up of subsystems, and these subsystems are often made up of even lower-level subsystems, with low-level subsystems functioning as the building blocks for higher-level systems, everything working together to achieve the objective of the overall system.

In that sense, your game is a big system made up of a bunch of subsystems. From the hardware systems that define server capabilities and graphics to the systems that define player progression, interaction, rewards, game economy, and more. These subsystems come together to create your “Game.”

Why does this matter? Because of the next principle in Systems Thinking, and perhaps this framework’s most important insight for the world:

The structure of a system creates the behavior of the system.

Why is this such a big revelation? Because applied to game design, this approach tells us that the reason the player in your game is “Rule Beating” (exploiting a loophole to gain an advantage) isn’t because they are “bad” but due to some inherent structure/rule in your game.

And the idea that the system’s behavior is caused by its structure puts you in the driver’s seat of the system you are building.

When modeling something in Machinations, and you notice your game system is breaking down – maybe some variables are going outside of sustainable bounds, this knowledge empowers you.

You understand that players’ behavior causing the problem is caused by some inherent mechanics you built, and by changing their structure or parameters, you have the control to change your player’s behavior.

Let’s do a quick recap:

In Machinations we are modeling systems made up of subsystems.
These subsystems interacting with each other and working together create feedback loops that create the behavior of the large system.
If the system is misbehaving (doing things we don’t want it to do) we can change the structure of the subsystems and/or the feedback loops between them to change the behavior of the larger system.

Now let’s apply this knowledge more practically to modeling in Machinations and how to beat complexity when modeling complex systems – such as a game economy.

Luckily you just realized that your game economy system is made up of subsystems, and when modeling a large system in Machinations, it is often helpful to break it up into its subsystems first!

Understanding the hierarchical nature of systems and subsystems can help you masterfully navigate the first step in your modeling process.

Step 1: Gathering information

Gathering good information sets the foundation for good modeling. In this step, you start to understand the project, its various elements, and the expectations of those you are modeling for and agree on a scope of what is to be modeled.

Most importantly, you agree on what questions you are trying to answer by modeling in Machinations.

The purpose of your Machinations model should be to help answer those open questions you identified with your stakeholders.

If we take a game economy as an example, this step usually culminates with some sort of Game Design Document. This GDD outlines:

The questions that need to be answered: the model’s purpose.
The different subsystems of the game economy: player actions, faucets, drains, currencies, game loops, fees, costs, penalties, revenue streams, marketplace…
The different KPIs we aim to measure that help provide the answers to our open questions.

From a Machinations perspective, our KPIs often revolve around the ideas discussed in our article The Design Pillars for Building Sustainable Game Economies – we’ll briefly mention them again later in this article.

Identifying the right KPIs to measure is crucial. In system design, there is a trap we call “Seeking the wrong Goal”. It happens when you optimize a system for the wrong thing because that’s what you think you want.

Imagine you built an entire Machinations model to measure a specific KPI only to find out that that’s not the right metric to optimize for. That’s why you should take your time to define your KPIs. Make sure the purpose of your model is clear and that the variables you want to measure will help answer the questions you’re building your model for.

Why model in the first place?

Why do we model systems? Is it to predict the future? No. Is it to look cool? Maybe.

We model to ask WHAT IF questions.

We model to better understand the driving forces of inflows and outflows of our system.

In truth, models are not great at accurately predicting the future because we have no clue what will actually happen!

There are a whole set of variables that could change and throw your “prediction off.” When we are modeling we are taking a slice of reality, a probability amongst perhaps infinite, and looking to see what happens under these specific conditions and assumptions.

But models are great at helping us understand how our systems will behave in different scenarios. They assist us in making sense of how your player’s behavior in aggregate might affect your system. This allows you to gain insights and make better design choices.

Models help you spot problems and issues before they arise and hopefully resolve them before they become major issues. Preventative medicine is the best! Whether it’s your body or your game system. Usually, when an issue becomes apparent, it’s often much harder to resolve.

So although modeling is not a panacea nor a fortune teller, when it comes to building a complex system (be it your game or otherwise), it’s an invaluable tool to help you build a system that works as intended.

Step 2: High-Level Model

In the first step, you’ve defined the purpose of your model. You know the questions you are trying to answer. You know the KPIs you will measure to help us answer them, and you have an idea of how the model will be used and by whom.

Now it’s time to start building it, and for that, we have a simple recipe to get you started.

Machinations Model Cooking Recipe:

Build the simplest version you can think of to get started
Check-in with your simulation model purpose: does it fulfill the purpose you need?
If not, add another feature to it
Test the feature
Look at your result, and check if your feature fulfills the purpose you need
If not, add a feature, test it, and check purposefully.
Rinse and repeat.

Modeling is an iterative process: we start simple, and we continuously add features until the model fulfills its purpose.

The purpose of your first model is often to validate what’s been agreed upon in the Game Design Document. For example, your first high-level model might answer, “What are all the subsystems of the game economy we should model?”

Building a simplified model that reflects the whole system and the parts to be modeled helps in many ways:

It helps safeguard against miscommunication between you and your team and serves to validate the scope laid out in Step 1
It paints the big picture of the different parts of the system, how they interact, and the different feedback loops that are created through their interactions
It gives you the first insights into the system in question that you have to model

Communicating Complexity

Systems are complex beasts. They can be hard to picture and understand. Words have a hard time doing systems justice because words, by necessity, happen one at a time, while systems have multiple elements being triggered simultaneously.

Visualizing complex systems is one area where Machinations shines. You could model a system using pen & paper, but you lose the immense value the interactivity of a Machinations model brings. It’s a great tool for visualizing your system and communicating to others what’s going on.

It helps you see the stocks (resources) and flows (movements of assets) of your system, as well as how they interact and affect each other.

Other tools (Spreadsheets, Python) model in a continuous fashion. You plug in the variables, and out comes the answer. In Machinations, you can lay your nodes, input your variables and watch the resources of your system flow step-by-step (this is also called discrete modeling).

And when you see your whole system moving together, it hits the mind differently, and it becomes a lot easier to understand and communicate what’s actually going on within your system.

So don’t sleep on the Machinations communication beast!

Step 3: Subsystem Modeling

Once you’ve made the high-level model of your system, you’ll find that there are subsystems that require more detail. More detail means more complexity and more complexity often invites a new set of modeling problems to navigate. But fret not, it’s time to put our systems thinking to work.

We’ve already learned about subsystems and how they combine to create a larger system greater than the sum of its parts.

From building your high-level model, you have a good idea of the individual subsystems making it up. So what do we do next? We begin the same way as before.

Machinations Subsystem Cooking Recipe:

Start to model the subsystems one by one as simple as possible
Check-in with your simulation purpose – does the subsystem model fulfill the purpose you need?
If not, add another feature to it.
Test the feature
Does it fulfill the purpose you need?
If not, add a feature, test it, check with purpose, and repeat.
Do this for every subsystem.

Initially, these subsystems might remain within the same diagram, but whenever you have complex subsystems that warrant a lot of detail, you can build them in a new Machinations diagram.

Your node limit is dependent on your CPU power and the lag you experience, but let’s say once your diagram is between 250 -500 components and still increasing, you might want to start thinking about separating them into different diagrams. The rule to remember is that you want to optimize and adjust your workflow so that your models are easy, fluid, and load quickly.

How do we connect different Machinations diagrams?

When you have a sufficiently complex system, you may have a number of Machinations diagrams and wonder how to connect them.

Your subsystems interact with and affect each other through information flows.

So we take the KPI output of one diagram and use it as input for the next machinations diagram.

Like individual rivers flowing into a lake. We have individual Machinations diagrams of subsystems flowing data into the larger system diagrams.

This starts to paint the hierarchy of systems within your system. Whether it’s a game, an economy, or your body, there is an inherent, natural hierarchy that emerges from its structure, encompassing low-level subsystems to larger systems.

Model Boundaries & Abstraction

How do you know what to include or omit in your model? Where are the boundaries of your model, and what is acceptable to remove or abstract away?

Limiting the systems/subsystems you are modeling based on the questions you are trying to answer is the way to go: your goal is to minimize complexity as much as possible while keeping the variables, actions, and feedback loops that impact your KPIs.

This is why we start simple and keep iterating and adding features to the model until it fulfills its purpose. It’s also a lot easier than making a behemoth of a model only to go back and have to change it.

So how much should be abstracted? It depends on what you want to measure.

If you are modeling a game economy, your concerns should be all of the actions users can take that will affect the economy, including all sources and sinks of resources and currencies you are trying to model. Anything else that doesn’t affect the economy of your game, you can abstract away.

It’s both an art and a science to understand how much to abstract and where to put the boundaries on your model. It gets easier with experience, but if you keep checking with the purpose of your model as you build it and ensure that what you are modeling directly impacts the KPIs you care about, you should stay within the reach of any tangent.

Our recent article on Managing Complexity within Machinations does a great job of highlighting a few key insights that help us understand why managing complexity and abstraction is important:

Complex models take longer to build
Complex models are harder to rework
Complex models are harder to understand
More complex doesn’t always mean more accurate
Payoffs in accuracy diminish as complexity increases
Complex models can slow your simulations

Step 4: Single User Group Model and Persona Logic

First, let’s have a quick recap:

Systems are everywhere, they’re made up of subsystems, and you’re modeling systems in Machinations
You’ve defined the questions that you want to answer with your model and identified the KPIs that will help you answer them
You’ve built a high-level model, and your team approved it, confirming the subsystems you want to model
You are now building out your subsystems with the right level of abstraction and boundaries by focusing on the actions that affect the KPIs you’re measuring.

Once you’re done you may wonder: what do I do now with this model?

Well, it’s time to model the behavior of a single user group.

By modeling a single user group we mean to model the set of actions and decisions made by a single user group. These actions have an impact on the KPIs we are trying to measure. In our model, the input is the user behavior, and the output is the KPIs you’re measuring for that specific user group.

What do we mean by single user group? Well, each system will have different kinds of users – we might call them player personas in the gaming industry or stakeholders in Web3 economies – And different user groups have a different probability set of actions and choices they make based on their kind of behavior and core drivers that motivate them.

Adding User Persona Logic

User Personas constitute the different user groups, their actions, and probabilities of being triggered. Imagine a table where we’ve defined different personas and the various player actions that affect our KPIs, and have assigned them a value based on outcome/probability or random intervals. It might look like this:

We begin by modeling one user group at a time. Each user group will change certain probabilities and values within our model. This will give us the KPIs based on that group’s specific actions/probabilities and show us the effect each user group has on the core loops/relevant mechanisms of the system we are modeling.

Ultimately all of the data we have collected per user group will act as the input for the next step in our modeling process.

Feedback Loops

Now it’s time to put on your Systems Thinking cap again and discuss one of the core structures of systems: Feedback Loops.

We all got them!

Our body → homeostatis. The themostats → keeping it cool.
The game → rewarding player achievements. The digital economy → providing yield on your staked tokens.

Feedback loops are an integral part of any system, and they occur because of how the parts of our system are interconnected. I.e., The behavior of one subsystem often affects the behavior of another. These relationships are usually responsible for the complexity that emerges out of complex systems. They are also present between different user groups.

Ex: A game introduces an overpowered item, skewing gameplay. Players, forced to use this item to compete, grow dissatisfied with the stifled strategy diversity. This dissatisfaction leads to an exodus of players or reluctant adoption of the dominant strategy, reinforcing item overuse. If unchecked, this destructive cycle could diminish the game’s player base and reputation.

Often these relationships are nonlinear. A 1% increase in one subsystem can lead to a much larger response in another. Just think about the ocean temperatures and how a few degrees of change can have such huge effects on other subsystems within nature.

Optimizing feedback loops to be sustainable and resilient to changing conditions is where the bulk of your work as a Machinations modeler lies. Remember that by changing the system’s structure, you can change its behavior. And feedback loops are one of the most important points of intervention for changing the behavior of your system.

Now, you should be particularly concerned about these two types of feedback loops: the REINFORCING & BALANCING feedback loops.

These two loops work together to create a balanced system. On its own, a reinforcing feedback loop reinforces the current trend. Unchecked, it leads to exponential growth or runaway collapses. And It’s a no bueno for sustainability! This could mean continuously rewarding the best players with the best gear, over-spawning crucial resources in some parts of your game map that low-level players can’t easily access, preventing them to farm that location and reach that same gear level, etc….

It leads to a system trap our world has fallen deeply into and currently finds it hard to extract ourselves from, known as “SUCCESS TO THE SUCCESSFUL”.

If the winners of a competition are systematically rewarded with the means to win again, a reinforcing feedback loop is created by which, if it is allowed to proceed uninhibited, the winners eventually take all, while the losers are eliminated.

Luckily we have some solutions that go by the name of Balancing Feedback Loops. These loops are goal-seeking, regulating loops. They keep things within a range of values and oppose the current direction exacerbated by the reinforcing feedback loop. They are like what Robin was for Batman, bringing him back from the edge of darkness time and again.

Often, in your models, you may try to balance resources given to your users or manage supply and demand within your in-game economy. To begin, you entice users with reinforcing feedback loops (the more your players do this, the more reward they get), but you cannot endlessly reward users, and you should not endlessly create resources in your system. It needs to be balanced somehow. And this can be as simple as:

Adding delay on resources spawn so that players can’t just continuously exploit it
Increasing the amount of resources sink in your game giving your players more meaningful choices to spend their resources.
Imposing limitations, such as players can only stack a certain amount of resources in their inventory
Constraining the amount of value that can be rewarded to users by the amount that’s coming into your ecosystem
Imposing taxes and upkeep fees on those that are wealthier, and decreasing them on those that have less, and so on.

When modeling a system in Machinations, and you notice that unsustainable patterns are emerging, most of the time, some sort of balancing feedback loop will need to be introduced to keep things within sustainable parameters. And as we saw, there are many ways to implement a balancing feedback loop. And Its purpose should always be to keep things within a sustainable range, preventing your system to go for a runaway exponential growth or decay.

Leverage Points

Another valuable element about modeling in Machinations is that it helps you identify your system’s leverage points. Leverage points are points of power. It’s where every wizard goes for their initiation. But more relevant in your case is that these act as points of control that you can use to change your system’s behavior.

If the structure of the system is the source of its own problems, by understanding leverage points, you understand how you can affect change to the structure of the system and change its behavior to more closely align with its purpose.

This is EMPOWERING. Like He-Man, raise your sword and shout, “By the power of Machinations.” The power to change the system is in our hands; it is a great power, and with great power comes great responsibility! (Okay, we are done with the comic book references… for now)

A leverage point could be a number or a parameter like a % of something rare to drop. It could be a change in a flow, like the spawn rate of foes in your game. It could be a balancing feedback loop, like putting a cap on the amount of items that can be rewarded each week or changing the variable in a feedback loop.

It can be a change to an information flow that affects the response time of something else, something that might increase or decrease a delay. This is by no means an exhaustive list, and understanding and mapping the leverage points and their effect remains a crucial output of the modeling process and, ultimately, a big part of the insight you’ll provide to your team.

Step 6: Full Economy Model

The full economy model provides a full scope of the system you’re modeling and takes the output of our single-user group as its input. The purpose of this step is to simulate how the interaction of all user groups affects your main KPIs.

This is where we answer the questions we sought to answer. Although you may have gained a lot of insights and answers throughout this process, theoretically, the full economy model was the true purpose of this process, and the single user model + persona logic is what you used to obtain your user groups data to feed into this model.

And because you have created detailed models of the subsystem for the single user group model, often some details in your full model can be abstracted away (they are already present in the data we are feeding into this model). This may sound anti-climatic but voila! You now have built your model, learned about systems thinking, and are able to obtain data on specific KPIs based on various scenarios and different user behavior.

KPIs + Data now what?

The results from the Single User Group Model and your Full Model can be used to detect risks.

They can also help optimize your system and subsystems to sustainably fulfill their purpose.

But what does it even mean for something like a game economy to be sustainable? “The economies of games are not just functioning like a genuine economy: they are a genuine economy.” reminds us Castronova.

If we had to take a real-world example, the US Economy is a sum of many subsystems (private sector, public sector, imports, exports, etc, which have their own set of subsystems…). They attempt to optimize the economy for GDP (whether that’s the right goal or not is up for debate, i.e. systems trap “seeking the wrong goal”).

The central banks monitor certain KPIs, such as inflation and unemployment, which show the system’s behavior. They then try intervening in the system through various leverage points such as interest rate policy or monetary easing/tightening. However, when wealth inequality is entrenched and getting worse. We have fallen into the system’s trap of “Success to the successful” and find it hard to extricate ourselves.

We can learn a lot from observing the economies around us, physical or digital. Although there are some distinct differences in digital economies, such as decay which doesn’t exist unless it is programmed, and assets are often inflationary with very negligible costs to duplicate and multiply.

Our article The Design Pillars for Building Sustainable Game Economies presents some guiding principles that can help you on your journey.

Principle 1: Currency Stability

“The core issue when designing an economy is not inflation or deflation per se, but rather the failure of its currencies to keep within certain bounds of value. Wildly rising, falling, or fluctuating currencies prevent almost any player’s economic activity from proceeding smoothly.

Thus, currency stability, rather than inflation or deflation, should be the true target of currency design so that as a medium of exchange currency can serve as a unit of account and sustain economic planning.”

Principle 2: Price Rationality

“A system for establishing fair prices and figuring out how much everything in the game is worth is necessary for a well-balanced economy design. An item should be expensive if it is thought to be very valuable. Things that are supposed to have no value ought to be priced at or close to zero.”

Principle 3: Proper Allocation

“The allocation function of an economy refers to the way an economic system distributes goods to people.

A successful economy distributes the right goods to the right people in a way that seems reasonable and fair to everyone involved.”

Conclusion: Harnessing System Thinking and Machinations for Holistic Design

By adopting a systems-thinking mindset, designers and strategists can perceive and model complex interactions and feedback loops that define the behavior of intricate systems, whether in games, economic models, or social structures.

Machinations, as a tool, serves as more than just a modeling platform; it’s a lens through which the multifaceted nature of systems can be comprehended and manipulated. The step-by-step guide presented here underscores the importance of starting with a high-level view, progressively delving into subsystems, and continuously iterating for refinement and precision. This methodology not only aids in capturing the essence of complex systems but also empowers creators to predict, itterate, and optimize within their designed ecosystems.

Furthermore, this journey through systems modeling underscores a crucial truth: while our models are simplifications of reality, their real value lies in their capacity to provoke thought, highlight potential issues, and guide decision-making processes. By modeling different scenarios, designers gain insights that are invaluable in preempting challenges and enhancing the overall experience of the end product.

In essence, the convergence of Systems Thinking and Machinations equips us with a powerful toolkit for understanding and shaping the world around us. It encourages us to look beyond the obvious, to explore the interconnectedness of elements within any system, and to appreciate the complexity that governs the dynamics of our creations. Whether applied to game design, economic theory, or any other field, this approach fosters a deeper comprehension of the systems at play and, ultimately, leads to more effective and sustainable solutions.

This article was co authored by Curious Rabbit, Head of Tokenomics at HLV Advisory.

Fortress Merge

About

Tags

Enjoying what you see?Show your appreciation by saving it with a click!

Be the first to this diagram

More from Franck Morgand

Product

Solutions

Roles

Resources

Compare

Pricing

Company

Enjoying what you see?
Show your appreciation by saving it with a click!