14 Years of LiveOps: What Supercell, King, Trailmix, and Turborilla Have Learned

What keeps live service games growing after 5, 10, or 14 years?

Candy Crush has over 20,000 levels. Hay Day just celebrated its 12th anniversary. Mad Skills Motocross has been running for 14 years. These aren't legacy products coasting on nostalgia — they're growing, evolving live service games that continue to hit revenue targets.

How? That's what we set out to explore at PGC London 2026, bringing together the people who actually run these games:

• Maya Hofree, Supercell (Hay Day)
• Zorbey Cantürk, King (Candy Crush)
• Felicity Gracie-Herst, Trailmix (Love & Pies)
• John Wright, Turborilla (Mad Skills Motocross)
• Teemu Haila, Metaplay

Thomas Huxter from Raptor PR moderated. Here's what surfaced.

Why the content treadmill kills retention

The panel kicked off with a warning from John Wright: teams fall into a trap where they keep adding more of the same content because they feel like they have to — not because players respond to it, not because the data supports it. (For more of John's thinking on sustainable LiveOps, see our Game Development Renaissance interview with him.)

One studio in the audience had a counterintuitive success story — they broke through a revenue ceiling by stopping production for months. They killed the roadmap entirely so the team could step back and make better decisions instead of spinning their wheels on content that wasn't moving metrics.

Turborilla took a different approach. After five years of never doing it, they added mini-games in December — bespoke side loops players could engage with one to three times daily, tied to reward systems.

The result: double-digit improvements across session length and engagement metrics.

The lesson: just because you've never done something doesn't mean you can't. And just because you've always done something doesn't mean you should keep doing it.

How to change your game economy without losing players

One of the hardest changes a legacy game can make is fundamentally revamping the core economy. The Love & Pies team at Trailmix did exactly that last year, and Felicity Gracie-Herst walked through how they pulled it off.

The key wasn't having a perfect plan. It was iteration speed and radical transparency:

• They iterated on the economy weekly
• They were completely open with players about what they were trying to achieve
• They worked through player pushback together rather than retreating

The result: improvements to both monetization and engagement — rare for economy changes that typically trade one off against the other.

There's a critical nuance here though, as Zorbey Cantürk from King pointed out: intent matters more than execution. Players are far more forgiving when they see you're trying to make the game better and you fail, compared to when you have the wrong intent and succeed. If players sense you're just trying to extract more money, trust erodes regardless of how well you execute.

Using time-boxed events to test LiveOps changes safely

One pattern came up repeatedly: time-boxed events with their own economies give you permission to try things you'd never risk in the core game.

When players know an event has a start date, an end date, and its own currency that resets — change becomes an expected part of the experience. You get real feedback on new mechanics without the backlash that comes from modifying something permanent.

Turborilla runs new seasons every two months. The revenue pattern is predictable: spike at season launch, then settle until the next one. But within those seasons, they can test almost anything.

Maya Hofree had a useful framing for this: it's a "trust agreement" with players. They come to your game expecting a certain experience. You have trust capital to spend — the question is how you spend it. Time-boxed events let you experiment without drawing down your core trust balance.

Battle passes as engagement tools, not just monetization

Here's a question worth asking: if you don't have a battle pass in your game, why not? Done right, a battle pass is more than a monetization tool — it's an engagement framework that gives players a shorter journey with a clear start and end. (For more on monetization strategies, see John Wright's complete monetisation guide.)

But there's a cautionary tale here too. Turborilla added a third premium tier to their battle pass, thinking the additional value (an exclusive game mode) would drive conversions.

It didn't. The third tier added no meaningful revenue because they'd misread their audience. Most of their players weren't motocross enthusiasts who'd pay premium for deeper features — they were casual players who liked physics games.

The takeaway: know your actual players, not the players you imagine you have.

Why copying features from other games usually fails

It's tempting to see a feature work in one game and copy it wholesale. Zorbey Cantürk challenged this approach head-on.

The Candy Crush team learned this the hard way with their progression system. With over 20,000 levels, new players face a daunting climb. The team thought: let's give players something on the side, a parallel progression that feels more achievable.

It didn't work. What they actually needed was to make the main progression more meaningful — not add friction by splitting attention across multiple tracks.

The only time direct copying works is with standalone mechanics like mini-games. For everything else, you need to understand the player psychology the feature serves, then figure out how that maps to your specific game and player base.

This is a common pattern across the industry: someone attends a conference, reads about leaderboards being the hot new thing, and tries to bolt them onto their game. But the real question isn't "should we add leaderboards?" It's "do our players have long-term competitive goals, and if so, how would we structure that for our game?" (For more on building features that scale, see our comprehensive guide to building for scale.)

The problem with short-term LiveOps metrics

Here's something the industry doesn't discuss enough: the day-1, day-3, day-7 metrics that make a LiveOps change look successful can completely reverse by day-30 or day-60.

Teams celebrate early improvements, move on to the next initiative, and don't notice until much later that they've actually hurt the game. By then, attribution is murky and the damage is done.

This framing from Maya Hofree resonated with the audience: LiveOps done well is about long-term relationships with players. That's all. If you're not measuring and optimizing for long-term retention, you're probably making decisions that feel good now but cost you later.

How LiveOps tooling affects iteration speed

The panel spent significant time on how tooling choices affect a team's ability to iterate on established games. (This echoes Teemu Haila's post on shipping fast without regret — the tools you choose early determine how fast you can move later.)

There's a common regret across studios: teams always wish they'd built more flexibility into features from the start. But building the "spaceship" version of every feature — fully segmentable, tunable from the backend, A/B testable — costs development time studios often can't afford.

The balance is finding tools that provide that flexibility without requiring your team to build everything from scratch.

Trailmix, for example, uses third-party tools for fast daily accelerator events, achieving 20%+ uplift from features that would have taken months to build internally.

For small studios, building LiveOps tech internally rarely makes sense when every developer should be improving the game. That's why John Wright was at PGC — to find providers who solve problems his team isn't equipped to solve themselves.

The right answer is game-specific. Top-tier games often build bespoke solutions because their needs are particular. But for most studios, the quality of existing LiveOps tooling is high enough that building custom solutions is usually a distraction.

How to keep dev teams motivated on legacy games

An audience member asked how to keep developers engaged when they're working on meta adjustments and economy tweaks instead of building new core gameplay. Three different approaches emerged:

Monthly game jams. Turborilla shuts the office, sets a theme, and gives everyone eight hours to build something completely different. The week after a game jam, the team comes back noticeably more energized.

Making impact visible. People want to see their work matter. If you're just telling developers what to do without involving them in the why, they disengage. Make them part of the solution. Help them see their work translate into real player outcomes.

Planning for team transitions. At Supercell, the culture explicitly expects team composition to change as a game moves from creation to live operation. The skills that make someone great at building a game from scratch aren't the same skills needed to optimize it at scale. Acknowledging this and planning for transitions is healthier than pretending one team can do everything forever.

LiveOps drives both retention and acquisition

Someone asked about balancing acquisition versus retention in LiveOps strategy. The panel's consensus: they shouldn't be in tension.

Good LiveOps retains players, brings back lapsed players, and creates moments that drive platform featuring and word-of-mouth. The distinction between "acquisition LiveOps" and "retention LiveOps" is often a false dichotomy.

Think of games as soap operas rather than movies. A movie optimizes for a single viewing experience. A soap opera creates ongoing reasons to come back tomorrow. That reason to return matters equally to new and existing players.

Mature games often see significant reactivation of churned players during major LiveOps moments. That's user acquisition that doesn't show up in your UA dashboard but absolutely matters for growth.

Key takeaways for live service game teams

Running games for 5, 10, or 14 years teaches you things you can't learn any other way. The recurring themes from this panel:

• Player trust is finite. Every LiveOps decision either builds or spends it.
• Short-term metrics can mislead. Track day-30 and day-60 outcomes, not just day-7.
• Flexible tooling pays compound interest. Teams that experiment fastest learn fastest.
• Team morale affects game quality. Burned-out developers don't build features that delight players.
• Don't copy features — understand player psychology. What works elsewhere may not work for your audience.

And finally: just because something has never been done in your game doesn't mean it can't work. Sometimes the breakthrough is trying what you've been assuming was off the table.

If you're running a live service game and want to talk about how Metaplay can help you iterate faster, get in touch or dive into the technical documentation.