Building the Swarm, a Numbers Game

When the engineering team first sat down to discuss The Last Defender, there were 2 immediate challenges.

- A roguelike AI that can adapt

- Having a performant game with hundreds of enemies on the screen at once

Whenever developing software, it's important to isolate the real challenges early on and set about de-risking those by producing proof of concepts and tech demos.

You can find the AI challenge and solution explained in another post.

In these tech blogs, we aim to explain things without too much use of technical jargon, to give you an insight into the problem solving and key features of the game. Creating a swarm justifies a post in itself.

As you may now be aware, we've been focussing on a genre mash-up of Survival, Defence and Strategy. The Survival part of the equation pitches our protagonist in a third person perspective yet the Defence and Strategy parts typically lean towards massive amounts of units. If you've ever played the Total War games, you'll notice the size of armies and therefore a lot of units on screen at once.

The challenge of our player perspective is that you'll be 'up close and personal' with the enemy, so the fidelity of combat, their animations and general style will need to be of a quality that works and fits in with our overall game vision.

Attack of the Polygons

When a game is running, both the GPU and CPU are working hard doing various things to process it. This is why the GPU often sounds like a plane taking off and your room gets some added heat! The GPU is typically processing the visuals and the CPU all the game logic underneath.

We use Unreal engine as the driving force behind our game but (up until recently) it was always better suited for FPS games with fewer units on screen. Processing mass AI or 1000s of moving enemy wasn't in its wheelhouse. For this reason we needed to dig deep and find an architecture that allows efficient and parrallel processing (since nearly every game playing machine has multiple CPU cores nowadays) of many units at once.

We opted to use an architecture that adopts a data-orientated approach (ok, a bit technical) but essentially rather than having each unit process itself on a timer, we process all units in one timer. The efficiency of this architecture was quickly proved out in our tech demos.

Our first experiments were without animation or graphics because we wanted to isolate just the CPU. We wanted to prove out movement, AI and volume of units from this perspective first.

Not only did our demos prove we can move hundreds of units but also that they could act with intelligence - e.g. head towards a target, be killed, attack etc.

The turn of the GPU

Once we've isolated and proved out the CPU can handle movement, AI and general game play logic, it was time to test out the GPU.

Using test animations and early concept models, we could determine how far we can push the limits of rendering. This testbed allowed us to try different animation optimisation techniques to get performace we needed.

It doesn't stop there

We proved that we can create a swarm and for it to be performant but as you may know with games, they go out into a world with countless PC configurations. We can't design for every possible PC but we can use techniques we call 'graceful scaling'. This is where we try to make sure that the experience and difficulty is the same across multiple platforms but provide optimisation scaling so players can adjust their settings to suit performance.

As you can now see, it was extremely important for us to prove out these core game concepts and build the remaining game around the performance budget (computing resource) left over. This method of prioritisation puts performance and optimisation of swarms at the core of the gaming experience which we believe suits this genre mash-up.