Developer Diary #24: Verifying Event-Day Estimates

In short: We predicted when population changes would occur in a separate test model and compared the result with a reference calculation that advances one day at a time. Group states and first change days matched in a defined small world and generated starting conditions; this verifies the test model, not a released MKA Engine feature or a speed improvement.

Update: 8 November 2026. The verification completed on this date is separate from the diary’s original content date, 30 October 2026. The results below are limited to the test model’s scope.

What does it mean to predict the day a population group changes?#

Strategy games often represent population as groups of people who live in one place or share relevant characteristics, rather than tracking every person separately. A game’s own rules can determine whether a group grows, moves elsewhere or joins another group. When those calculations run daily, checking each group one day at a time is an easy-to-understand reference method.

An event-day approach asks a different question: while a group’s properties and the rates applied to it remain unchanged, can we predict the next day on which a meaningful change will occur? That question does not decide what a population rule should be. It attempts to calculate the timing of changes produced by rules that have already been selected.

This work did not add that approach to the production engine. The design document was marked as a proposal awaiting user approval. The completed work was to check, in a separate test model, whether the proposal agreed with a daily reference calculation. It should not be read as a new behavior players can use in a game or as a completed production feature.

How did we compare the model with the daily reference?#

A verification method should test a clearly stated claim. Here, the reference calculation processes every day in a small game world. The event-day model calculates the next change time for each group and handles groups only when their scheduled day arrives. We checked whether both paths reached the same world by comparing group states, not merely a few totals.

The comparison ran for forty game days. The same setup was run first with one worker thread and then with eight. A thread is a unit of work the engine can run at the same time; the counts here are not a speed measurement. At the end of each day, group states, births, move counts and numbers moved were compared with the reference calculation. This check covers the defined small world and period; it is not a performance run at full-world scale.

That distinction matters. Matching results show that the two methods in the test reached the same state under the same rules. They do not, by themselves, show that one method is faster, uses less memory or produces the same result in a much larger game. This diary therefore does not present a speed comparison or announce a move to production.

Was the predicted day the first day with a change?#

A second check focused on a narrower claim: was the next event day calculated for a group the same day on which the daily reference first applied a change? The test generated starting conditions for population size, active processes and accumulated change at that point. It compared the calculated day with the first change found by advancing the reference calculation one day at a time.

Comparing only the first event would not be enough; that first change can alter a group’s size or remaining accumulated amount. The test therefore recalculated later event days from the new state and repeated the comparison across successive events. Instead of relying on a single matching date, it also checked whether the schedule was rebuilt after each new event.

The starting data in this check was generated in a defined, repeatable way. Its result applies only to the group sizes, process choices and accumulated-change ranges covered by those conditions. It does not validate a real game’s historical population rates, content rules or a player’s strategic choices.

Boundary cases are part of the daily calculation#

A threshold is the level accumulated change must reach before a change is applied. A method can look correct in an ordinary case and still return a day too early or too late near that level. The checks therefore included accumulated change exactly at a threshold, a fractional waiting period rounded up to a whole day, and a group that starts above its threshold but is handled on the following day. They also checked that a group with no active process producing a change does not receive a new event day.

Order matters when several processes can change a group on the same day. For example, if growth adds people first, the amount that can move later that day must still respect the rules for that day. The checks covered process order, preventing a transfer from exceeding the group available, ensuring an empty group gains no population, and the threshold ceiling for large groups. These are calculation behaviors in the test model, not separate game rules players can observe.

Testing boundaries does not mean every possible game rule has been verified. When rates and thresholds change, when a group moves to another place, or when game content is reevaluated each day, those decisions require separate scope. This work focused on whether selected model behaviors agreed with the reference calculation.

What claim does the result support?#

The completed verification supports the claim that, under the defined conditions, the event-day calculation in the test model reached the same group states and change days as the daily reference. Comparing the same results with two worker-thread arrangements also showed that results within this test scope did not vary with that execution arrangement. This is not a general guarantee about every workload in the full MKA Engine simulation.

A full-map measurement was not part of this result. We therefore make no claim such as “faster than daily calculation,” “reduced memory use” or “equivalent across the whole game world.” A performance result would need a separate measurement with the same world, rules and comparable workload. No such measurement was performed here.

Keeping the test model separate from production code also helps readers interpret the result. A design passing tests does not mean it has been approved or is active in a game. For this proposal awaiting approval, the check answers only a correctness question: in the selected examples, the dates found by the daily reference agreed with the dates predicted in advance.

Frequently asked questions#

Sources and links#

The verification scope comes from the comparison between the daily reference calculation and the event-day model in MKA Engine’s tests. The design document is marked as a proposal awaiting approval. Detailed evidence and limitations are recorded in the source note. For more information, visit MKA Engine, developer diaries, and contact.