How Supercell Made Brawl Stars Load in 5 Seconds

On older Android devices, Brawl Stars took roughly 35 seconds to load. A typical match runs about 3 minutes. So before you could play a short session, you paid a load tax that was almost a fifth of the game itself.

Supercell developer Damien Mabin put it bluntly: "You can't really play on a toilet break." The load time was long enough to discourage the spontaneous, drop-in play that a mobile game lives on.

The data backed this up. Android players opened the game less often but stayed longer once in, while iOS players, with shorter loads, dipped in and out freely. The load time was shaping when and how often people played, not just how happy they were.

The push came from a Brawl Stars relaunch campaign in Brazil, a market with a large share of older and lower-spec Android phones. Suddenly the slow path was not an edge case, it was the mainstream experience, and performance became a business problem.

When the team dug in, there was no dramatic culprit. As Damien said, there was "no villain in the server room." The loading pipeline had simply grown, over years, into something painfully sequential.

Loading a game means pulling in UI files, textures, sounds, 3D models, and animation data, and those assets have real dependencies. A button needs its texture. A screen needs its sound. A character needs its model, animation, and effects before it can appear.

The old system respected those dependencies by doing almost everything one step at a time: load an asset, wait for it, load the next, wait again. Even assets with nothing to do with each other were queued up nose to tail.

The first job was not optimization. It was dependency mapping: working out what genuinely must load before what, what could run at the same time, and what only looked like a dependency because nobody had questioned the assumption in years.

The fix was to break loading into small discrete tasks, load this sound, this UI file, this texture, this model, and push them into a shared queue. Multiple worker threads then pull tasks off and run them in parallel, held back only by the real asset dependencies.

Damien described the concept as almost boring: "You create tasks, put them in a queue, and then multiple threads pick them up and work through them in parallel." The genuinely hard part was drawing the line correctly, since some assets, like the loading screen before the main menu, legitimately must serialize.

There was a second, quieter bug this exposed. Server messages sometimes arrived before the client assets needed to handle them were ready, which used to crash the game. They added a buffer so incoming messages sit in a queue until the game state is ready to consume them.

On older Android devices, load time dropped from ~35 seconds to ~5-6 seconds. Even newer iOS devices, already fast, went from ~7 seconds to ~2.5 seconds. The whole project, from design through stabilization, crash-fixing, and getting production-ready, took about 4 months.

This was only possible because Supercell owns Titan, its in-house engine, end to end. The team changed the loading system itself instead of bolting a workaround on top of it. As Damien put it, "owning the engine mattered."

Going multi-threaded brought the classic hazard back: race conditions. Thread A waits on resource X while thread B waits on resource Y, and X and Y depend on each other. A circular wait, and now nothing moves.

It showed up two ways. Some were outright crashes. Worse were the silent stalls, where loading simply stopped with no crash and no signal. As Damien said, "It's not a crash, so if you don't pay attention to it, you don't really know what's happening."

To catch the stalls, they added analytics that flag moments where loading progress stopped without a matching crash report. After release there was a spike in crashes, and the Brawl and Titan teams spent the next few days chasing them down. They went in expecting it: "We knew we would have crashes and instability."

Supercell's startup logo animation runs about 2.8 seconds. Once loading fell to 5-6 seconds, the game was sometimes functionally ready before the logo finished playing. The loading screen stopped appearing the way people expected.

So players filed bug reports, convinced something was broken. Nothing was. The game was just faster than the animation designed to cover the wait. The fix was to show the logo only once per day, letting the game otherwise drop straight into the faster flow.

The behavior data followed. Android sessions shifted toward iOS patterns, shorter and more frequent. Damien framed it as handing agency back: "They can play however they want, not how the loading time forces them to play."

Titan runs every Supercell game and serves about 300 million players a month, but it was never designed top-down. It started as game code that teams copy-pasted between titles, later merged into one shared engine. A teammate, Elie, called parts of it "a machine that looks good from the front, while the back is held together with duct tape and a prayer."

Titan's boss Timo Tervola calls the resulting decay a "silent killer": no single crash, no explicit complaint, just gradual performance rot on ordinary devices that no feedback form ever captures. The loading fix is one instance of a team hitting a wall the shared engine created and reaching in to fix the engine itself.

Because the loading system lives in Titan, that fix does not stay with Brawl Stars. Under Game Tech's stated principle, when one team solves a hard problem in the engine, the improvement is there for every other game to reuse. The instability was a deliberate call for this game at this moment, and another team, Damien noted, might weigh it differently.