Contents
In short: MKA Engine now offers two calendar choices for a game: a 365-day year with no leap days, or the leap-year Gregorian calendar. The game’s choice is stored with the save, keeping February 29, the passage of dates, and the calendar rule of a saved world in sync.
What was the problem?
In earlier diaries, we described how game time advances independently of the computer’s clock, and how the engine schedules work at the start of a month or year. The calendar is the ground beneath that schedule. If an empire’s anniversary, tax period, or historical event must fall on the right day, the game’s calendar rule needs to be explicit too.
At first, the engine’s year was always 365 days long. That made a regular calendar straightforward, but it could not represent a leap day for a game using the Gregorian calendar. A one-day difference in a calendar does not stay confined to a date display: it shifts the next month and year boundaries. That can also affect when date-based events and monthly or yearly work run.
Think of it as the calendar rule of a tabletop strategy game. Even when players share the same map, they need to agree on how long the year is before play begins. If one player moves straight from February 28 to March 1 while another plays a February 29, their idea of “today” has diverged. The engine needs to know which rule it is following and keep that rule for the whole game.
How did we solve it?
We made the calendar a choice for each game. The default in MKA Engine is a 365-day calendar with no leap days. The second choice is the Gregorian calendar. In that calendar, years divisible by four are leap years, except century years; century years divisible by 400 are leap years again. For example, 2000 is a leap year, while 1900 is not. February therefore has a 29th day when the rule calls for it.
“Gregorian” here means more than the way a date is displayed. The selected calendar converts the running day count into a year, month, and day. A monthly step ends on the first day of the next month, and the selected rule determines where that boundary falls. Yearly schedules and calculations tied to calendar periods use the same choice. Date display and simulation time stay connected.
The calendar is chosen when a game is set up. The starting date is interpreted under that rule, and the engine advances steps using it. Days, weeks, months, and years all come from the same calendar. A game can choose the regular 365-day pattern or the Gregorian pattern; the engine does not silently switch between them.
The choice travels with the save. When the game is saved, its calendar type is stored alongside its date. When loading, the engine compares the saved calendar with the one selected for the game being opened. If they differ, the engine returns a calendar-mismatch load error. The same day count can correspond to a different month and year under another calendar.
We also accounted for older saves. Saves created before the calendar type was added had no recorded leap-year choice. During migration to the current format, they are assigned the 365-day calendar. That lets older saves continue under the previous default without retroactively adding a leap-day rule that they never had.
What did we find?
We checked the boundaries of ordinary and leap years separately. We verified the four-year rule, the century exception, and the four-hundred-year exception. We also checked that converting a date to a day count and back returns the same year, month, and day across month and year boundaries. This shows that the calendar arithmetic remains consistent over consecutive dates, not just a few familiar examples.
We also checked the engine’s time calculations with the new calendar choice. The next monthly step lands on the first day of the next month; yearly work tied to a calendar boundary uses the correct year; and the leap day appears in the sequence of dates. These are code- and test-verified behaviors, not a speed measurement.
The difference is easiest to see in February. In the 365-day calendar, February always has 28 days. In the Gregorian calendar, February has a 29th day in years that meet the leap-year rule. That extra day matters to the dates that follow as well: the engine must place the next month and year boundaries on the right day.
Why did we choose this approach?
A single fixed calendar kept the first version of the engine simple; we described that choice in Diary #1. But every strategy game does not have to treat time the same way. Some games may want a regular calendar where every year has the same length. Others may want to follow dates with Gregorian leap years. Leaving the choice to the game avoids imposing one idea of time on every project.
At the other extreme, we could have allowed the calendar to change freely when a save is loaded. We did not choose that. A save represents not only how many days have passed, but also the calendar used to turn those days into years and months. Changing the calendar can change the displayed date for the same day count and can shift future calendar-based work. The save therefore keeps its own calendar choice and cannot be opened under a different one.
This topic is close to Diary #19, but it is not a repeat. Diary #19 explained when daily, monthly, or yearly work is called, and how those calls behave when a game step spans a longer period. This diary focuses on the question underneath that scheduling: “Which calendar defines a year and a month?” The calendar defines time; the game or mod chooses which work runs in each period.
What does it cost?
The game’s calendar choice is preserved with its save, so a player cannot continue that save under a different calendar. This boundary prevents dates and period starts from changing silently.
What comes next?
Counting days correctly makes the history of a strategy world more dependable.
Frequently asked questions
How does MKA Engine determine leap years?
In the Gregorian calendar, years divisible by four are leap years; century years are exceptions unless they are also divisible by 400. Under that rule, 2000 is a leap year and 1900 is not.
Does every game have to use the Gregorian calendar?
No. A game can choose either the 365-day calendar or the Gregorian calendar with leap years. The 365-day calendar is the default.
Can a save be opened with a different calendar?
No. A save carries its calendar type, which the engine compares with the current game choice during loading. If they differ, the engine returns a calendar-mismatch load error.
Which calendar do older saves use?
Older save formats from before the calendar choice was recorded are interpreted as using the 365-day calendar. This avoids assuming a new leap-day rule for a save that never stored one.
Links
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.