Building Free-to-Play Mobile Games for Scale: Part Three - Foundations for operating a growing live game

The second Pillar of Scaling: Operating a growing live game

Before we dive into how the complexity of your game evolves as your game grows, and how you can best operate a growing live game to effectively anticipate that, let’s quickly refresh ourselves with we’re at so far in this Building for Scale Metaplay Miniseries. 

In Building for Scale - Part One: An Introduction we outlined the lay of the land and shed some high-level light on the four fundamental things that change as your game grows: 

• The number of players playing your game 

• The complexity of your game

• The size of your team

• Your game and company revenue 

We called these the Pillars of Scaling. We posited the theory that in spite of the fact that it’s fundamantally a good thing that each of these pillars evolve, as game developers we need to plan for their changing - otherwise we run the risk of getting caught out, chasing our tail, losing our playerbase, and failing to capitalize on the chances that lie in front of us to grow our games in the market. 

With that said, in Building for Scale - Part Two: Handling the increasing number of players playing your game we set out some basic requirements you need to have in place to ensure that as your game starts attracting increasing amounts of players, you’ll have more than you need to sustain and support them. 

We discussed four key areas developers need to have in mind from the moment they start building in anticipation for handling this growing player base: 

• Building on a scalable backend optimized for heavy loads with architecture that’s designed for handling large amounts of players 

• Using a robust and reliable backend that will easily sustain unprecedented spikes in CCU, DAU and other causes of intense memory and database consumption 

• Having an in-built cheat-prevention system that will prevent your game from being used maliciously as it grows (spoiler: Metaplay’s built-in cheat-proof shared game-server logic is a great way to implement this without having to build such a system yourself)

• Having effective customer support tooling that will allow non-technical staff to handle complex support tickets from a large and growing playerbase

How to effectively handle your game's increasing complexity

In Building for Scale - Part Three: Foundations for operating a growing live game we expand on our previous discussions with the hypothesis that as the number of players playing your game grows, you can expect the complexity of your game to grow with it. 

What exactly do we mean by that?

As you have more players coming in, you need to find more ways to deliver them fresh, innovative gameplay experiences in a way that’s efficient as well as effective. 

You need development foundations and processes that will not just ensure your survival in the fast-moving world of mobile games, but rather, allow you to thrive. 

Let’s take a look at some of the considerations that will help us achieve that in a bit more detail: 

The need to build new features, fast

When your game gets traction, you need to be in a place where you don’t need to refactor your entire codebase in order to add more features and content for your players. 

And ideally, you want to be in a position where you can do this fuss-free for 10+ years. 

That means you need to build on a platform that’s truly extensible and fully programmable. 

The vast majority of third-party backend tech and tools that exist are exactly the opposite of this: black boxes that allow you to pick and choose certain features and implement them into your own projects.

And getting started with these tools is fast and easy. But beyond that, customization possibilities are limited.

That means as soon as your game starts growing and you want to add custom features, or modify existing ones, then you quite literally hit a brick wall. 

The challenge of building your own custom backend

At the same time, choosing to build your own custom backend from scratch poses similar problems. You build the tech you need to support a particular feature, then as soon as you want to evolve that feature, you find yourself limited by the tech choices you made earlier. 

Choosing to build on a fully-programmable backend platform like Metaplay is the only way to guarantee that as your game scales and you need to add more complex features, you have the tech you need to facilitate that.

Metaplay ships as source code and can even be deployed into your own cloud. By it’s very nature, then, it’s anti-black box - and allows you to easily extend and customize an increasingly complex featureset. 

Metaplay also includes all the features you need to build and scale a top-grossing game out of the box, meaning you won’t have to waste precious development time building functionalities like IAP validation, push notifications, social logins, guilds, and leagues - all of which you’ll need if you’re serious about scaling. 

The need to provide social and online capabilities

It goes without saying that all top tier games rely on social and multiplayer features to boost engagement and retention. 

Features like guilds, competitions, leagues, and tournaments are essential make-up of a top-grossing game, and should incorporate both cooperative and competitive angles, against one another (PvP) and against the game (PvE).

For most game developers, building social and multiplayer features is a challenge that only increases in difficulty as a game grows and becomes more complex. 

the challenge of building social and online features

Oftentimes, studios will have a team of gameplay programmers employed to work on the game on the one side, and a team of server engineers to work on the underlying architecture on the other. 

Breaking the building of new features into two distinct teams then not only becomes a product challenge, but a communication and company culture challenge, too. 

A studio needs to build an environment that naturally facilitates communication between gameplay programmers and server engineers - which is no mean feat. 

Game companies tend to solve this by sticking a producer in between and hoping for the best, further bloating their team and adding more lines of responsibility, communication, and reporting. There's a reasonable argument that that shouldn’t be the way. 

An alternative would be to build game development infrastructure that allows you to code server logic and write multiplayer features directly on the client, without having to duplicate your game logic across both client and server produced by two different teams. 

Metaplay’s shared client-server logic does exactly that, and allows Unity developers to seamlessly create new social gameplay. 

The need for a comprehensive suite of LiveOps tooling

Throughout this Building for Scale Miniseries we’ll be talking a lot about the need for a thorough, extensible LiveOps toolkit. 

Every game with top-grossing aspirations knows they’ll need LiveOps tools - but most won’t know exactly what they’ll need them to do until their game is well into global launch, and the team is actually running the game as a service - with a complex metalayer and all of the challenges that brings with it. 

Modern games are live services that provide a steady stream of new content to stay engaged. More content also serves as a valuable retention and monetization tool. 

WHY YOU NEED NOT JUST A LIVEOPS TOOLKIT, BUT A FULL CMS

In practice, that means that as well as the game itself, studios need to build increasingly complicated content management systems (CMS). 

These systems should let game developers, game designers, and even less-technical product managers work on their live game effectively, from making and scheduling new in-game events to building and iterating on new offers. 

The CMS should be built on a web of data-driven game configs that allow for quickly modifying and optimizing the gameplay experience, and shipping updates over-the-air. 

Even better, still, if that game config system has version control, rollback capabilities, and the ability to view what’s changed and who’s changed it from one config to the next. 

What’s more, your game config system should allow for deep segmentation based on different player behavior. It goes without saying that you won’t know how your players are going to behave until you’ve launched the game and have a fair amount of people playing it, so your game configs need to handle the ability to constantly build and iterate on new segments, as well as A/B test them against one another, and even A/B test different content delivered to the same segments. 

When LiveOps is the bread-and-butter mobile games today, it’s crucial that developers get this tooling right. Building them from scratch is of course no mean feat, so studios should look for robust LiveOps tooling providers like Metaplay to build this for them, and allow developers to focus on what they do best - make great games. 

The need for customizable game data and economy pipelines

This is almost an extension of the above, such is the state of mobile games today and the fact that customizable game data and economy pipelines are so deeply embedded in modern LiveOps tooling. 

But to expand strictly on the data management side a little more, rather than the more player-facing LiveOps side - as your game grows in complexity, the size of your team grows too (more about that in Part Four). This makes managing the game design and economy data hard - and there are no off-the-shelf tools for managing this it a large scale. 

That means you need tools for building data-driven and live-updateable games that leverage existing editors like Google Sheets in a way that gives you complete build and update control, almost as if you were shipping a full App Store update. 

Tools like Metaplay’s Game Config kit contains diff tooling for reviewing and validating changes before publishing a new config, which is invaluable when working on a game that’s being played by millions of players per day.

In conclusion: How to effectively handle the growing complexity of your game

Bringing Building for Scale - Part Three: How to operate a growing live game we’ve discussed in detail four core needs that evolve as your game grows in size, and accordingly increases in complexity. 

They comprise the second Pillar of Scaling: The increasing complexity of your game and together they are: 

• The need to build new features, fast 

• The need to provide social and multiplayer features 

• The need for a comprehensive LiveOps toolkit

• The need for customizable game data and economy pipelines 

In short, as games grow, their complexity increases, which brings with it the need for strategic planning and the planning of scalable solutions in advance. 

In particular, we’ve highlighted the importance of building new features rapidly, incorporating online and social capabilities, employing comprehensive LiveOps tooling, and managing customizable game data and economy pipelines to sustain growth. 

Building on the arguments we raised in Building for Scale - Part One and Building for Scale - Part Two we’ve posited that developers can save time and avoid future headaches by considering these problems now.

By choosing to build on an extensible and programmable platform that already includes the comprehensive tooling required for developers to navigate the challenges of scaling, they can ensure games can evolve without compromising on innovation or player engagement. 

This holistic approach to game development allows game creators to focus on what they do best—delivering exceptional gaming experiences.

In the next installment of this Metaplay Miniseries, Building for Scale - Part Four: How to handle the evolving needs of a growing game development team we’ll discuss in-depth some of the implications that scale can have on your people and their workflows, and share some ideas for how to mitigate common problems that surface deep into game development projects way ahead of time.

Be sure to check back over the coming weeks to be the first to read it.