Ernest.dev

  • [AoNW] The Refactor So Far: From a Rust Movement Slice to Integrated Turns

    A few days ago, the Rust engine was mainly a successor path with movement, local sessions, contracts, and a growing set of isolated gameplay slices.

    Now it is becoming something much bigger: https://engine.aonw.net

    The latest changes add turn processing for production, research, diplomacy, economy, objectives, and match outcome resolution. Combat, cities, workers, roads, logistics, artifacts, save/replay contracts, and recipient-safe views are also part of the Rust workspace.

    This changes the shape of the migration. The Rust engine is no longer only proving that one command can cross a native boundary. It is starting to prove that a complete turn can live behind the same deterministic boundary.

    (more…)

  • [AoNW] Some ongoing UI work…

  • [AoNW] One Game, Two Views: Extracting the Rust Engine and Building AoNW2 in Godot

    The existing Flutter and Flame client received many new gameplay systems, multiplayer improvements, performance fixes, and better release tooling.

    But the biggest recent change is architectural.

    I started separating the game itself from the technology used to display it.

    The long-term structure will have:

    • AoNW1, the existing 2D client built with Flutter and Flame
    • AoNW2, a new 3D client built with Godot
    • one shared game engine written in Rust
    • one Serverpod multiplayer backend
    • one set of rules, maps, commands, events, saves, and multiplayer contracts

    This is not a plan to abandon AoNW1.

    It is a plan to make the game independent from both Flutter and Godot.

    The most important product decision is also simple:

    AoNW1 and AoNW2 will use the same multiplayer system. Players using the 2D and 3D clients will be able to join the same matches.

    From the gameplay point of view, both clients should be the same game.

    The difference should be presentation:

    • AoNW1 shows the world as a 2D hex map
    • AoNW2 shows the same world as a 3D scene

    They will not have separate combat rules, separate balance, separate AI, or separate multiplayer servers.

    (more…)

  • [AoNW] An Interactive Map of the Game Architecture

    Most of the recent work on Age of New Worlds has happened below the visible game.

    The shared engine, multiplayer flows, state boundaries, runtime services, deployment, and quality gates have gradually become one connected system. Describing these changes across separate refactor posts was useful, but it was still difficult to see the whole repository at once.

    I have now published an interactive AoNW Architecture Atlas. It lets you explore the repository by module, follow the main application flows, and distinguish the current implementation from accepted migration targets.

    Explore it here: aonw.net/architecture

    This is not an architecture frozen in time.

    It is a snapshot of where the project is now, and a map for where the next changes belong.

  • [AoNW] The Refactor So Far: Breaking Up the Runtime Around the Game Engine

    Since the previous refactor update, Age of New Worlds has kept one canonical GameEngine, but the runtime around it has changed substantially. The main game-state provider, Flame renderer, network session layer, and Serverpod multiplayer services have been split into explicit responsibilities. At the same time, presentation parity tests and aggregate architecture budgets now make it harder for the same complexity to grow back under different filenames.

    Finishing the shared game engine did not finish the refactor.

    (more…)

  • [AoNW] The Refactor So Far: Finishing the Shared Game Engine Refactor

    Since the previous refactor update, Age of New Worlds has moved local play, multiplayer, AI simulations, replay, presentation effects, and match lifecycle behind one canonical game engine. The visible result is fewer synchronization bugs. The architectural result is one authoritative path from command to state, events, and animation.

    Since the previous refactor update, most of the work has not been about adding another visible system.

    It has been about removing alternative ways in which the same game could be interpreted.

    (more…)

  • [AoNW] The Refactor So Far: Movement Now Survives the Network

    In the previous update, AoNW already had one canonical turn pipeline and a growing set of shared game rules. Local play, the multiplayer server, AI simulations, and turn processing were starting to use the same implementations instead of maintaining similar versions of the same behaviour.

    Movement was one of the largest parts of that work. Manual movement, auto-exploration, queued paths, fog updates, and AI movement had moved toward one shared model. The engine could calculate the exact route taken by a unit, including every step and its movement cost.

    (more…)

  • [AoNW] The Refactor So Far: One Turn Pipeline and Shared Game Rules

    In the previous update, the legacy map adapter was gone and DomainState had become a real part of the application. Most of turn finalization already used the new state, but one old section remained in the middle: the economy phase still converted the canonical snapshot to PersistentGameState, processed the turn, and converted the result back.

    That legacy island is now gone.

    The complete simultaneous turn now stays on canonical or persistence-neutral types, and the old persistent implementation of simultaneous finalization has been removed. At the same time, the same migration pattern is spreading through normal player commands, where local play, the multiplayer server, and AI previously had separate versions of similar rules.

    (more…)

  • [AoNW] My Perspective on Using Language Models in Indie Game Development

    When I showed my game to a wider audience for the first time, many people focused on the visuals and called the game “AI slop”. This was mostly a reaction to the generated maps, units, icons, and other assets that were visible in screenshots.

    I understand where this reaction came from. A screenshot shows the map before it shows the game rules, multiplayer synchronization, AI simulations, save migrations, tests, or the architecture behind the project. It presents the weakest part of the current build first.

    I already explained my perspective in an earlier post. I have always treated the existing assets as visual boilerplate for future dedicated assets, not as the final art direction. They allowed me to focus on mechanics, release a working version, and collect feedback without waiting until every part of the game looked finished.

    Since then, I have not become a graphic artist, and I did not suddenly wake up with a talent for painting terrain. But still I can build a process that gives me more control over the result.

    (more…)

  • [AoNW] The Refactor So Far: The Map Adapter Is Gone and DomainState Is Real

    In the original refactor post, I described the target architecture and a plan for reaching it without rewriting the whole game. In the previous progress update, the project already had stronger quality gates and one indexed map model, but the migration was not complete because two production conversions still existed, the legacy map adapter was still alive, and DomainState was mostly a target shown on a diagram rather than a type used by real gameplay paths.

    That is no longer the current shape of the project. The last map adapter has been deleted, the local reducer uses read-only map contracts, several old state models now own their collections instead of borrowing mutable lists and maps, and a real DomainState exists together with a canonical snapshot that separates game rules, match session data, metadata, persisted interaction, and the event offset. Turn combat and turn movement now run directly on this canonical state, while only the economy phase still uses the old persistent model.

    (more…)