Responsiveness in Age of New Worlds is not the same problem as responsiveness on a normal website.

A 4X game is dense by nature. It has a map, units, cities, resources, action buttons, panels, notifications, fog of war, overlays, turn state, and sometimes multiplayer information. The challenge is not only to “fit the UI on the screen”. The challenge is to keep the map playable while still giving the player enough information to make decisions.

That means I do not treat responsiveness as a final CSS-like pass. I treat it as part of the presentation architecture.

The UI has a difficult job. It has to feel like it belongs to a strategy game, but it cannot get in the way of the map. It has to show a lot of information, but it cannot become visual noise. It has to work for menus, HUD panels, modals, the map editor, multiplayer screens, and developer tools, but it cannot turn every screen into a hand-crafted exception.

A strategy game is not only code and rules.

It is also icons, unit sprites, terrain images, map textures, building symbols, technology art, sounds, music, overlays, and small visual markers that tell the player what is happening.

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.