The Tech Behind Swarm

This time last year, alien Primordians had invaded Final City. The Anima Squad was the only hope to fend them off. Players around the world sent trains flying, bullets in circles, and mines all over the map as they took down wave after wave in Swarm. 

When Swarm debuted, it was a different game mode than anything we’d done in the past. The bullet-heaven style mode required WASD movement, a toggle between manual and auto aim, and new abilities. Behind the scenes, it also required our engineers to solve a variety of technical problems that weren’t quite as player facing. 

That’s what we’re here to talk about today. If you’re new to the Riot Games Tech Blog, this is where we turn the keys over to the engineers behind the game to talk about their work and some of the problems they solved over the course of a project. 

We go pretty deep into the tech here, so these articles are geared for fellow engineers, students interested in pursuing a career in tech fields, or players who are particularly interested in the challenges many Rioters work on that aren’t as visible in the day-to-day of the game. 

We’ve got a triple feature for you all today. To start, Nancy “Riot Nancyyy” Iskander, the Tech Lead on Swarm, will take you through the challenges of making Swarm feel like an actual swarm with hundreds of minions on the map at once.

Next, Andrew “Riot H28 G EVO” Hilvers, the Senior Engineering Manager on Modes, will dive into the impact on the servers with a look at how modes impact server usage, the difference between PvP and PvE, and how the team worked to keep Swarm running smoothly.

And finally, Taylor “Riot Regex” Young, a Software Engineer on Swarm, will walk you through Swarm’s progression system and how parts from other systems were used to model the roguelike system’s challenges, scaling, and unique gameplay mechanics. 

Making Swarm a Swarm

Hi everyone, I’m Riot Nancyyy, the Tech Lead on Swarm. In this article, I’ll be sharing some behind-the-scenes work by the Swarm engineering team, with a focus on in-game optimization.

League of Legends is a server-authoritative multiplayer game, hosted on dedicated servers, a paradigm that doesn’t lend itself very well to a bullet-heaven mode like Swarm. The engineering challenge was twofold: first, drastically increase the number of minions that could be active at once in comparison to other modes, and second, reduce the server cost to offset the lower player count.

Our approach was simple: spawn hundreds of minions, identify the biggest performance bottleneck, optimize, rinse and repeat!

Swarm Minions

Our first consideration was how we would implement complex optimizations in the same codebase that’s driving live game modes like Summoner’s Rift, TFT, ARAM, and other rotating game modes, without handicapping ourselves with extensive regression testing at every step.

All League modes heavily employ the minion class—lane and jungle minions, TFT units, pets, objects like Teemo shrooms, and even some AoE effects all have the same internal representation. That’s why even subtle changes to this class could have unintended ripple effects across all modes.

The trade-off we were considering with the choice of Swarm minion representation was whether we wanted to stick to the minion object with all of its features and added baggage, or to start anew with a lightweight object that we could more easily optimize. Given our development timeline, we needed to unblock design iteration on the mode as soon as possible, so we went with a compromise, where we added a new leaf to the object hierarchy as a sibling to the Minion object. The parent class gave us enough features to unblock iteration, while allowing us to optimize several features independently of live modes.

So, what are the practical differences between League and Swarm minions? Swarm minions don’t allocate any resources to classic League features like lanes, jungle camps, or vision. They also replicate less data to the client and do so more selectively. The biggest difference is how Champions interact with them, but more on that later!

Pathfinding & Movement

With the switch to lighter-weight minions, we could spawn hundreds of attackable, visible, animated minions while maintaining good server and client performance—at least, until those minions started moving.

Our early tests revealed a significant challenge: pathfinding was scaling almost quadratically with the number of minions. League of Legends uses A* pathfinding, which remains the gold standard for general-purpose pathfinding in gaming. However, it is not a one-size-fits-all solution—especially when swarms of minions are involved. For those unfamiliar, A* is an agent-based algorithm where we find a path from a specific source to a specific target, where paths that have the shortest lengths are explored first. Along each path explored, collisions are checked with other minions. Therefore, we have to find a path for each individual minion, and each minion’s pathfinding is made more complex the more minions there are to collide with, hence the worse-than-linear scaling.

Aside from performance, we encountered issues like overlap and clumping, which not only reduced visual clarity but also increased overdraw, which negatively impacted client performance. On top of that, we saw scattered movement in certain areas where minions failed to realize their paths were blocked, causing even more chaos.

With the time frame we had to develop Swarm, completely overhauling pathfinding wasn’t exactly something we were eager to do. We tried tweaking existing parameters—reducing collision radii, lowering pathfinding accuracy, and capping path complexity so minions would “give up” sooner. While these adjustments did improve performance, it quickly became clear that we were hitting diminishing returns. Performance improvements came at the cost of responsiveness and accuracy. Worse yet, this left us with no breathing room for any additional server-heavy features—which, in retrospect, we absolutely needed.

Global Pathfinding

The solution was to replace agent-based pathfinding with global pathfinding. Global pathfinding is an approach where a single pathfinding computation determines the optimal routes for multiple units across a shared environment, towards common goal positions. As you might expect, there’s a threshold number of minions after which the global computation becomes more cost-effective, and that was exactly the case for Swarm.

Swarm’s global pathfinding algorithm is a version of Dijkstra’s maps (or Flowfield pathfinding) customized to fit our needs. The algorithm starts by assigning a cost of zero to each target location (i.e. Champions) and then propagates costs outward, incrementing the cost with each step. When minions need to move, they simply follow the path of decreasing costs. Minions apply a collision “stamp” as they move, depending on their size, modifying the flow around them.