Contents
Correction (4 November 2026): The loop and list-scan limits described in this diary no longer apply. The scripting language was removed on 2–3 November 2026; rules are now written as Rust data functions, and these limits are not part of the new model. Limits on mod processing and memory still apply. The sections below keep the original text, with a content date of 19 October 2026.
In short: Scripts describe a strategy game's rules and content behavior. MKA Engine separately limits the work those rules can produce in loops and long-list scans. Setting the boundary by work performed rather than elapsed time gives computers of different speeds a shared, predictable stopping point.
A rule may apply to many countries or provinces; sometimes the same action repeats while a condition remains true. Even a few lines can turn into a great deal of work when they cover a broad list or nested repeats. The aim is not to ban broad rules, but to keep the amount of work in a single run predictable.
What was the problem?
A loop repeats an action while a condition remains true. If the rule itself does not change that condition, the repetition may continue for a long time. A list scan visits members of a collection one by one; checking a condition or making a change for each member adds work. When one scan is placed inside another, the number of members to examine can multiply at each level.
That is why the length of a rule does not tell us how much work it needs. A short loop may run many times; a short list rule may inspect every member of a very large set of countries or provinces. Without a boundary, this work can lengthen a game step and make other players wait. We limit loops and list scans separately because these two kinds of work are counted differently.
How did we solve it?
The loop boundary counts repetitions, while the list boundary counts the members visited in a single evaluation. A member still counts as work even if the rule does not change it. If a loop crosses its limit, the effect doing that work stops and an error is recorded. If a list scan crosses its own limit, that rule evaluation returns an error; this is a different outcome from a loop-limit error. In some cases, if an upper layer does not handle the list-budget error, a game step can stop; we cannot guarantee continued play in every case.
What did we find?
To make the order concrete, consider a one-time payment event for a country: if its gold is below 1, the event adds 7 gold. The condition is checked first; if it holds, the immediate effect runs. Effects proceed in the order they are written, so a later effect sees the earlier change. The new value written by the event can also be seen by later systems in the same game step. The values 1 and 7 in this example belong to the event, not to the engine limit.
The list boundary matters even more in nested scans. A rule may change some countries during its first pass, then reach the work limit during a later pass. A limit error does not automatically undo changes already applied, so part of a rule may finish while the rest does not run. The important distinction is between what the rule is meant to do and how much work one evaluation actually completes.
Why did we choose this approach?
We set the boundary by work performed, not by elapsed seconds. The same second can contain more operations on a fast computer and fewer on a slower or busy one. A wall-clock limit would therefore create different stopping points across computers.
A work count is a simulation measure independent of machine speed: with the same starting state and rule, execution reaches the boundary after the same amount of work. Processor speed does not change that stopping point. This supports consistent evaluation of the same game inputs on different computers; it does not mean those computers finish in the same time.
What does it cost?
A broad and valid rule can still reach the work limit; the boundary does not guarantee that every rule will finish. A content creator can divide a large scan into groups by region or condition, or narrow the members checked in each pass. This reduces the work assigned to one run, but the creator still needs to plan each group's scope and size so that a pass can complete.
What comes next?
This diary covered how much work rules can perform. Next, we will explain the parts of the strategy map and how they connect to one another.
Frequently asked questions
Does this diary show a speed improvement?
No. We did not measure performance here; the change we describe limits how much work a rule can produce.
Do mods use these same limits?
Mods have separate limits for processing and memory, distinct from the script loop and list limits discussed here. For how mods work, see Developer Diary #8.
Does the limit change the game rule I wrote?
No. The rule's purpose, condition, and effect remain as the content creator defined them; the limit sets how much work one evaluation may perform. When designing a broad rule, its scope and the size of each pass still matter.
Sources
- MKA Engine scripting-language and determinism guides.
- MKA Engine mod reference.
Related reading: Developer Diary #7 and Developer Diary #8. For more, see MKA Engine, developer diaries, and contact.
Sources and related docs
You may also like
- How is a strategy game's world map made?
For MKA Engine we built a 27,357-location world map of 1337 from real data: how terrain, rivers, straits, population and location borders were made.
- The road to a game engine
How we started MKA Engine: reading four games, treating determinism as law, moving phase by phase with measurements, and where we are now.