When I showed Age of New Worlds 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. I can still build a process that gives me more control over the result.

The Goal Is to Replace the Generated Maps

Language models are part of my development process, but they are not the project. Dart and Flutter are not my main stack either. I have been learning both while working on AoNW, and now I am also learning Godot, terrain editing, 3D cameras, lighting, image processing, and procedural vegetation.

The important point is that the new map pipeline is not meant to generate more assets with AI. It is meant to replace the existing AI-generated maps with terrain that I can edit, control, and improve myself.

Besides the ongoing architecture refactor, I prepared the first version of a small Godot editor pipeline for AoNW maps. It works with the existing game format instead of introducing a second format used only by the editor.

An AoNW map contains a map.json file and a collection of image slices named after their column and row. The importer reads the JSON, loads the map dimensions and tile data, and joins the existing slices into one large reference image.

The same data is used to create an initial heightmap. Ocean and lake tiles are placed below the normal terrain level, hills and mountains receive additional elevation, and the numeric height stored in each tile adds another part of the final shape. The result is smoothed and imported into Terrain3D.

The original map image is then projected over the terrain as a reference overlay. I can change its opacity or hide it completely while sculpting coastlines, mountains, valleys, and other details.

I also plan to use Tree3D together with Terrain3D. Terrain3D handles the shape of the land, while Tree3D provides procedural trees that can be used to build forests and other vegetation without placing every tree by hand.

flowchart LR
    Existing["Existing AoNW map<br/>map.json + image slices"]
    Import["Godot importer"]
    Reference["Stitched reference image"]
    Height["Generated heightmap"]
    Terrain["Terrain3D sculpting"]
    Trees["Tree3D vegetation"]
    Render["Tilted 3D render"]
    Slice["Hex tile slicer"]
    Output["AoNW map.json + image slices"]

    Existing --> Import
    Import --> Reference
    Import --> Height
    Reference --> Terrain
    Height --> Terrain
    Terrain --> Trees
    Trees --> Render
    Render --> Slice
    Slice --> Output

Exporting Back to the Existing Game

The export process works in the opposite direction. The tool hides the reference overlay, renders the complete scene through a tilted orthographic camera, and captures the result inside a Godot SubViewport.

The rendered image is then divided using the same hex-grid geometry, dimensions, file names, rounding, and edge cropping that AoNW already expects. Most tiles are 160 by 120 pixels, while tiles at some map edges can be smaller because the rendered image ends there.

For a 25 by 19 map, this produces 475 separate image files. A small difference in rounding would be enough to create visible seams, so the tool uses the same coordinate calculations as the existing Flutter editor.

The original JSON data is preserved as well. Objectives, resources, terrain definitions, tile heights, map dimensions, and other gameplay data should pass through unchanged. Godot reads JSON numbers as floating-point values, so the exporter also needs to make sure that values such as tile heights are written back as integers where the Dart parser expects integers.

The pipeline has headless tests for the hex-grid geometry, JSON round-trips, image stitching, slicing, heightmap generation, and map dimensions. The final test is simple: export the map, place it back in AoNW, and load it through the existing game code.

This is not a one-click AI map generator. It does not create a finished world after one prompt. It gives me a starting point based on the existing map, after which I can sculpt the terrain, change the vegetation, adjust the camera, and repeat the export until the result works in the game.

Unit Assets Are a Different Problem

Maps can be improved through a combination of existing data, generated height, procedural vegetation, and manual editing. Unit assets need a different approach because they require consistent proportions, clear silhouettes, equipment variants, and animations that work together.

At a later stage, I want to commission a 3D artist to prepare dedicated unit models and animations. Those assets can still be used in the current 2D game by rendering them from fixed camera angles into sprite sequences.

The original 3D models could still be useful to someone creating a fork of the project. Personally, though, I think I prefer the look and readability of stylized 2D maps.

I Do Not Want to Monetize AI Slop

I am not doing this because I am worried that someone on the internet may call my game AI slop. That label often comes from judging only what is visible in a screenshot, without knowing how the project works technically or how much a language model can realistically produce and maintain under the limits of a normal subscription.

Still, temporary assets look temporary, and I want the visual side of the game to improve.

I also do not want to monetize AI slop. Age of New Worlds is open source and available for free on itch.io

The current assets helped me move from an empty project to a playable game, but they are not the point where I want to stop. I want to develop AoNW for years, not only for a few weeks or months, which means improving the mechanics, interface, architecture, maps, and eventually the complete visual layer.

It also means gaining new skills and raising my own level of competence. AoNW has already helped me learn Dart and Flutter, and the map pipeline now gives me a practical reason to learn Godot, GDScript, terrain editing, procedural vegetation, 3D rendering, and tool integration.

Releasing Early Was Still the Right Decision

Publishing the game in its current state was not a mistake. Without a public build, most feedback would still come from me testing my own assumptions.

Technical feedback can reveal bugs. Gameplay feedback shows which mechanics are unclear or unbalanced. Visual criticism shows which temporary elements are already limiting the experience. Not every suggested solution is useful, but the signal still helps me decide what to improve next.

The temporary AI-generated assets allowed me to release the game earlier. The new pipeline gives me a way to replace them without stopping development of the mechanics, interface, and architecture.

The next map should not be better because I found a better prompt.

It should be better because I now have a process that gives me control over the result.