Dev Blog #3 - Grid: From a Napkin Sketch to a Scalable Visualization System

This system is used for many gameplay features, and it will continue to grow as the game evolves.

It Started with a Simple Idea

One day (as it usually happens), our lead came to me and said something like:

“We need a system that visualizes complex calculations on the grid. This will be the foundation for future gameplay tasks. It needs to show several zones and metrics at once, layered on top of each other - and the player must instantly understand the result.

Most important

fast, readable, no freezes.

Approach

dig, collect, build a solution.”

And then I was given a very simple concept - not about implementation, but about the idea: there are several sources, each one has its area of influence, and all of this needs to be visualized clearly on the grid.

At that point it looked like: “Okay, we just highlight some tiles.”

But very quickly it became clear: we’re not drawing squares - we’re visualizing math, and math can be heavy.

Digging: What Happens When the Grid Gets Big?

The first real question I asked myself was: what happens when this is no longer 500 cells, but tens or hundreds of thousands?

Because in the game, the player will not wait. They move the cursor - they expect feedback instantly.

So from the start, I introduced a hard rule:

Heavy calculations should be moved off the game thread whenever possible. The main thread should only assemble the final visual result and apply controlled updates.

That decision shaped everything that came after.

Iteration 1: Chunk Structure Was Born

I started with the foundation: how do we store and update data without scanning the entire world every time?

That’s where the chunk structure came in. Essentially, it’s a container system that allows working locally - only updating and recalculating what is actually needed.

At first it was created just for highlighting, but very quickly it became obvious: this is a universal structure that future gameplay systems can also build upon.

What this gave us:

• Local processing (no full-map scans)

• A clear path to scalability

• A base for caching and controlled updates

Iteration 2: First “Wow Visualization” and First “Uh-Oh”

Next, I built what everyone wanted to see: the first real highlight visualization in the actual game scene.

And this is where the interesting part started - because something that works in a controlled test can start breaking down in real gameplay scenarios:

• Artifacts on zone borders

• Issues when moving the cursor quickly or switching modes

• Difficulty adding new highlight types without breaking existing ones

• And most importantly performance when many cells are active at once

So yes, it looked cool… but I knew: if we leave it like this, the first serious feature will completely destroy this system.

Iteration 3: Clean Up and Survive

The third iteration was about survival of the system:

• Fixes

• Stabilization

• Removing things that blocked further development

• Making sure typical cases no longer broke the system

But that still wasn’t enough. Because the problem wasn’t a single bug. The problem was that the system needed real architecture, not just patches.

Iteration 4: Turning Highlight into a Platform

In the fourth iteration, I stopped building “a highlight system” and started building a platform for highlights.

Several key principles became the foundation:

• Separation of concerns Calculations, data preparation, and rendering must not be tangled together.

• Thread-aware design It must be clear what can run in background threads and what must stay on the game thread.

• Safe background processing Background tasks must not break frame stability or cause data races.

• Editor-friendly setup New modes and rules should be added without rewriting half the system.

After this stage, I finally had the feeling: "Now this can actually be extended. Adding new rules, modes, and metrics is no longer scary."

What Gave the Biggest Performance Boost

After the architectural changes, the system stopped causing frame drops when the player expects instant feedback.

The biggest contributors were:

• Incremental updates (work is split into small steps instead of “everything in one frame”)

• Caching of already calculated metrics

• Parallel processing where it is safe

• Highlight update budget (how much can be updated per tick without stalling the frame)

• Culling (we only calculate and render what the player actually sees and needs right now)

In the end, we achieved what the original task required:

A system that is:

• Clear to read

• Fast to update

• Scalable

• Capable of processing extremely large data volumes (up to millions of cells in some internal scenarios)

• Without the player feeling any delays or stutters

And this system will now serve as the foundation for many future gameplay mechanics in Age After Age.

As you can see we are experimenting with the dev blog, in this particular we provided a though process which was taken to create the grid highlight system. Hope you like it, we will continue to experiment on dev blog content. And see you guys in two weeks!