The road to a game engine

In our first post we explained why we are writing our own grand strategy engine, and in the second the thinking behind that decision. This post goes into the kitchen: how we started an engine, in what order we are moving and where we are now.

First we read the games#

Before writing any code, we went through every system the player touches in the four best-known games of the genre (Europa Universalis, Victoria, Crusader Kings and Hearts of Iron). Population, economy, trade, diplomacy, war, characters, events, maps. We asked each the same question: is this a mechanism, or a rule of one game?

That distinction became the backbone of the whole project. "How is a value computed quickly and correctly every day" is the engine's job. "How is war declared, how is peace made" is the game's job. Only content-free mechanisms that several games use with different rules go into the engine. Everything else stays in the hands of the game or of mods.

Determinism is not a rule, it is the law#

In a multiplayer strategy game, every player's computer computes the same world on its own; only commands travel over the network. This method has one condition: the same start and the same commands must give the exact same result, bit for bit, on every machine. A tax that comes out one cent different on one computer leads, a few years later, to two players playing in completely different worlds.

That is why the engine core uses no floating-point numbers; all calculations use fixed-point numbers. Randomness comes from a single source, derived from a seed. Clocks, files and the network cannot enter the core. We run the same tests on different processor architectures and on the version that runs in the browser, and compare the results.

Step by step, every step measured#

We split the engine into phases and wrote an exit criterion for each one up front. A phase does not close until its criterion holds. Roughly, the order went like this:

1. Numbers, randomness and how data is laid out in memory
2. Entities and the state of the world
3. Commands, saving and replay
4. Content database and languages
5. Events, modifiers and infrastructure that recomputes only what changed
6. Shared mechanisms for systems such as population, economy and diplomacy
7. Mod hosting and developer tools
8. Multiplayer

At the end of every phase we measure how long one game day takes to compute. Our target is to compute a day in a few milliseconds even in the late game, with tens of thousands of provinces and millions of population units.

Mods are first-class citizens#

What extends the life of this genre is mods. We go one step further and build the game itself as a mod. A mod can patch content, add a new system, or switch an existing system off entirely and put its own in place. Mods run in a safe sandbox; a mod cannot access files on the player's computer.

Where are we now?#

The core, the save system, the mod interface and a first version of the multiplayer infrastructure are written and passing their tests. We are now working on the engine-level principles of AI and war. A map pipeline that prepares a real-world map for games is also growing alongside the engine.

There is no playable game yet, and we are not hiding that. Not moving to the game before the engine is done is a deliberate decision. If the foundation is not solid, everything built on it will collapse one day.

For those who want to follow MKA Engine closely, there is an MKA Engine page on our Turkish site. We will keep writing here as the road goes on.