Ernest.dev

Author: ernest

  • [AoNW] Movement on a Hex Map: Pathfinding, Costs, and Player Intent

    After the map exists, the next question is simple: how does a unit move through it?

    In a strategy game, movement looks like a visual feature. A unit slides from one hex to another. A path appears. The camera follows. Fog reveals new terrain.

    But movement is not animation.

    Movement is a domain rule. Animation is only how the result becomes visible.

    (more…)

  • [AoNW] Building the Game Map: Data, Hex Geometry, and Rendering

    In Age of New Worlds, the map is not just a background.

    It is the board, the terrain model, the input surface, the rendering foundation, the source of movement rules, the basis for city placement, the thing fog of war hides and reveals, and the content artifact that I need to edit, validate, save, and ship.

    That means the map cannot be only an image.

    (more…)

  • [AONW] What Each Player Is Allowed to Know: Projections, Fog of War, and Multiplayer State

    An authoritative server knows the whole match.

    That sounds obvious, but it creates one of the most important architectural questions in Age of New Worlds: if the server knows everything, what exactly should each client receive?

    In a local game, this question is mostly about UI. In multiplayer, it becomes a data boundary.

    (more…)

  • [AoNW] Building AI That Uses the Same Commands as the Player

    AI in a strategy game can easily become a second game hidden inside the first one. That is dangerous.

    If the AI has its own movement rules, its own production shortcuts, its own visibility model, or its own private way of mutating state, then every new feature has to be implemented twice: once for the player and once for the AI. Worse, bugs become harder to reason about because the AI is no longer playing the same game.

    In Age of New Worlds, I want the AI to use the same language as the player. That language is commands.

    (more…)

  • [AoNW] From Hotseat to Multiplayer: Making the Server Authoritative

    Age of New Worlds started with local play. That was the right place to begin. A 4X game already has enough moving parts before networking enters the picture: turns, units, cities, production, research, fog of war, saves, UI state, and AI. Adding multiplayer too early can turn every feature into a distributed-systems problem.

    But I did not want local play to become a dead end.

    So even while the game focused on hotseat, I tried to shape the architecture around a future server-backed model. The main rule was simple:

    Local play can be convenient, but multiplayer must be authoritative.

    (more…)

  • [AoNW] Saving game: Snapshots, Event Logs, and Migrations

    Saving a sounds simple until the game starts becoming a real 4X game.At the beginning, it is tempting to think of saving as one operation:

    jsonEncode(gameState)

    That works for a prototype. It does not work for long.

    (more…)

  • [AoNW] The Domain and Application Layers: Where the Game Actually Lives

    A 4X has many different kinds of decisions. Some are game rules. Some are player workflow. Some are persistence. Some are rendering. Some are network concerns. If I let all of them live in the same place, every new feature becomes harder than it should be.

    So the project uses a DDD-inspired split between the domain layer and the application layer.

    The domain layer answers: what is true in the game?

    The application layer answers: how do I perform a use case around that truth?

    (more…)

  • [AoNW] General Architecture Overview

    Age of New Worlds is strongly DDD-inspired. I use domain boundaries, application ports, infrastructure adapters, commands, events, projections, and persistent snapshots because a 4X game becomes complicated very quickly. The architecture is there to answer one question:

    How do I keep the game understandable when rendering, UI, AI, saving, hotseat play, and multiplayer all want to touch the same state?

    (more…)

  • [AoNW] Fog of War: Separating What Exists from What the Player Knows

    Fog of war looks like a visual feature. The map gets darker. Unknown territory disappears. Previously explored land stays dim. Enemy units appear and vanish. It feels like something that belongs mostly to rendering.

    But in AoNW, fog of war is not just an overlay. It is one of the systems that forced me to separate three different ideas:

    • what exists in the game world
    • what a player has discovered
    • what a player can currently see

    That distinction matters everywhere. It affects rendering, selection, movement, combat previews, AI decisions, event visibility, and eventually multiplayer.

    (more…)

  • [AoNW] Rendering a Hex World with Flutter and Flame

    Age of New Worlds is built in Flutter, but the map itself is not a normal Flutter widget tree.

    That was one of the first architectural decisions I had to make. A 4X game has a lot of ordinary UI: menus, panels, buttons, overlays, localization, routing, settings, loading states, and HUD elements. Flutter is excellent for that.

    But the game map is different.

    (more…)