Developer Diary #25: State Fingerprints and Population Grouping

In short: We changed MKA Engine’s game-state fingerprint so that only changed parts need to be recalculated. That shortened the measurement when little changed, but could make a busy run slower. We also measured less frequent population-group organization: ordinary days became shorter while more work moved to month-end. These results come from separate test worlds, not a full game day.

What was the problem?#

In a multiplayer strategy game, everyone needs to advance from the same world state. A state fingerprint is a compact summary that helps detect when players’ simulations have diverged. Earlier diaries covered multiplayer consistency and how the world is kept in memory (#2, #3).

The earlier method summarized changed information in larger sections rather than updating each changed part individually. Even when only a few things changed, calculating the summary could still require reading the affected section; that does not mean the whole world was reread at every step. Tracking only changed parts is not free in every situation, though: if much of the world changes in a day, updating every part individually can cost more than starting over.

Keeping population groups arranged by similar traits is a separate cost. When many new groups appear, reorganizing all groups every day can take most of the step. Doing it less often may reduce that work, but makes the scheduled regrouping day busier.

How did we solve it?#

We recalculated only the changed parts#

The previous method grouped the summary work for changes within larger sections. The new method updates the fingerprint contribution of each changed item individually. When the world is mostly stable, this avoids reading the same information again. In a different situation—when many parts change each day—the benefit may shrink. We therefore measured both conditions and did not turn one good result into a general speed claim.

We made population-group organization less frequent when appropriate#

A game can choose intervals for organizing newly formed groups. Those groups do not disappear from daily calculations while they wait; the game can still include them before the next reorganization. This lets a game trade the cost of daily organization for a less frequent collection of the work. It is not a universal setting: the game decides when changes need to become visible and how much month-end work is acceptable.

What did we see?#

In the first measurement, we timed only the state fingerprint in a large test world with a map. The world contained about 2.04 million population groups, and the system-load indicator—a rough measure of work running or waiting—was between 8 and 9. A millisecond is one thousandth of a second. Worker count tells us how many workers shared the work at the same time.

These numbers are for the state summary alone, not a full game day. A separate run showed the opposite result: in a 60-day runner scenario, summary work rose from 0.086 ms to 0.459 ms per day. In a later, separate 60-day run with 8 workers, a partial fix reduced the summary from 0.32 to 0.26 ms per day; the reference baseline for that scenario was 0.11 ms per day. The fix improved the path but did not bring it back to baseline. Because the load conditions differed, we do not combine these results into one series. In that scenario, most of the state changed each day, so the extra work of updating changed parts one by one outweighed the benefit. We report what the measurement established; the other causes of the slowest days were not settled.

The population-group organization measurement ran for 26 game days in a separate large test world using an experimental population-update path. Daily organization accounted for 70–72% of the measured step, which took about 15–18 ms. With monthly organization, the average day took 3.63 ms with 1 worker and 2.72 ms with 8; the month-end organization day rose to 19.6 and 18.5 ms respectively. Machine load was between 2.8 and 3.9. This also measures one part of a specified test world, not a full campaign or the whole engine.

We measured the initial organization too#

Our first monthly run unexpectedly added work every day because of how the starting world was organized. We corrected that setup path and then repeated the monthly measurement. This does not mean monthly organization is always faster; it explains a correction needed to make the comparison fair.

Why did we choose this approach?#

The state summary and population-group organization solve different problems: one tracks changes in the world, while the other prepares similar groups to be processed together. We did not assume that improving one would automatically improve the other. Measuring both low-change and high-change worlds, and showing the difference between ordinary days and month-end, gave us a more honest comparison.

What does it cost?#

Tracking changed parts reduces calculation when little changes, but adds work when most of the world changes. Monthly organization shortens ordinary days while moving a noticeable workload to month-end. The runner’s state-summary time remains above its earlier measurement level.

What comes next?#

We need to revisit the high-change runner and its slowest days. We will not present monthly organization as a general performance recommendation until it has also been measured in a real game scenario alongside the daily simulation.

Frequently asked questions#

For more background, see multiplayer consistency, how the world is kept in memory, MKA Engine and the developer diaries, or reach us through contact.