Developer Diary #23: Game Setup and Mod Faults
In short: MKA Engine can prepare a new game or resume a save in the background while the player-facing interface keeps responding, and it reports which part of setup is underway. Games started from the same prepared data keep separate states. If a mod (an extension that adds game rules or content) faults during a game step (one simulation update), the normal step result is returned with the fault in this specific path; this is not a general guarantee that every kind of error lets the game continue. Loading time was not measured.
What was the problem?
Starting a new game or opening a saved one means preparing mods, game content, the map, rules and the starting world. If setup leaves the player-facing interface unresponsive for too long, the player may think nothing is happening. The interface should keep responding and show how far setup has progressed.
Mods can also run during some game steps. When a mod fails, a generic “operation failed” message does not tell a developer which mod or task caused the problem. The result can also depend on where the fault occurred. Progress during setup and a fault during a game step are separate problems.
How did we solve it?
We prepared the game in the background
The engine can prepare a new game or open a saved one in the background. The player-facing interface can keep updating its controls and display while setup continues. The engine reports meaningful steps in order: preparing mods, reading game content, setting up the map and rules, building the world, and becoming ready. These are not percentage points; they tell the interface which part of setup is underway.
The player-facing interface decides how the loading screen looks, what it says and whether it shows a progress bar. The engine supplies progress information that the interface can read. If a setup step fails, progress remains at that step; this information by itself does not say how long loading will take.
We started separate games from the same preparation
Prepared game data can reuse map and mod resources. But shared preparation does not mean sharing one world: each game started from the same package advances with its own population, countries and events. Moving one game forward does not change the other’s moves. It is like setting up two game boards with the same rulebook.
In the checks, games started one after another from the same package produced the same summaries as a game started from a freshly loaded package. When two games were advanced in turn, each kept the same result it had when run on its own. This shows that reusing preparation data and sharing a running game state are different things.
We returned a watched game-step fault with its result
If a mod being watched faults during a particular game step, the engine can return that step’s normal result together with the new fault information. In this tested path, the step had already been applied; the faulting mod was stopped, and later steps could run without it. The report names the mod, the task in which it faulted and the kind of failure. The engine does not undo a step that has already been applied.
This does not mean every fault path has the same result. For example, an error in a command that only asks for information can reject that command without stopping the mod. So the continuation described here applies only to a fault during a watched game step; it is not a guarantee that the game continues after every setup, command or mod failure.
What did we see?
The compared results were the same whether the game was prepared in the usual way or in the background. Setup progress could be read in order. Two games started from the same package also produced the same results as when each was run alone, even when their turns were interleaved.
In the mod-fault example, the ordinary step report was preserved and returned with the new fault information. The fault was reported once, and the stopped mod did not produce the same fault again on later steps. This was verified for the specific watched game-step path. We did not measure loading time or how much time this arrangement saves.
Why did we choose this approach?
The engine lets setup continue in the background while the interface remains responsive; the interface chooses what to show the player. This means it does not have to reproduce every internal engine step.
If a game step has already been applied, undoing it as if it never happened could change the game world. Keeping the fault only inside the mod would also leave the reader of the step result without that information. That is why, in the tested step-fault path, we return the normal result together with the new fault.
What does it cost?
The player-facing interface and engine must share progress information safely, and each game uses memory for its own changing state. The fault-in-result behavior covers only the watched game-step path. Setup and other fault paths can have different outcomes; we did not measure loading speed or memory cost.
What comes next?
In the next diary, we will explain how to find the day a population group needs an update instead of processing every group in detail each day.
Frequently asked questions
What can the player-facing interface show while a game is being set up?
The engine reports which meaningful part of setup is underway. Designing a percentage bar or loading screen is the player-facing interface’s job.
Do two games started from the same prepared package share one world?
No. They can reuse preparation data, but each game has its own changing state. Advancing them in turn does not change the other’s result.
Is a game step rolled back when a mod faults?
In the watched game-step path described here, no: the step stays applied and its normal result is returned with the fault. The faulting mod is stopped; this is not a general guarantee for every kind of error.
Did this work make loading faster?
We did not measure that. We verified that setup can run in the background and that its progress can be read.
We explained the reasons for mod limits in Developer Diary #13, and how mods connect to the engine in Developer Diary #8. Read Developer Diary #2 to learn why identical game results matter in multiplayer, explore MKA Engine and the developer diaries, or visit contact.