Testing a 4X game is strange.

A lot of the game is visible: the map, the units, the HUD, the fog of war, the city panels, the turn button. But the most important parts are not visual at all. They are rules, constraints, transitions, contracts, and boundaries.

The presentation layer has a tempting job.

It shows the map. It reacts to clicks. It animates units. It displays city panels, movement previews, action buttons, fog of war, territory, alerts, and turn information. From the player’s perspective, this layer often feels like “the game”.

But architecturally, it is not the game.

The presentation layer is the place where the game becomes visible and interactive. It is not the place where the rules are decided. That distinction became one of the most important boundaries in the project.

When I started development, I was not trying to collect as many packages as possible. I wanted the opposite: a small set of Flutter and Dart libraries, each with a clear responsibility.

A 4X game can easily become a place where everything talks to everything else. The renderer wants to know about units. The UI wants to know about commands. The save system wants to know about state. The server wants to replay decisions. If I let every layer depend directly on every other layer, the project would become painful very quickly.

At some point, every strategy game becomes a content problem.

The rules can be elegant. The renderer can be pretty. The AI can make decent decisions. But if creating and adjusting maps is slow, every gameplay idea becomes expensive to test.

That is why Age of New Worlds has a map editor early.

Not because the game is finished. Not because the editor is polished enough to be a public tool. But because the editor makes the game easier to build.

It looks like one in the UI, of course. The player presses “end turn”, the game moves forward, and the next decision appears. But architecturally, that click is only the entry point into one of the most important pipelines in the game.

A turn boundary is where delayed systems become real.

In a 4X game, founding a city is one of the most important clicks the player makes.

It looks simple from the outside. A settler stands on a tile, the player presses a button, and a city appears. But that single action changes the meaning of the map. A neutral tile becomes a capital. Nearby terrain becomes territory. Future production, research, growth, defense, expansion, and victory scoring all start to orbit around that decision.

In Age of New Worlds, city founding is not treated as just spawning a city object.

It is the moment where individual hexes become an empire.

After the map exists, the next question is simple: how does a unit move through it?

In a strategy game, movement looks like a visual feature. A unit slides from one hex to another. A path appears. The camera follows. Fog reveals new terrain.

But movement is not animation.

Movement is a domain rule. Animation is only how the result becomes visible.

In Age of New Worlds, the map is not just a background.

It is the board, the terrain model, the input surface, the rendering foundation, the source of movement rules, the basis for city placement, the thing fog of war hides and reveals, and the content artifact that I need to edit, validate, save, and ship.

That means the map cannot be only an image.

An authoritative server knows the whole match.

That sounds obvious, but it creates one of the most important architectural questions in Age of New Worlds: if the server knows everything, what exactly should each client receive?

In a local game, this question is mostly about UI. In multiplayer, it becomes a data boundary.