After nearly two months of intensive Dart and Flutter learning, I’m finally releasing the first public playtest build of AoNW, my 4X strategy game.

You can try it here: https://aonw.net

This is not a polished release. It is very much an unstable public test build for single player mode. Saves may break, progress may be lost, and weird things will definitely happen. I’m putting it out mainly so people can test the core mechanics, feel the game loop, and help me catch the rough edges early.

(more…)

When I started building multiplayer, I was not trying to bolt networking onto an existing single-player prototype at the last minute. A 4X game has a large world state, hidden information, turn submission, AI players, long reconnect windows, and plenty of tiny UI-only interactions that should never touch the server. I needed a multiplayer architecture that treated the server as the source of truth while still letting the Flutter client feel responsive.

This post walks through the architecture I ended up with: repository layout, protocol contracts, command dispatch, event log, snapshots, WebSocket replay, fog-of-war projection, deployment, observability, and tests.

(more…)

At some point after the first proper release of Age of New Worlds, I would like to make the project open source.

Not immediately. Not while the game is still changing shape every week. Not as a way to avoid finishing it. I want the game to stand on its own first: playable, understandable, and coherent enough that someone can experience it as a game, not only as a repository.

But after that, I want to open it.

Because Age of New Worlds has always been more than a private experiment for me. It started as a small project to learn the Apple ecosystem, Flutter, Flame, and the shape of building a game across client and server. Over time, it became a compact 4X architecture study: commands, reducers, projections, fog of war, AI, map editing, multiplayer safety, and a domain model that tries to stay testable.

That kind of project feels worth sharing.

(more…)

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.

(more…)

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.

(more…)

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.

(more…)

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.

(more…)

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.

(more…)

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.

(more…)