In Sand Hawk, you fly a helicopter over a desert war that carries on without you. Soldiers travel from bases to the front, take cover, get wounded and call for help. Ivan Belačić wants the battlefield to feel busy even when the player is somewhere else.

A recent stress test brought 400 soldiers into one fight, followed by an air strike and a nuclear blast. Ivan is building the game to run on modest PCs, so a battle that size meant being careful about what Godot handles at any given moment.

Sand Hawk keeps track of each soldier’s name, squad, wounds and home base. When a squad is near the player, its soldiers appear in the scene and fight normally.

Farther away, the squad still follows its route, but the game doesn’t need to simulate every soldier’s movements or every shot. It works out distant fights with simpler calculations. The video is a tougher test: all 400 soldiers are present and fighting at once.

Those soldiers don’t make decisions every frame. A commander sets broader goals, squads decide how to carry them out, and individual soldiers act on those decisions. They keep moving between checks, but react immediately if they’re hit or a blast goes off nearby.

The map uses a grid for navigation, with separate paths for soldiers and different sizes of vehicle. That stops a truck from choosing a gap only a person could fit through. The game also reuses routes it has already found, recalculating them when something nearby changes, such as a wall being destroyed.

Ivan moved pathfinding, movement and other costly work into C++ through Godot’s GDExtension.

The artwork helps with the scale too. Ivan builds units and scenery as 3D models, then renders them into sprite sheets before the game runs. At runtime, Godot draws those flat sprites rather than the original models.

A native renderer draws thousands of sprites together with a MultiMesh. In Ivan’s 3,000-sprite test, CPU drawing time fell from 6.24 ms to 0.34 ms per frame.

Air strikes use the same damage rules as smaller explosions. When a bomb lands, the game checks nearby cells for targets instead of searching through every soldier on the map. A hit on fuel or ammunition can set off further explosions.

The nuke at the end of the clip is a scripted showcase, not a weapon players can call in the game. To handle its expanding shockwave, Ivan sorts soldiers and plants by distance when it detonates. As the blast spreads, the game moves through those lists and affects whatever it reaches.

In an exported build running on his CPU’s slower cores, the 400-soldier battle went from 25–41 FPS to 102–123 FPS. Checking soldiers’ decisions less often and moving costly work into C++ helped with that crowd. Keeping distant squads as data helps the rest of the war continue beyond the player’s view.

See more from Ivan: