How Titan Made Brawl Stars Toilet Break-Friendly

On some Android devices, Brawl Stars used to take around 35 seconds to load.

That’s not a lovely number when a typical match lasts about three minutes. Brawl Stars is built around quick sessions, played in small gaps throughout the day. If opening the game takes 35 seconds, those small gaps start to disappear. The game becomes less spontaneous, less frequent, and easier to skip.

As Damien Mabin, a game developer on Brawl Stars, puts it: “You can’t really play on a toilet break.” The data showed that Android players were opening the game less often, then staying longer once they did. On iOS, where load times were shorter, players dipped in and out more freely. The loading time had started deciding when people could play.

Load, wait, load, wait

The trigger to hunt down those extra seconds came from a campaign.

Brawl Stars was relaunched in Brazil, where a lot of players play on older Android devices. Performance and load times mattered. And when the team looked closely, the scale of the issue was obvious.

The game wasn’t slow because of one dramatic failure. There was no villain in the server room. The loading process had just grown over time into something too sequential for what the game needed.

Brawl Stars loads a lot of assets before a player gets into the game. UI files. Textures. Sounds. 3D models. Animation data. Some of those assets depend on each other. A UI file might describe a button, but the texture for that button still needs to load. A screen might have a sound attached to it. A character might need its model, animation, and effects ready before it can appear properly.

The old system handled too much of this one step at a time.

“It was basically load, wait, load, wait,” Damien says. “And that logic was spread around the codebase, a bit like spaghetti”.

The first job was not making the loading screen faster. It was finding out why it was slow in the first place. The team had to map all the dependencies between assets: what needs to load before what, what can happen at the same time, and what only looked dependent because nobody had questioned it for a while.

Enter Titan

This is where Titan starts to matter.

Titan is our internal game engine. It runs every Supercell game, and it includes editor tools used by artists, designers, and developers. Some parts are shared across every game. Some parts are game-specific. It’s not a clean commercial product that was built once and handed to teams. It’s a patchwork grown out of games and features being built, copied, adapted, merged, and reused over the years.

“It started as game code,” says Elie Tattevin-Drevet, a game developer on mo.co. In the early days of Supercell, each game team had its own codebase. As teams literally copied and pasted the same code across games, Supercell started pulling those shared pieces into one internal engine. That shared engine became Titan.”

That history shows up in the engine. Some systems were built quickly for one game, then reused more widely than anyone expected. Some parts are polished. Others carry bugs, old assumptions, or design decisions that made sense at the time but now slow people down.

The upside is access. Because Titan is our own engine, game teams can go into the systems they depend on and change them. In this case, that meant changing the loading system itself instead of building a workaround around it.

But Titan is not only a place game teams can go deep when they need to. There is also a dedicated Titan team making those shared systems stronger, safer, and more useful across Supercell’s games. That matters because work like this should not stay trapped inside one game team. When a team solves a hard problem in Titan, the engine can get better for everyone building on top of it.

Making the game do more than one thing at once

This is how the team was able to make the right changes to the game. To stop it from treating loading like one long line where every asset politely waits its turn.

The team broke the loading process into smaller tasks: load this sound, load this UI file, load this texture, load this model. Instead of running those tasks through one mostly sequential path, Titan could put them into a shared queue and let multiple worker threads process them at the same time, as long as the asset dependencies allowed it.

“Technically, the idea is simple,” Damien says. “You create tasks, put them in a queue, and then multiple threads pick them up and work through them in parallel.”

The hard part was deciding what could safely run in parallel. Some assets still had to wait for others. The loading screen needs certain files before it can appear. The main menu needs others. But a lot of work that had previously happened one step after another could now happen at the same time.

The game also has to connect to the server while all of this is happening. Server messages can arrive before the assets needed to process them are ready. Previously, that could crash the game. So the team built a buffer: messages arrive, sit in a queue, and get processed only when the game is ready for them.

This is where owning the engine mattered. The team did not have to work around the loading system. They could change it.

From 35 to 5

The first results weren’t subtle.

On older Android devices, loading times dropped from around 35 seconds to roughly five or six. On newer iOS devices, they went from around seven seconds to about two and a half.

Success! But this created a new, slightly stupid problem.

The Supercell logo animation at startup lasts around 2.8 seconds. The game was now sometimes ready before the logo had finished.

“The game's loading screen was no longer displayed,” Damien says. “Players felt something was broken and started sending us bug reports.”

The team eventually changed the flow so the Supercell logo appears only once per day. After that, the game opens faster. The best UX feedback, in this case, was mostly silence.

“If something works well, people usually don’t notice,” Damien says.

They did notice the crashes, though.

Not a magic switch

Moving loading into parallel introduced race conditions, a common problem in multi-threaded systems, where different pieces of work can finish in an unexpected order. Sometimes one thread waited for resource A while another waited for resource B, and both depended on the other finishing first.

Those issues showed up in two ways. Sometimes the game crashed. Sometimes loading just stopped progressing, which was worse because it left fewer obvious clues.

“It’s not a crash, so if you don’t pay attention to it, you don’t really know what’s happening,” Damien says.

The team added analytics to detect where loading stalled. They looked for the moments where progress stopped, even when no crash report appeared. After the first release, there was a spike in crashes. The Brawl and Titan teams spent the next few days fixing them.

For players, a crash means the game does not just feel slow. It breaks. For the game team, it means taking a change that was meant to make Brawl Stars easier to open, then making sure it did not create a worse reason for people to leave.

That risk was understood going in. “We knew we would have crashes and instability,” he says.

The Brawl Stars team was willing to take that risk because the upside was clear. Another team might make a different call, depending on what its game needs most at that moment. But for any team wanting to adopt a similar approach, the groundwork now exists.

The loading work took around four months in total: implementation, stabilization, crash fixing, and getting it production-ready.

What changed for players

The obvious result was speed. But the more interesting result was behaviour.

After the loading change, Android behaviour moved closer to iOS behaviour: shorter sessions, more often. The game was no longer asking players to plan around the loading screen.

“They can play however they want,” Damien says. “Not how the loading time forces them to play.”

This is the part that makes the work feel less like an engineering trophy and more like a game team problem. The goal was not to make a chart look nicer, but to make Brawl Stars fit back into the small moments where mobile games live: the commute, the queue, the couch, the suspiciously long bathroom visit.

Building better tools inside Titan

Elie’s work shows the same pattern from another side: not loading times, but the tools people use to build games inside Titan.

He works on tools and systems for artists, designers, and other developers. Some of that work happens close to a specific game team, but the problems are familiar across game development: fragile workflows, shared files that block people, tools that make simple changes slower than they need to be.

One of his first projects was replacing a huge spreadsheet that controlled animation data.

“It was one massive CSV file,” he says. “If you made a typo, you broke everything.”

Artists were using that spreadsheet to manage animation composition. It worked in the technical sense, in the same way a chair with three legs is technically a chair. It was bad for collaboration, easy to break, and not something you’d want to build a workflow around forever.

Elie rebuilt it as a visual editor inside Titan. Artists could drag animations onto a timeline, move them around, add effects, and preview how things would look in-game. The work took him about six months, partly because he had just joined as a junior developer, and partly because building the right tool meant talking to artists again and again.

“You build up the best tool together,” he says. “You hear their ideas, hear their concerns, and come up with the best system.”

Another project did something similar for cosmetics: the skins, outfits, and visual items players can collect or equip. Instead of one big shared spreadsheet, each cosmetic became its own asset file. That meant several artists could work without blocking each other. One artist could test more of their own changes instead of waiting for someone else to update the shared file.

This is the editor side of Titan. Less visible than loading times, but very real to the people making the game.

The honest version

None of this means Titan is pristine.

“A lot of systems weren’t designed to scale,” Elie says. “There are bugs everywhere. It slows the game teams down.”

That is part of working on an engine that has grown with live games over many years. Large game teams can put pressure on asset management, editor workflows, and content pipelines in ways the original systems were not always designed to handle. Some parts of Titan were built quickly for one need, then used more heavily than anyone expected. Some parts are polished. Others are, as Elie puts it, a machine that looks good from the front, while the back is held together with duct tape and a prayer.

Elie does not see this as a reason to avoid working on Titan. Quite the opposite.

“It’s fun to work with a system that’s a bit broken,” he says.

He means it. Solving those problems matters to a very real audience: the artists and designers trying to build better games.

“We’re not building tech for the sake of tech,” Elie says. “You’re building better tech to help artists do their art stuff, or help designers do their designer stuff."

Titan is not there to be admired. It is there to make the work behind the games better.

Help us build what Supercell’s games run on

The loading-time project made Brawl Stars faster. It also showed what working with Titan can mean: deep technical problems, visible player impact, and shared systems that can become stronger for every game team.

You can go deep into the engine. You can change engine systems that might be off-limits in a third-party engine. You can take on a problem that touches millions of players, then spend several days in the crash mines because the first version did not behave. You can build tools that remove a spreadsheet from someone’s life, which is a noble act in any company.

The work is not always clean. But clean is rarely where the interesting problems live.

Titan and the team behind it are growing. The goal is not to make every system perfect overnight, because that is not what happens in software. The goal is to make the engine and tools stronger, less rusty, and more useful for every game team building on top of them.

Sometimes that means cutting 35 seconds off a loading time. Sometimes it means giving an artist a timeline instead of a spreadsheet.

Sometimes it means letting someone open Brawl Stars before their legs go numb.

Explore open roles