How to Manage Complexity in Machinations
In the realm of game development and systems design, the ability to transform complex ideas into prototypes and simulations empowers designers to test their assumptions, refine design ideas, identify potential issues, and allows designers to assess the balance of game systems.
Prototypes and simulations also serve as effective communication tools among the development team and provide a shared reference point for discussions. By having a tangible representation of their game systems, designers can collaborate with stakeholders to align their vision and ensure a cohesive development process.
And while Machinations offers designers a powerful tool to model, test, and predict player behavior, it is not uncommon for our users to inadvertently overcomplicate their models while striving for accuracy. This is not surprising, given that thoroughness is usually a virtue in design work. As designers, we are often inclined to believe that more detail equates to better design.
When it comes to modeling and simulation, however, this approach can pose significant risks and hinder project success. Being too detailed – or not effectively segmenting your models into multiple smaller models – can come with greater risks than not being detailed enough.
In this article, we will delve into the critical importance of scoping your projects when working with Machinations, emphasizing the significance of managing complexity. By effectively doing so, you can maximize Machinations’ potential, ensure alignment with your objectives, and sidestep unnecessary complications and pitfalls.
Additionally, we will explore the intricacies of managing complexity within Machinations.io simulations: as game systems become more intricate, accurately capturing their behavior through simulation becomes increasingly challenging, and will suggest strategies and best practices for balancing complexity, achieving meaningful results, and avoiding simulation overwhelm.
More Isn’t Always Better
Overcomplicating isn’t inherently bad when modeling. If you know the ins and outs of your system, you can technically make a model that almost perfectly reflects the actual system. However, just because you can put more detail into your model doesn’t mean the value of doing so outweighs the costs.
You should keep in mind at all times that the goal of modeling and simulation is not to recreate the Matrix, where every detail of the game is accounted for in near-perfect detail.
Meteorologists don’t model the flap of every butterfly’s wings just because it could technically cause a hurricane. Likewise, spending more time modeling a game system than it would take to design or code it is generally unwise. Modeling is a companion tool, not a product in itself.
Below are some of the key reasons that more isn’t always better:
1. Complex models take longer to build
The relationship between complexity and time spent on the model is rarely linear and will often increase exponentially. Those familiar with programming will know that complex systems have many more interconnected parts that must all be implemented and tested. Additionally, human errors are much more likely to sneak into more complex models and tend also to be harder to track down and fix.
2. Complex models are harder to rework
If, after simulating using your model, you decide a mechanic needs to be reworked or removed, or if you want to add a new mechanic, you may have to tear out large chunks of your diagram and add new ones. Again, this is much more time-consuming and prone to error.
3. Complex models are harder to understand
If you need to return to your model later, or if multiple people need to use it, it needs to be easily understandable. Complex models with lots of visible connections and no clear hierarchy of information can take a long time to digest.
To make complex models more legible, you will often need to spend even more time restructuring them, adding visual aids, walking colleagues through them, or even writing dedicated documentation explaining how they work.
4. More complex doesn’t always mean more accurate
Paradoxically, though complex models may be more accurate if done right, they are also more likely to be done wrong. The more detail you add to a model, the more likely you are to make an incorrect assumption about how the system works, especially if you are assuming how players will behave.
Such incorrect assumptions can cause your model to produce incorrect results, which is arguably riskier than making a simpler, less precise model.
Consider this analogy: four artists are told to draw a gift box that is hidden to them behind a curtain and create the following drawings.
The first artist approaches the assignment by stripping away all unnecessary elements: drawing a simple box defined by geometric lines. The second artist took the same path, adding, this time, a ribbon to the box. The third artist adds no complexity to the former design but assumes that the box is opened. Lastly, the fourth artist is going much more detailed but is making even more assumptions, adding color and confetti to the design.
Suppose the box behind the curtain is wrapped in plain blue gift-wrapping paper with no ribbon. In that case, the first artist is correct, assuming the box could be any color, while the fourth artist, more detailed with the design, is the least accurate because they have made the most incorrect assumptions.
The above example is not to argue that very basic diagrams are better, rather that adding complexity to a diagram risks making more unproven assumptions, which can lead to incorrect conclusions being drawn.
Vague, low-resolution diagrams aren’t much use either, so the key is to be aware of the assumptions being made and to scrutinize them. You should only add detail to your model if you are reasonably confident that the assumptions you make by doing so are minor ones or are at least easily corrected in light of new information.
5. Payoffs in accuracy diminish as complexity increases
After a certain point, each detail you add to the diagram will (on average) produce a smaller and smaller increase in accuracy. This is because users generally model the fundamentals of a system first and then add surrounding details. The fundamentals are what define the system most broadly, so you would expect that modeling those gives the best payoffs in accuracy.
Once you have modeled the core systems, you should decide how much time you are willing to commit per % increase in accuracy. Quantifying accuracy is very difficult without real data to compare to, but a rough estimate is better than nothing.
6. Complex models can slow your simulations
Regardless of the software, more complex models will take longer to run and may require more simulation runs to capture all the variability in the system.
Machinations’ Interactive Play mode is a unique and highly valuable tool for helping understand what is happening in your economy step-by-step. However, by creating very large diagrams (usually with a thousand or more components), you may lose out on their value, as animations will begin to slow down.
We recommend that if you can’t avoid making a system very complex, you should consider dividing it into multiple models and using the simulation results of one model to inform what you do in the other.
How Much Complexity Is Needed?
Determining the appropriate level of complexity when modeling in Machinations.io is a delicate balance. This question depends heavily on the goals of modeling, the timeframe in which conclusions must be gathered, and the state of the game being modeled. We discuss each of these below:
What are your goals?
The general philosophy to adopt when modeling is to start by building only what is absolutely necessary for answering your core design questions. If your sole goal is to find out how long it takes for players to progress through your game, the model should help you discover this and only this.
What is your timeframe?
Minimum viable models can take several hours to build, but you will also need to factor in time for balancing and resolving any human errors made. It is best to test your diagram little and often in Interactive Play mode, to make sure you catch issues early and don’t miss deadlines.
What stage of development is your game in?
The more set in stone your game systems are, the more reasonable it is to increase model complexity. Conversely, if core features could still change in light of simulations and playtests, there is a greater risk of wasting time modeling things that will have to be reworked later.
Note that “significant changes” do not include purely numerical changes. If your model is well-organized, design values should be straightforward to change.
During the very early stages of pre-production and brainstorming, we recommend building only very small models (of less than one hundred nodes). Over time, as you become more confident in the suitability of your game systems, you can add more detail.
Iterative Modeling
The workflow for building diagrams should be the same as in other aspects of game development:
Programmers develop prototypes that get to a functional and playable state as efficiently as possible, omitting any features that designers, marketing execs, etc., don’t need yet. Once that prototype is tested and validated as fit for purpose, programmers iterate on it, cleaning it up and resolving any limitations (i.e. “refactoring”). Then, the next sprint begins, where they add new layers of functionality requested by other departments. Again, they build only what is absolutely needed and leave the rest for a later sprint.
This iterative approach is ideal for modeling because it forces you to adopt a mindset that discourages overcomplication and time-wasting.
More specifically, we recommend doing the following:
Model systems in order of significance
If you know that mechanic A probably isn’t going to have as much of an impact on player progression as mechanic B, you should start by modeling B. There is a chance that, after doing so, simulations reveal that A isn’t needed, or that it will compound an issue that B has caused. If you modeled A first, you would have wasted time.
Test and simulate little and often
If you spend a lot of time building and refining your model before ever testing it in Interactive or Batch Play mode, it will be harder to figure out what outcome was caused by what mechanic; thus, it will take longer to come to accurate conclusions about what the results show. It will also be harder to track down the source of human errors, and you may mistake erroneous results for valid results or vice versa.
Refine your systems layer by layer
It is better to get your model to a stage where it can produce actionable insights as soon as possible, particularly if your time is limited. If your game includes one core mechanic and three important metagame mechanics, for instance, it would be best to model all four in a low level of detail (starting with the core mechanic), run some simulations, gather results, make necessary changes to the mechanics (functional changes, balancing, bug fixes, etc.), and then add another layer of detail to them. This is usually better than building out one mechanic in-depth and only then moving on to building another – doing so would delay the time taken before the model could give you any useful information.
Conclusion
As explored throughout this article, overcomplicating models without a clear purpose can prove inefficient and risky and may not give you the pay-offs in accuracy you hoped for.
Remember that your Machinations project’s success lies in understanding the purpose of modeling and simulation: namely, to enhance your design and decision-making process, and not to become an end in itself.
By thoughtfully segmenting complex systems into smaller, manageable models, you can maintain clarity while delving into specific areas of interest. This facilitates focused analyses and decision-making, and avoids the modeler getting distracted or overwhelmed by unnecessary details.
This approach will also minimize the time and stress required to build functional models and maximizes the value derived from simulations so that you can unlock the full potential of your Machinations.
