Dev Diary #16: Separating the Map Tool from Game Choices
In short: MKA Engine’s map tool turns shared geographic data into map content a game can use. Historical borders, province groups (in-game administrative units made up of several small map locations) and regional layout are decisions made by the game; the tool applies those choices, while the game remains responsible for its map design.
What was the problem?
Small map locations, provinces and regions are more than shapes on a strategy map. Players use them to read control, neighbouring areas and routes for movement. Which period’s borders to follow, or which small locations should form a province, are design choices about each game’s world.
If the map tool builds those choices into its own defaults, game decisions become mixed up with the tool. A choice kept in two places can also drift over time; if a choice is missing, the tool might quietly substitute its own assumption. It then becomes harder to tell which decisions shaped the map.
This diary is about the separate tool that prepares map content for MKA Engine, not the engine’s simulation rules. The tool processes geographic data; it does not run the events and rules of a game world.
How did we solve it?
We separated shared geographic work from a game’s map choices. The tool provides a common method that different games can use. Each game decides which historical borders, province groupings and regions its map should follow.
During production, it is clear which game’s choices are being used. Work that prepares shared geographic data does not carry game-specific decisions; work tied to a game follows that game’s own map choices. The person preparing the map knows which design is being applied, and the tool does not choose a game on its own.
The next step was giving each map choice and the result it shapes a single owner. A game’s choice stays with that game, while shared geographic information remains available to all. If the same choice appears on both sides, or a required choice is missing, the tool does not make its own selection: it stops production and reports the conflict clearly.
Province grouping makes this distinction concrete. The game chooses which period’s country borders those groups should follow, and whether a province may extend across those borders. The map tool does not set that policy; it groups locations according to the chosen approach.
To form the base of a province, the process first uses historical administrative units; where those are unavailable, historical city centres and present-day administrative boundaries act as supporting sources. Smaller pieces are then split or joined with neighbours according to the game’s chosen border policy. The game also defines the names and extent of larger area and regional groups; the tool carries that layout onto the map.
An example game included with the tool can run without Mandates of History. This shows that the tool’s method is not bound to one game’s own map choices.
What did we observe?
Responsibility for production is easier to follow: the game owns the map choices, and the tool applies them. Missing or conflicting choices become visible during production, so it is possible to trace which historical period and grouping decisions shaped the map.
What does the player see?
Players do not see where choices are stored; they see which provinces the small locations form and how the borders follow the selected period. One game can keep provinces within the country borders of that period, while another can allow historical units to cross them. The tool carries each game’s choices through to its map, helping the layout match that game’s design; this changes map preparation, not the rules of game simulation. The accuracy of the source borders still depends on the data used.
Why did we choose this approach?
Map choices describe a game’s world, so keeping them as fixed assumptions inside the tool would put responsibility in the wrong place. Letting each game retain its own decisions allows a shared tool to serve different world designs.
Keeping a choice with the map result it shapes also makes that result easier to trace. A single-owner rule avoids a hidden priority for deciding which of two conflicting definitions should win. When information is missing, the tool reports the problem early instead of guessing.
What does it cost?
Each game must maintain its own map choices, and production must use the right set. No time or memory measurement was reported for this structural change; the example game does not prove full map production for another real game or guarantee the historical accuracy of source borders.
What comes next?
Map choices also affect how borders appear against the terrain. We described work on making impassable-terrain borders look more natural in Diary #17.
Frequently asked questions
Does the map tool run the game?
The map tool prepares map content for the game to use. Simulation of the game world is a separate part of the process.
Does every game use the same borders and province layout?
Historical period, border policy and grouping are choices each game makes. The tool applies those choices rather than imposing one layout on every game.
What does “province” mean here?
A province is an in-game administrative group made up of several small map locations. The game’s map choices determine which locations belong together.
Does the example game prove full support for another game?
It shows that the tool can run without Mandates of History. On its own, it does not prove that another real game’s full map-production process has been completed.
Links
Learn where the map tool fits in MKA Engine on the MKA Engine page. For persistent map keys, read Diary #10; for more diaries, visit the developer diary list. You can also contact us through the contact page.