In Part Two of our 'Building for Scale' Miniseries we do a deep dive into how the growing amount of players playing your game affects your game dynamics. Even though this being a positive problem, we will still need to handle the changes it brings to our game by planning for scale from the outset of our game project. The big question remains: How do we do this effectively?
Planning for global scale from the outset of your game project - A recap of Part One
Part One of our Metaplay Miniseries introduced the core concept of 'Building for Scale' 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 Metaplay Miniseries 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.
Pillar 01 - The number of players playing your game
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:
You’ll need to ensure you’re running a scalable backend
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.
You’ll need to have in-built cheat prevention
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 manual 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.
You’ll need to have customer support systems
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 Part Two of our Metaplay Miniseries
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 'Building for Scale' Miniseries.
We'll take a closer look at how to plan ahead for social and online capabilities and how to manage customizable game data & economy pipelines.
Building Free-to-Play Mobile Games for Scale: Part Three - How to handle a growing game complexity will be published week commencing 19th February. Sign up to our newsletter or follow us on Linkedin to be the first to read it.
