Space map & economy balancing

The goal

Create a meta-gameplay and trading system that expanded production in a way distinct from competitors: without Factorio’s combat loop or Satisfactory’s fixed quests.

After several prototype and brainstorming cycles, we stopped at the idea of a space map built around robot trading. Robots were still a small part of the game at that point, with plans to expand them dramatically.

Content layer: planet types and biomes

Next came the content layer: planet types and biomes. They were not distributed randomly. A few conditions made discovery more interesting: some types appeared only within a small constellation, some had a better chance in particular regions such as the north or west, some clustered together, while others kept their distance.

That creates different outcomes in each playthrough. Pure randomness at this scale would spread colours evenly until the map became a boring grey mix rather than a world with recognisable regions.

Roads between planets

The next task was the road network that connected planets. After several attempts, the solution combined a few approaches: start with Depth-First Search, then add layers that correct the map and help it serve the intended purpose.

Every point must be connected, but the process cannot become too complicated. The map generates for each player and every run, so baking or saving a huge amount of map data would not be practical.

The target was around four to six main branches, with only a few shorter ones. The initial algorithm made almost a single route to reach each point, so another layer analysed the graph and added connections between branches while keeping the minimum, maximum and average distances to points within useful bounds.

Reading and tuning the economy

There was much more work at the economy level: many data points and parameters influenced one another. Reading the outcome or balancing it by hand would not have been realistic without the next tool: a heat map for the resulting economy.

It showed the endpoints where particular robots could be sold, how those points were distributed across the map, and how prices differed. The result became clear and practical: tune the income, judge the distribution visually, and test whether it played well through different game phases and strategies — harder to find where needed, easier elsewhere, with occasional outstanding random opportunities that could shape a run.

From iteration to release

In this case, I could hardly imagine designing the system without building it myself. Bouncing individual tasks through the development department would have taken months instead of a few weeks, even with close daily communication. Iterating directly meant testing an idea in minutes, which mattered because the system depended heavily on its architecture and implementation.

Once the creative director and I were happy with the result, the development team helped optimise the system and connect it with the rest of the game: saves, multiplayer, dedicated servers, world generation, cheats and mods.

The update went well and the game reached a new historical CCU peak. This case study describes my contribution, not the update’s only change: the team on the project brought deep experience across their disciplines, and Paradox Interactive did major work on the publishing side as well.