For a long time I could run the Flutter app. I could run the Dart server. I could start a database. I could test multiplayer locally. That was enough while everything lived on my machine.

But a public build changes the shape of the problem.

Suddenly the project needs a real URL, TLS certificates, a running backend, a database that survives restarts, a static web bundle, a homepage, health checks, version numbers, iOS archives, and one command that can push the whole thing without me reconstructing the release process from terminal history.

(more…)

When I started building Age of New Worlds, I was thinking mostly about the native app.

Flutter gave me the UI layer. Flame gave me the game scene. Dart gave me a shared language for the client, the rules, the AI, and the server. That was already enough complexity for a solo project.

Then I wanted one more thing: a public web version.

Not because the browser is the best place to play a heavy 4X strategy game. It is not. The native app is still the better experience. But the web version solves a very practical problem: people can open a link, see the game, start a match, and give feedback without installing anything.

(more…)

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…)