Ernest.dev

  • [AoNW] Refactoring a Growing Flutter 4X Game Without Rewriting It

    When I wrote the first article about Age of New Worlds, the project had reached the point where the core loop was real.

    I could explore a hex map, found cities, move units, manage production, research technologies, improve terrain, run turns, and save the game. The interesting question was no longer whether Flutter and Flame could support a 4X game. The question was whether the code could keep growing without turning every new feature into a negotiation with the entire repository.

    Since then, the project has grown in several directions at once.

    (more…)

  • [AoNW] Shipping a Flutter Game to Multiple Platforms

    Age of New Worlds is now available outside my development machine. The current release covers iOS, macOS, Windows, Linux, and Android, with a web demo, direct downloads, store versions, and source code available publicly. That was the original technical goal: build one game codebase and make it run on real platforms.

    Where To Play

    (more…)

  • [AoNW] Adding Gamepad Support to a Flutter 4X Game

    Age of New Worlds started as a mobile-first game.

    That shaped a lot of early decisions. The map had to work with touch. The HUD had to survive small screens. Panels had to slide in and out without burying the world. Most interactions were built around taps, long presses, drags, and responsive layouts.

    For a while, that was enough.

    Then the game started growing toward more platforms: web, desktop, Steam, and eventually devices like the Steam Deck. At that point controller support stopped being a nice extra and became part of the shape of the game.

    (more…)

  • [Peryhelium] Moving a 4X Game Domain From AoNW to Unity

    While waiting for Age of New Worlds to move through the publishing path for iOS, Steam, and Android, I tried a small experiment.

    This time in Unity.

    Not as a replacement for AoNW. More as a question:

    What happens if I take some of the mechanics and architecture from AoNW, move them into a 3D engine, and let the concept grow in a different direction?

    A few hours later, I had the first slice of Peryhelium: a space 4X prototype about colonizing the Solar System, starting with the Moon, previewing locked planets, and rendering spherical hex maps with real planetary textures.

    (more…)

  • [AoNW] Refactoring Multiplayer to Serverpod

    The first multiplayer implementation in Age of New Worlds was not a mistake.

    It was a proof of concepts.

    I needed to learn where the hard parts really were: command dispatch, reconnects, snapshots, event offsets, fog of war, match lobbies, AI turns, and the strange little edge cases that only appear when a turn-based game is running across two devices instead of one.

    That version used a custom Dart server, HTTP routes, WebSockets, JWT handling, PostgreSQL repositories, and a lot of glue code.

    It worked well enough to answer the most important question:

    Can this game have multiplayer at all?

    The answer was yes.

    But once the concept was proven, the shape of the problem changed.

    Now I do not need “a server that works”. I need a server architecture that is boring in the right places, strict in the important places, and easy to evolve without leaving a trail of networking code across the Flutter app.

    That is why I started moving multiplayer to Serverpod.

    (more…)

  • [AoNW] Turning Game History Into Something You Can Actually Use

    A strategy game is not only about making decisions.

    It is also about understanding them later.

    In Age of New Worlds, a turn can contain many tiny things: a scout discovers a new civilization, a city finishes production, a unit moves through fog of war, diplomacy changes slightly, a battle resolves, research progresses, and the player probably notices only half of it while thinking about the next move.

    (more…)

  • [AoNW] Containerizing and Deploying

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

  • [AoNW] Bringing a Flutter Game to the Web

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

  • First public test build of Age of New Worlds

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

  • [AoNW] How I Built Multiplayer for a Turn-Based 4X Game with Flutter, Dart, WebSockets, and PostgreSQL

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