Developer diary

Developer Diary #19: How Does the Engine Schedule Game Tasks?

How the engine schedules game and mod work at daily, weekly, monthly and yearly starts, with a one-time setup task for a new world.

Contents
A new-world map beside a calendar marking daily, monthly and yearly moments for scheduled game work

In short: Some game work happens at the start of a month or year rather than every day; some values calculated from the starting world also need to be ready before the first game step. MKA Engine can call this work at times chosen by the game or mod; the content owner decides what to calculate. There is also a separate preparation task that runs once while a new world is being set up.

Think of an annual budget. It may make more sense to total income at the start of the year than to recalculate it every morning. In a newly created world, a total derived from the starting population may also need to be ready before the player sees the first day. The game chooses when this work belongs; the engine finds that moment in the game flow and calls it.

What was the problem?

A game step is the interval a game processes as time advances; it does not always cover exactly one calendar day. Some games can advance in longer steps, and one such step may include the start of several days, weeks or months. If each mod worked out the calendar on its own, correctly interpreting the period covered by a step would be harder.

New-game setup has a different need. A value calculated from starting data should be ready for the first world summary the player sees. Leaving it to a later step could show an incomplete value at first; recalculating it in every step would repeat the work unnecessarily.

Running work at a chosen calendar moment

A game or mod can bind work to the start of a day, week, month or year. The engine calls it in a game step that contains the selected start. The engine does not decide what to calculate: for example, the period in which taxes are collected is a game rule.

When a game step includes a calendar start, the work is called once in that step. Even if a step spans several starts, the engine does not run the same work once for every one of them. This makes the call timing explicit; a mod that needs to process each day separately must account for the span in its own calculation.

A game that starts in the middle of a period follows the same rule. If the first short step does not include a new month start, the monthly work is not called immediately; it runs in the later step that contains the month's start. The engine does not treat the starting date as a new period by default.

A game-time interval across several calendar divisions connects one scheduled-task marker to a strategy map

A one-time preparation for a new world

During new-game setup, the engine provides a separate moment to prepare values derived from the starting world. This work runs before the first day's summary and the first view shown to the player. A value calculated from data such as the starting population can therefore be ready for the first game step.

This preparation does not run again when a saved game is opened. Values calculated at the start are stored with the save; loading resumes the same game. A game that does not use this preparation does not run an extra calculation.

A value calculated for a new world with an abacus remains on the map when that saved world is opened

Does skipped work change other results?

Work that is not due in a game step is not called. It is important that skipping it does not shift the random results used by other work: one task being skipped does not move the others to a different sequence. This helps the same game state keep producing consistent results under the same conditions.

What did we observe?

Checks at the engine and mod layers show that work chosen for a calendar start is called once in a step containing that start and that call order is preserved. They also confirm that new-world preparation runs before the first summary and does not run again after loading a save. No speed comparison was made; these findings concern timing and whether starting values are ready.

Why did we choose this approach?

The engine already knows which calendar starts are included in each time interval. Letting it decide when to call a task, instead of having every game and mod calculate this separately, reduces the risk of missing a calendar boundary in a longer step. The game or mod still chooses which work belongs to which period.

Using a separate setup moment for starting values also avoids repeating the same calculation every day. If a game does not need this preparation, no starting calculation is run.

What does it cost?

A scheduled call does not keep information from its previous run by itself; if the gap between periods matters, the game or mod needs to store that information in its world. Also, during a long game step, the call runs once for that step, not once for every period it covers. No speed benefit was measured.

What comes next?

After calendar-scheduled work, we will look at how family and succession relationships are handled in a game world.

Frequently asked questions

Does monthly work run every day of the month?

No. It runs once in a game step containing the month's start. Even if a step spans more than one month start, there is no separate call for each one.

Does new-game preparation run again when a save is loaded?

No. Values calculated at the start are stored with the save; loading resumes the same game.

Does the engine decide which work is monthly or yearly?

No. The game or mod chooses the period; the engine calls the work in a step containing its start.

If calendar-scheduled work is skipped, do other tasks get different random results?

No. Skipping one task does not shift the random results used by the others to a different sequence.

For how periods appear in game data, read Developer Diary #12; for the general order of a game step, see Developer Diary #4; and for when events run, see Developer Diary #6. Visit the MKA Engine page for more information, or the contact page with questions.

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.