Developer Diaries

The diaries we keep while building MKA Engine: what we built, why, and what we measured.

The diaries we keep while building MKA Engine. Each diary covers one decision, the reason behind it and the result we measured. For the engine itself, see the MKA Engine page.

Developer Diaries

Dev Diary #12: Time Series and Reading Data by Name

· Open separately

A wall calendar with brass pins marking the first days of the months; in the open notebook in front of it, a small line chart with dots

In short: A time series is a value recorded over periods such as days, months or years. In MKA Engine, the game chooses what to keep and how often; the player's interface can request that history by name and display it as a chart.

Later feature update (26 October 2026): The time-series and named-data-reading work developed on 26 October was added to this diary later. Its original content date remains 18 October 2026.

What problem were we solving?

We wanted players to follow a city's population or a treasury over several years. If the question is about a year-end trend, saving a value at every game step adds more points than the answer needs.

There is another need: understanding where a number on screen came from. When a player sees total income, it can help to show the rule effects that contributed to it. The engine's job is not to draw the chart; it is to provide the game's declared information in an orderly, readable form.

How did we solve it?

One sample at a calendar interval

Think of recording one note for the game step that contains the month's first day instead of tracking every day separately. We separate what the game wants to follow from how the interface reads that history: each city's population can be kept separately, or all cities can be combined into one total. The game chooses a daily, monthly or yearly interval and how many periods to retain; older points are removed once they fall outside that window.

A sample is recorded at the barrier—the designated recording point—of the game step that contains the period's first day. In a weekly game, one monthly value is recorded for the step containing the month's first day; later weeks in the same month add no second point.

A strategy map is divided into calendar-like weekly bands, with the week containing the month's first day highlighted in orange; beside it, a notebook shows one sample for that game step.

Reading a value by name

This is like a labeled filing cabinet: the interface asks for a value by name, and the engine returns the matching history. It can request a city's population history; the engine returns its points in period order, while the game's interface chooses the chart's appearance and labels.

The same idea works for a single value. The interface can request a country's treasury by name. When it reads a total built from bonuses and penalties, the engine can also return the contributing effects alongside the total, so the interface can explain how the number was formed.

Markers for three towns connect to separate measurement rows in a notebook; at right, three line series form a chart, and contribution tokens lead to a combined total.

What did we see?

With weekly game steps and a monthly history, one sample is recorded at the step boundary for the game step containing the month's first day. The game can keep separate city values or a combined total; old points are removed when the chosen retention period expires. After a save and reload, the existing points and the next period to sample remain the same.

If a weekly game requests daily sampling, setup rejects that series and points to its content record by file, line and column.

Why did we choose this approach?

Rather than fixing these choices for every strategy game, we provide ordered samples and values that the interface can request by name. A game can show a population chart or a treasury total, while the presentation remains its own design choice.

What does it cost?

A monthly sample cannot show daily changes inside the month. For the same span of game time, more frequent sampling creates more points; we did not measure timing or save-file size for this feature.

What comes next?

The engine supplies the samples and named values. Each game's interface chooses how to present them in charts and explanations; this diary does not prescribe that visual design.

Frequently asked questions

How does a monthly sample work with weekly steps?

One monthly value is recorded at the step boundary for the game step containing the month's first day. Later weeks in that month add no second point.

Can I see every change inside a month?

A monthly sample shows the value recorded at the step boundary for the game step containing the month's first day, not every daily change within the month. A game that needs a more frequent history can choose a shorter interval.

Does the engine draw the chart?

No. The engine returns samples and named values; the game's interface chooses the line, scale and labels shown to the player.

Do the readings survive a save and reload?

Yes. Kept samples and the next sampling period are preserved in the game save. Points older than the chosen retention period are not kept.

Sources and links

For questions or suggestions about this diary, write to us through the contact page. For an overview, see the MKA Engine page; the full list is on the Developer Diaries page.