What Is a Live Service Game? (and What It Needs to Stay Live)

A plain definition, the systems that keep a live game online, and where a game backend and LiveOps fit.

What is a live service game?

A live service game is a title you ship once, then keep running for years on a steady stream of new content and events.

Players keep spending, so the game keeps earning. The industry also calls this games as a service, or GaaS, because the game works like software as a service. You publish it, then you operate it.

Here is the short live service game definition: a game built to be updated and monetized long after launch, not sold once and left alone.

The model is not new. It grew out of subscription MMOs like RuneScape and World of Warcraft, where a monthly fee funded a constant flow of new content. Big publishers including Electronic Arts, Ubisoft, and Square Enix made games as a service a focus of their plans in 2017. Today it covers the biggest titles across mobile, PC, and console.

The numbers show why studios and publishers chased it. In 2025, mobile games alone pulled in $81.75 billion from in-app purchases, and games from the top 1% of publishers took 92.5% of that spend. Nine mobile titles each cleared a billion dollars that year. These are all live service games. Royal Match, Candy Crush Saga, and Coin Master run on constant updates and events, not one-time sales.

Live service game vs premium boxed game?

The difference is what happens after launch. A boxed game is finished on release. A live service game is only getting started.

What makes a live service game distinct is that it keeps changing, funded by ongoing spend rather than a single sale.

A premium boxed game, sometimes called a buy-to-play or single-player title, sells for a fixed price and works on its own. You own the copy, and it keeps working whether or not the studio sticks around. A live service game trades that permanence for reach. It leans on servers, so if the studio stops running it, the game can go dark. When Ubisoft switched off the servers for The Crew in 2024, the racing game became unplayable, even for players who owned a copy.

That is also the risk. A boxed game is done. A live service game is a running service with real costs and real uptime pressure.

What does a live service game need to stay live?

To stay live, a game needs three systems working together. Miss one and the game stalls, empties out, or falls over.

These are the core live service game requirements. LiveOps covers the content cadence and the seasons calendar. Here is what each one does and why it leans on a game backend.

Live operations (LiveOps)

Game LiveOps is the practice of operating your game as a live service after launch, to drive retention, engagement, and monetization. LiveOps is short for live operations. It is the umbrella for the content cadence, the seasons and live events that give that cadence its shape, and the data work that tunes what players see.

A live service game lives on rhythm. Players return because something new lands next week or next month. Miss the cadence and they drift. The backend has to ship and version that content without taking the game down.

A season or a live event gives the cadence its shape. A season resets progression and hands players a fresh goal. A live event drops a limited-time mode or reward, then ends. Both need scheduling, remote configuration, and a record of where each player is. This is also how you push a change without an app store update, since the rules live on the server, not in the client.

Under that calendar sits the data loop. You capture what players do, group them into audiences, and tune the game for each group. A LiveOps platform for games captures those events and adds experiments, feature flags, and remote configuration on top. Done well, this is how you reduce game churn, because you fix the moments where players quit before they quit.

A metagame (including the player economy)

Beside the LiveOps calendar sits the metagame: the layer of systems around core gameplay that give players a reason to keep going. Progression, rewards, energy, and the player economy all sit in that layer. Soft currency you earn, hard currency you buy, and energy that gates play are economy systems inside the metagame, not a separate pillar. Every balance has to be stored and checked on the server, or a player will find the exploit.

A game backend

Both of those systems sit on a game backend. The backend handles accounts, stores player data, and keeps progress consistent across sessions and devices. For anything competitive, you want an authoritative game server. The server has the final say on game state, so a player cannot fake a score or an item. A multiplayer game backend adds matchmaking, leaderboards, and chat on top. This is the layer that decides whether your live game holds up when a crowd shows up at once.

Retention is the scoreboard for all of this, and it is getting harder. By December 2025, seventh-day retention for the top 25 casual games had fallen to 14.9%, per Sensor Tower data. Keeping players past the first week is the real work of a live game, and it is what player engagement work is for.

How a live service game stays live: the LiveOps loop

Day to day, a LiveOps game runs on a loop. Each beat starts with a plan for the next update, season, or event, then the LiveOps loop takes over. Here is the cycle, with a concrete move at each step.

1. Capture. Log what players do the moment it happens. Example: a match-3 game logs every level attempt, booster use, and purchase during a two-week themed event.
2. Segment. Group players into audiences by that behavior. Example: a casual game builds an audience of players who stalled early and have not spent.
3. Configure. Set a live event, offer, or feature flag for that audience, from the server and without an app store update. Example: a shooter turns on a limited-time mode with a feature flag and no client patch, and the casual game offers its stalled players a starter bundle.
4. Measure. Track whether the change moved the metric that mattered, and run an experiment when you need proof. Example: a puzzle game A/B tests two energy refill rates and watches session length and day-seven retention.
5. Iterate. Keep the winner, roll it wider, and feed what you learned into the next beat. Example: the puzzle game ships the refill rate that lifted session length to every player.

How do you build a live service game? Build vs buy

You have two honest paths. Build the backend and LiveOps yourself, or run them on a managed stack built for games. Most teams land somewhere in between.

Building in-house gives you total control and a standing bill: a small backend team to build it, then that same team on call to keep it up. You own the scaling, the uptime, and the late-night on-call. Buying a managed stack gets you live fast and hands the infrastructure to someone else. The hybrid path is an open-source core you can read and change, plus managed operations. That is why a lot of teams pick open source first.

The provider landscape, by type

If you buy or go hybrid, the options fall into three archetypes.

Where the Heroic stack fits

We built our stack for exactly this problem, and we built it open source first. Here is how the pieces map to the three requirements above.

Nakama, our open-source game backend, handles the foundation. It covers authentication, real-time multiplayer, and matchmaking. Leaderboards, chat, and groups come built in. It serves over a trillion requests a month; Nakama Enterprise adds distributed clustering and high availability for larger deployments. Nakama’s core is open source under Apache 2.0, so you can run that core yourself rather than relying on a black box.

Satori, our LiveOps platform for games, works on its own or paired with Nakama. It captures player events, groups players into audiences, and runs live events, experiments, feature flags and remote configuration, and player messaging from one console. That covers the live operations layer without bolting analytics onto a game server by hand.

Hiro, our game development kit (GDK) for Nakama, adds the metagame systems: economies, energy, progression, and rewards, all set in configuration files. Because Hiro runs on Nakama, the metagame and the backend speak the same language.

Put together, that is a live service game backend plus LiveOps plus metagame as one stack. You take the pieces you need. Nothing is a black box, and your data stays yours.

Proof it holds at the top end: Remedy launched their co-op shooter FBC: Firebreak on the full Heroic game stack, with Nakama matchmaking, Hiro, and Satori LiveOps. Over a million developers build on our stack. Games on the platform generate over five billion dollars in annual games revenue, and the platform has been performance tested to two million concurrent users.

When a live game scales, the operations get real. For larger studios, publishers, and enterprise teams, our Heroic Cloud is the fully managed path. It runs dedicated Nakama and Satori clusters that expand within seconds with no downtime. You get multiple regions on AWS and GCP, SOC 2 Type II certification, and a private cloud option. That gives you an enterprise game backend without rewriting your stack.

The takeaway

A live service game is a promise to keep showing up for your players. The backend, the LiveOps, and the metagame are how you keep that promise. If you want it as one stack you control, start with our open-source Nakama and add Satori and Hiro when you are ready.