Developer Diaries

In short: In MKA Engine, rules for game and mod content are defined in text files. Three distinct rule forms check a state, change the game world, or calculate a number. This separation creates a clear boundary between content written by game makers and the machinery that runs it.

In a strategy game, a country's tax, an army's movement, or the condition for an event is often connected to other rules. Think of a rulebook: one sentence asks, “Is this true?”, another makes a change, and a third calculates an amount. When these jobs become mixed together, a small content change can lead to an unexpected result. We organized rules around these three different tasks.

Which rule-writing tasks were getting mixed together?

In a board game, a referee checks players' moves against the rules. The rulebook describes the game world. Knowing how the referee works should not be a requirement for writing a rule for a new country or event. At the same time, someone writing a new rule should not be able to accidentally create an endless loop that stops the whole game.

In MKA Engine, game content is not one fixed structure embedded in the engine; it consists of data defined by games and mods. So rules need to be readable, separated by purpose, and able to report mistakes clearly. Someone changing a tax condition should not accidentally change the calculation itself or the order in which the world runs.

Keeping conditions, effects, and formulas distinct

The first distinction is what a rule does. A condition asks a question about the current state of the world. For example, it can check whether a country's treasury is above a certain amount. A condition returns only yes or no; it does not change values in the world.

An effect makes a change in the game world. Adding money to a country or changing the value of a property belongs here. Effects are applied in the order they are written. This means the next effect can see the change made by the previous one. The rule's story is easy to follow: first evaluate the condition, then apply the appropriate change.

A formula calculates a number. A tax amount or another quantity can be derived from current values. Its calculation steps follow a defined order; a formula does not change the world by itself. As a result, asking a question, making a change, and calculating an amount cannot stand in for one another.

This separation is more than a writing convenience. A condition that does not change the world can be safely asked in different places. A formula that only produces a number makes it easier to understand where a calculated value came from. Making effects the explicit place for changes also makes those changes easier to trace.

We made a deliberate choice about loops as well. Formulas do not repeat themselves in loops; their order and endpoint are known from the start. If a condition-driven effect loop reaches its round limit while the condition still holds, that effect chain stops with an error record. Changes made before the loop remain; later steps in the same chain do not run. In the event-choice path, this error is recorded for the current step and does not prevent the next step from proceeding.

We also define how rules connect to one another. A condition can inspect the part of the world it is connected to; if the connection is empty, the inner check evaluates as false. An outer rule that looks for that false result can make the whole condition true. Effects, in turn, see the state left by earlier effects in the same sequence. That order helps the world progress consistently for every player.

When does a rule act in the game?

Within a strategy game's day, commands, timers, content rules and systems run in a defined order. The game's content rules are evaluated after commands and timers, but before systems. This order determines when a change becomes visible.

For example, a marker written by a system at the end of a day is not something a content rule can see retroactively in that same moment; it becomes visible in the next step. By contrast, a value written by a content rule can be seen by systems that run later that day. This gives a consistent answer to the question, “Which value did the rule see?”

How do three rule roles clarify the flow?

This diary does not present a new speed or memory measurement. The verifiable result here is the behavior boundary of the rule language: a condition checks, an effect changes, and a formula calculates a number; formulas have no loops. If a condition-driven effect loop is still running at its limit, that effect chain stops with an error diagnostic.

These behaviors are described in the MKA Engine scripting guide. The country, province and gold examples in the engine's example world show how different rule forms can be used. They are illustrations, not claims about a complete game feature or game balance.

Why make each rule's role explicit?

Putting every task into the same kind of rule might have looked shorter. But if a condition both asked a question and changed the world, reusing it could create side effects in every place it was checked. Adding unrestricted repetition to formulas would make content more flexible while making it harder to predict when it would finish.

Instead, we gave each rule form one responsibility. A condition checks, an effect changes, and a formula calculates. Bounded traversal prevents a rule over a large collection from running without limit. This creates a clear balance between flexible content and orderly game progression.

Limits of separating rule responsibilities

This design does not let every kind of calculation be written in content files; a more extensive mechanism may need to be developed in the engine. The upper limit on condition-driven effect loops restricts very long repetitions; if the condition still holds at the limit, the remaining steps in that chain do not run.

Moving from rules to events and modifiers

After separating the jobs of rules, we will explain how events and modifiers use them. That will let us follow, step by step, how a decision a player encounters connects to conditions and consequences in the game world.

Frequently asked questions

Sources

• MKA Engine scripting guide.
• This diary makes no performance-measurement or cross-game comparison claims.

For more, see MKA Engine, developer diaries, and contact.