This article is a bit more technical. If you want to learn about the gameplay, features, and mechanics instead, go ahead and try the demo!
The concept
From the very beginning, the goal was to create a simulation capable of handling large numbers of both player controlled units and enemies on a global scale.
The key to achieving this is separating unit rendering from the simulation itself. The simulation runs in the background in discrete time steps, while only the units currently visible on screen are rendered, ideally at 60 FPS.
How does the simulation work?
So, you don't want to limit the number of units in your game. How do you keep everything running smoothly?
The most computationally expensive task is pathfinding. Workers go about their daily routines autonomously, constantly searching for paths. Then you launch a large scale invasion and suddenly issue movement orders to hundreds of units at once.
The key concept here is a dynamic simulation step time. The simulation runs in discrete time chunks. At the start of the game, when there are only a handful of units, it updates three times per second. As the number of units grows, the time between simulation steps increases.
If all pathfinding tasks cannot be completed within the allotted time, the remaining tasks are postponed until the next simulation step. If this happens repeatedly, it indicates that the simulation has reached its performance limit, and the step time is increased slightly. Conversely, if the simulation consistently finishes well ahead of schedule, the step time can be reduced.
But what about responsiveness?
What happens if the simulation step grows to a couple of seconds? Do you have to wait that long before your units start moving in the middle of a battle?
No. Direct player commands have the highest priority and are executed as soon as possible. Of course, every simulation has its limits, and the maximum scale ultimately depends on your hardware.
And the enemy horde?
Enemies are simulated differently. The individual enemy units swarming across the screen are merely a visual representation of a unit count stored for each tile.
Their movement behaves more like a fluid simulation than traditional unit based pathfinding.
Navigating the Globe
Creating a world scale map introduces big challenge: pathfinding.
The map consists of 8,192 × 4,096 tiles, over 33 million tiles in total. You also want players to be able to send units from one side of the world to the other. Since the game includes naval units, pathfinding has to work seamlessly across land, sea, and rivers.
A traditional approach that searches every adjacent tile would consume far too much CPU time and memory.
The solution is hierarchical pathfinding. The entire map is covered by a grid of nodes further apart connected by precomputed navigation data.
When searching for a short path for example, within the area covered by a few screens, the game performs a direct search on the map tiles. For long distance travel across a continent, it instead searches the higher level node network.
A good real world analogy is planning a route within your city versus planning one across an entire state or country. When navigating locally, you only need a detailed street map. But if your destination is in another city, you first use a highway map to plan the overall route, deciding which cities you'll pass through. Once you reach each destination along the way, you switch back to the detailed local street map to connect the highways to your final destination.