Scaling Live Service Games: Pillar One - Scaling Players

Planning for Global Scale From the Outset of Your Game Project

Part One of the Scaling Live Service Games series introduced the core concept of 'Scaling Live Service Games' and how your game's features and functionalities need to evolve as your game grows. Each of these functionalities share certain characteristics and can be grouped into four distinct pillars:

1. The number of players playing your game
2. Your game's complexity
3. The size of your development and support teams
4. Your game's revenue

We call these The Four Pillars of Scaling, which are the fundamentals that will change as our game grows.

Over the course of this Scaling Live Service Games series we'll deep dive into exactly how each of them will change, and how they bring with them positive problems we need to plan for dealing with ahead of time.

In this part we'll cover how the number of players playing your game will change your game dynamics, and more importantly how you should be planning ahead in order to cope with these changes.

The First Pillar of Scaling: Managing a Growing Player Base

At the risk of stating the obvious, as your game grows, the number of people playing your game will increase.

Like all of our Pillars of Scaling, this is a positive problem - but nevertheless, it's something that will bring changes we need to plan for. Here are some ways we can do that effectively:

Why a Scalable Backend Is Non-Negotiable

To achieve growth, your backend must be able to handle large numbers of concurrent players at a reasonable cost.

Some systems aren't designed for this. We've all seen launches that crash and burn - games that spike to huge concurrents on global release, before promptly failing and soon after that, completely disappearing.

How can you prevent this from happening ahead of time? For starters, you're going to need someone who knows what they're doing on the tech and software side. Once you've got that box ticked, you'll need to give them the right tools to ensure they can scale properly.

That means fit-for-purpose architecture that's actually designed for scale. Metaplay's actor-based model combines authoritative game servers and periodic data persistence, which makes it suitable for handling games at large scale.

An ode to load testing

To add to that, you need to be able to simulate your game under heavy loads if you want to avoid the 'we just launched our game and now everything's broken' situation we were just talking about.

One way to do that is with load testing.

Building load systems from scratch is hard, and like many things we're discussing here, not a priority in the context of making games that sell.

Where you can, implement ready-made load testing features that allow you to rigorously test heavy loads in advance. Features like Metaplay's Bot Client allow you to test millions of concurrents, while Metaplay's robust C# game server is also battle-tested to hundreds of millions of players.

Ensuring robustness and reliability

When you've got lots of players playing your game, they'll trigger all kinds of edge cases and errors that you didn't even think were possible.

It goes without saying, then, that your backend should deal with this without waking up your team at unwelcoming hours of the morning.

Building a system that's founded on self-healing architecture would be one way to go about this.

Let's take a practical use case from one of the games running Metaplay.

Playsome, developers of Friends and Dragons, have been fortunate enough to not have had any production incidents to report, but they have experienced the self-healing powers of Metaplay's architecture in staging by simulating scenarios as extreme as server hardware completely dying, and yet their infrastructure and game has still recovered quickly.

In the event a production problem does sneak through (as inevitably at some point it will), you'll need to have plans in place to limit their blast radius.

Building observability and automated alerts into your tech stack is the first step to going about this.

Like many things on this list, these take time to build yourself, but there are ready-made observability solutions like Grafana that take the pain away from this for you.

Metaplay comes with built-in observability tooling like Grafana, and better still, it's configured as PaaS and IaaS components rather than SaaS, saving our customers a great deal of implementation and running costs.

Building Cheat Prevention Into Your Architecture

Perhaps the least-welcome problem of achieving scale is that as your game grows, it becomes a prized target for cheaters. And there are all-kinds of cheaters - from the casual fast-forward trick that we all remember from popular games in the past, to the more serious hackers who dedicate their time to making cheat tools for a wider audience, and publishing them on forums like iOSgods.com.

Dealing with cheaters once they're already prevalent in your game is a nightmare (trust me on this one, I've been in these shoes before).

From painstakingly investigating player event streams on a case-by-case basis and then determining whether to manually issue them a ban or not, to migrating entire matchmaking servers years after a live game was shipped, catching up with this problem once it's already manifested itself is something that's really not advisable. I can't stress that enough.

Of course, the best cure for a problem is to make sure it never arises in the first place. Building your game on server-authoritative architecture that's cheat-proof by default is one way to do exactly that.

And that's what we've done at Metaplay. We write the game logic in C# and it's then pushed to the server and client simultaneously.

This gives instant server validation and results in a game that's cheat-proof by default, at absolutely no extra effort.

Customer Support Systems for Growing Games

Customer support is another less-fun side effect of running a game that's played by millions of players.

Especially if you're working with a core or mid-core game that targets high-LTV players - in that case, retention becomes even more important than user acquisition.

You don't want to put yourself into a position where players are churning because they're not getting replies to support tickets, or cases are taking too long to solve. And of course, you don't want to bog your team down in handling these tickets, or putting the support systems in place that will be needed to handle them.

That means you'll need a suite of customer support tooling. And lo, you have found yourself another entirely new function to build, and another new department to run. It's a department that's far-removed skills-wise from your existing ones, too, which is another challenge in itself.

As well as offering comprehensive functionality that covers lots of potential support cases, a customer support toolkit needs to be well-designed and easily accessible by non-technical team members.

Ideally, it also needs to have varying access and permission levels. Once you grow to a certain point it makes strategic sense to adopt a hub-and-spoke approach to offering player support - i.e. retaining one or two in-house experts who then set direction, and liaise with external partners from all over the world who then go on to do the actual ticket management and replies.

As you build that team and those capabilities to offer support in-house and externally, you'll need to be sure that your customer support agents are actually doing their job properly. That means you'll need audit logs to sniff out any rogue agent activity (free gems, anyone?), and analytics events to monitor how they're going about handling their tickets.

Of course, building all of this yourself takes time and detracts from what you were supposed to be doing in the first place: making great games.

Wrapping Up: Key Takeaways for Handling Player Growth

You should now have a good idea of how to effectively deal with a growing player-base and all the changes it brings to your game.

For tips and tricks on how to handle the complexity of your growing game join us for Part Three of the 'Scaling Live Service Games' series.

We'll take a closer look at how to plan ahead for social and online capabilities and how to manage customizable game data and economy pipelines.

Scaling Live Service Games FAQ

What is the First Pillar of Scaling in mobile game development?

The First Pillar of Scaling addresses the growing number of players playing your game. As player counts increase, you need scalable backend architecture, load testing capabilities, robust self-healing systems, cheat prevention, and customer support tooling to handle the challenges that come with growth.

Why is load testing important for mobile game launches?

Load testing lets you simulate your game under heavy concurrent player loads before launch, preventing the all-too-common scenario of games crashing on release day. Tools like Metaplay's Bot Client allow you to test millions of concurrents, ensuring your infrastructure can handle real-world player volumes.

How does server-authoritative architecture prevent cheating?

Server-authoritative architecture writes game logic that runs on both server and client simultaneously. This means the server validates every action, making it impossible for players to manipulate client-side data to cheat. It provides cheat-proof gameplay by default, without requiring separate anti-cheat systems.

What should a game studio's customer support system include?

A comprehensive customer support system needs accessible interfaces for non-technical staff, varying permission levels for hub-and-spoke team structures, audit logs to monitor agent activity, analytics for ticket handling performance, and tools that cover a wide range of potential support cases without requiring deep technical expertise.