Developer Diaries

In short: We measured where time goes in a game day and reduced unnecessary work in two separate places. Under heavy system load, the wait for small tasks fell by 43%; in a separate market comparison, daily economy time fell by 14% and total day time by 9%. These results came from different conditions, and the wait-time result does not mean the whole day became faster by that amount.

What was the problem?

When we end a day, population, markets and the game’s own rules run one after another. To understand the total duration, it is not enough to measure one calculation. We also need to see which tasks take the most time and where waits accumulate.

The initial profile measured 300 game days in a fixed test world with one worker—that is, the engine did not split that run's work across several workers. A test world is a sample setup we keep constant so different versions can be compared from the same starting conditions. It had 30,000 locations, 250 countries, 2 million population groups and 512 markets, each with 8 goods. Mods and succession calculations were off. We measured on Linux on an AMD Ryzen 7 5700G machine with 16 processor threads, with the interface off and one worker; the computer’s one-minute workload indicator was around 14. This indicator roughly describes work running or waiting for its turn; it is not game time by itself.

How did we solve it?

We waited only for workers who joined small tasks

Some daily work is split into small pieces and shared among several workers. In the old arrangement, every worker was put on the return list when a batch began. Even if the batch finished quickly, the main worker could still wait for someone who never took a task to wake up and return.

In the new arrangement, the main worker closes the batch after finishing its own share and waits only for workers who actually took work. A late worker with no task does not join a closed batch. The order in which completed work is combined—and the game’s results—stays the same; only the workers the main one has to wait for change.

We reduced repeated work in the market calculation

The market looks at buyers’ and sellers’ requests to find a suitable price for a good and how much each participant buys or sells. The old calculation copied some order lists again while searching for a price. The new arrangement reuses the saved lists instead of making another copy. When the shares are already known directly, it also skips an unnecessary division; if the money amount is zero, it skips dividing the money shares.

These changes do not alter the trading rule, price or priority when participants are tied. The allocation rule we described earlier remains the same; only repeated work around the same result is reduced.

What did we see?

In the initial profile, the average duration was 8.70 milliseconds per game day. The economy calculation took 3.16 milliseconds and population growth took 2.21 milliseconds; other daily calculations, the game’s end-of-day rules and the day summary made up the rest. This is not the duration of a complete game with its interface running; it is a measurement of the fixed test world using one worker.

We assessed task sharing separately, with 8 workers on a continuously loaded computer. In the 10-pair high-load round, where the workload indicator was 17.8–18.0, the median time spent waiting for small tasks fell by 0.5 milliseconds per game day, or 43%. This round focused on the waiting category. Across all 16 comparison pairs at different load levels, the median difference in total day time was 0.2 milliseconds—below the roughly 0.6-millisecond variation in the population-and-economy section—so we do not claim that the whole day was definitely faster.

We measured the market change separately in the same test world, with one worker on the same machine, across 6 old-versus-new pairs; the workload indicator was 7.7–8.5. The economy calculation became shorter in all six pairs, with a median reduction of 0.39 milliseconds per game day, or 14%. Total day time fell in five pairs, with a median reduction of 0.64 milliseconds, or 9%. This result also applies only to the specified test world and conditions.

We did not combine the two improvements into one test: task sharing was measured with 8 workers under high load, while the market calculation was measured separately with one worker. We also compared whether the results were preserved; end-of-day summaries and market shares remained the same.

Why did we choose this approach?

For task sharing, the goal was not to decide which worker gets which task. It was to stop a delayed worker with no task from holding up work that had already finished. In the market, we reduced repeated work around the same calculation rather than redesigning prices or allocation. That kept the measured changes separate from the game’s rules.

What does it cost?

The engine must track correctly when a group of workers closes and who actually joined it. The market calculation must also keep reused lists attached to the correct price search. Measurements used a fixed test world with mods off; a real game’s rules and computer load can change the time distribution.

What comes next?

In the next diary, we will look at how the interface can stay responsive while a new game is being set up, and how mod faults become visible in a game-step result.

Frequently asked questions

We described the steps of a game day in Developer Diary #4 and how leftover shares are assigned in Developer Diary #7. Explore MKA Engine and the developer diaries, or reach us through contact.