Dev Diary #4: How a Game Step Moves Forward
In brief: A game step is the calculation interval in which the engine advances the world once. It processes player orders and game rules in a defined order, then advances game time. Two tasks can run together if both only read the same information. If one needs information changed by the other, or both change the same information, the engine runs them in order. With the same starting state and game rules, the same complete sequence of game commands—including those from players, AI, and game systems—produces the same result on every computer. Player orders are only part of that sequence; assigning independent calculations to different workers does not change the result under those conditions.
Which tasks wait, and which can run together in a game step?
When a player gives an order, many rules may need to run before the world reaches its new state. Some rules depend on the result of another; others can work independently on different information. The engine must respect those dependencies. For a like-for-like result, the starting state and game rules must be the same, as must the complete sequence of game commands. That sequence is broader than player orders: AI and game systems can issue commands for later steps too.
Following dependencies while separating independent work
A shared game step
The game can choose an interval such as part of a day, a day, a week, or a calendar month. As the date moves forward from the player's perspective, the engine processes player orders and the rules due for that interval in an orderly sequence.
Running independent work together
Each game rule tells the engine which information it reads and which information it changes. If two rules do not conflict, the engine can run them at the same time. If one needs the result of another, the first piece of work finishes before the next begins.
This arrangement does not tie the result to which worker receives a task. Given the same starting state and game rules, participating computers produce the same world when they process the same complete command sequence. That sequence can include commands from players, AI, and game systems.
Some periodic work can be distributed across multiple days in its month or other period. That means every game object does not have to be processed at the same calendar boundary. It does not mean every periodic rule is distributed in the same way; the game chooses when each rule runs.
Running work in parallel without changing the result
The engine's step order allows independent work to run together based on the information rules read and change. With the same starting state, game rules, and complete game-command sequence, the number of workers does not change the result. This article does not present a comparative speed measurement.
Why design ordering and concurrency together?
A consistent order helps apply player orders and game rules predictably. Running independent calculations together also makes use of the computer's available resources; the schedule is designed to preserve both goals.
Where dependent rules still have to wait
Rules that depend on one another still have to wait. More workers therefore do not guarantee a faster step; dependent work still proceeds in sequence.
Defining the game rules
Developer Diary #5 explains how game rules are defined on this foundation.
Does every game step represent one calendar day?
Not always. A game can choose an interval such as part of a day, a day, a week, or a calendar month.
Do all rules run at the same time?
No. Rules that only read the same information can run together. Read/write or write/write conflicts are ordered.
Will adding more workers make every step faster?
No. Dependent work still has to wait; actual speed depends on the game's rules and data. This article contains no comparative timing measurement.
Sources and links
- See Developer Diary #5 for defining rules and Developer Diary #3 for organizing the calculated world.
- Visit MKA Engine for an overview, or the Developer Diaries page for the full series.