Balancing a Game Without Players: Building a Simulation for Prologue

The Problem

Prologue can generate millions of possible maps. Each map contains different resource distributions, weather conditions, terrain layouts, shelters, and points of interest. Before Early Access, we had no player data and only a limited number of playtesters. This made balancing difficult.

Even if a single map felt balanced during playtesting, there was no guarantee that hundreds of thousands of other maps would produce a similar experience. I needed a way to test the game systems at scale.

Prologue: Go Wayback! generates a new world every run.
These are heightmaps of runs I played and used for my simulation.

Where the Idea Came From

While helping a PhD researcher working on Local Energy Communities, I was exposed to simulation models used to study complex systems. One thing that struck me was that the goal was not always to reproduce reality at the highest possible level of detail. Researchers adjusted the complexity and granularity of their models depending on what they wanted to observe. Some questions required highly detailed simulations. Others could be answered with a simpler model focused on a specific subset of variables. This is what they call a fit-for-purpose complexity level.

At the time, Prologue faced a similar challenge. The game could generate millions of possible worlds, making it impossible to evaluate them manually. We needed to understand how survival systems behaved across a large number of scenarios, but we did not necessarily need to simulate every aspect of the game to answer those questions.

This led me to wonder whether the same approach could be applied to game balancing. Instead of building a perfect reproduction of the entire game, I built a model with the level of complexity required to answer the questions we were asking at the time.

The objective was to understand how changes to weather, resources, shelter spawning, and survival systems affected the overall experience. Just like in the research models that inspired it, the complexity of the simulation was driven by the problem being investigated rather than by a desire to reproduce reality in every detail.

Early states of the simulation. From left to right:
– First generation of fully random map, shelter location, weather tower, and simulated player.
– Path-finding test gone wrong
– Edge detection implemented, making path-finding work cheaply for large iterations

Building the Simulation

The goal was not to reproduce the game 1:1, but to answer balancing questions before analytics existed. I wanted to reproduce enough of the game’s systems to observe how they interacted with one another. To achieve this, I built a Python simulation capable of running survival scenarios across generated maps.

Prologue stores its terrain as heightmaps. Rather than trying to reproduce world generation inside the simulation, I extracted the generated heightmaps from the game and used them as the foundation for the simulation. I then reproduced many of the systems that influenced survival outcomes:

Terrain and elevation.
Visibility based on weather conditions.
Visibility reduction caused by forest biomes.
Pathfinding across the world.
Day and night cycle.
Player vitals.
Wetness.
Fire making.
Clothing and insulation.
Inventory management.
Survival tools such as the map, compass, binoculars, and ferro rod.

Work had also begun on simulating shelter airflow and its impact on survival. Rather than simulating a player standing still and consuming resources, the simulation attempted to reproduce the decisions and constraints that players faced while navigating the world. The simulated player followed a set of rules and priorities that evolved as we learned more from playtests and player behavior.

This allowed thousands of survival scenarios to be evaluated automatically and made it possible to explore how weather, resource availability, world generation, and survival systems interacted across a large number of maps.

A Screenshot of the visuals part of the results of the simulation.
The simulated player starts on the left, picks a direction at random unless it sees a shelter. Moves to other shelters until it sees the weather tower (goal to reach). Once in sight, the player continuously walks toward it until one of its vitals is dangerously low. It then tries to find a shelter, and once the vital is back to the normal level, it continues toward the tower. This behavior was the behavior of a lot of our early playtesters.

Additional explanations:
– Green parts of the trail mean the player was in a meadow biome (increase visibility)
– Blue parts of the trail mean the player got wet (traversing a river)
– Shelters are the square of multiple colors. Colors indicate the quality. Red = Low, Orange / Cyan = Medium
– Shelters that have been seen display an orange circle

Assumptions and Limitations

One of the challenges was deciding how intelligent the simulated player should be. In an early version, I implemented a memory system that allowed the simulated player to remember previous locations and return to them later to make a fire or gather additional resources.

This seemed reasonable at the time. However, once players started interacting with the game, it became clear that very few players were able to consistently remember and revisit previous locations. The simulation exposed not only assumptions about the game systems, but also assumptions I was making about how players navigated and reasoned about the world.

This became an important lesson throughout the project. The simulation was never intended to predict exact player actions. It was intended to provide useful information for balancing decisions.

A Screenshot of the data part of the results of the simulation.
These graphics display the player’s vitals over time, sheltered state, body insulation, world temperature, and wetness.

What the simulation revealed

The simulation quickly uncovered several balancing and design issues.

System Issues

The simulation suggested that clothing was having a much smaller impact on insulation than expected. Investigating this eventually led to the discovery of bugs in the way temperature and insulation were being calculated.

World Generation

Some maps were effectively unwinnable due to extreme edge cases in the shelter and weather tower spawning rules. These situations were rare but could have a significant impact on the player experience.

Survival Balance

The game was relatively forgiving until a blizzard occurred, at which point the difficulty increased dramatically. Crossing rivers also proved far more dangerous than expected, even when world temperatures were otherwise manageable.

Exploration Incentives

Players could survive for extended periods while remaining in locations with very little content. This reduced the incentive to explore and undermined part of the intended experience.

Using the exported data to build a parallel coordinates plot allowed me to check irregularities or patterns between runs and seeds. Here, we filter the simulated players that survived the most. Without a surprise, they are also the ones who consumed (/ingested) the most calories and water. But they also made the most fires (so fire is likely mandatory to survive), and they visited a lot of shelters. So likely, at this stage, it was impossible to survive solely on foraging.

Consequences

The simulation became one of the primary balancing tools used throughout development and remained in use until Early Access.

Beyond balancing, it also became a useful verification tool. Because the simulation depended on reproducing the game’s underlying systems, I spent significant time validating how weather, temperature, insulation, hunger, and thirst were actually implemented. This process uncovered several issues that would have been difficult to identify through playtesting alone.

As development progressed, the simulation became increasingly expensive to maintain. Its original purpose was to answer broad questions about survival balance before player data existed. Once those questions became more focused, maintaining a complete simulation became less efficient.

I eventually replaced it with a set of specialized predictive tools dedicated to weather, clothing, hunger, and thirst balancing. These tools were easier to maintain, faster to use, and allowed designers to test hypotheses in a matter of minutes.

Some more results of the simulation, exploring island start, and hard to reach weather tower.

Takeaways

The simulation was definitely not the most valuable outcome.

Building it forced me to develop a deep understanding of how the survival systems interacted with one another. In order to reproduce the game’s behavior, I had to understand not only how each system worked individually, but also how they influenced one another. This made it much easier to understand new features and predict how changes in one system would affect the rest of the game.

The balancing tools that emerged from the simulation became equally valuable. They allowed us to evaluate ideas quickly, validate assumptions, and make informed decisions without relying solely on lengthy playtest sessions.

The most important lesson, however, came from the modeling process itself. While helping a PhD researcher working on Local Energy Communities, I learned that the value of a model is not determined by how closely it reproduces reality. It is determined by whether it is detailed enough to answer the question being asked. I applied the same principle to Prologue. Rather than trying to simulate every aspect of the game, I focused on reproducing the systems that mattered for the balancing questions we were trying to answer.

The simulation was never a perfect representation of the game, and didn’t need to be. Its value came from helping us understand complex interactions, compare scenarios, identify problems, and make better design decisions long before analytics became available.