Building for Scale: How not to get caught out at global launch

Making mobile games today: A scaling problem

To thrive, and have a chance of growing real market share, you need to have plans in place for how you’ll continue to grow your game after global release.

What will your game’s LiveOps strategy be? How will you keep the game fresh with regular content updates? How can you tap into revenue streams beyond only the App Stores?

Many developers fail to consider these key questions at the outset of their game development projects. The result is that as they progress into the latter stages of development, they're often left ruing their early design and production choices.

But by having scale in mind from a project's outset, developers can save themselves from a world of future production headaches, and ensure they're best placed to design and build games for scale.

What does it mean to 'build for scale'?

Building for scale ensures that not only will you not get caught out at global launch, but you’ll also gain valuable competitive advantages that will help your game achieve real global growth.

Granted, building for scale is easier said than done - but at the same time, it needn’t be that complicated.

Here, we take a look at how a little forward planning can go a remarkably long way, and break down the principles of building for scale so you can make games that achieve global growth. 

Why making games is about more than just 'time to market'.

At the start of a game development journey, nothing's more important than proving the product's concept.

On the quest to find product-market fit, it goes without saying that a key game development priority is to minimize time to market.

But while optimizing for time to market is what’s needed in the early days, it can cause problems later on down the line. Metaplay co-founder Teemu Haila discusses this in his piece Ship Fast Without Regret.

We’re not saying here that time to market’s not important. Far from it.

But during this phase, we’re only focusing on things that will get us over the line in the coming weeks, or at a stretch, in the coming months.

Naturally, that means we’re making tradeoffs that are only serving for now. By extension, then, we’re sacrificing the later.

Let’s start by taking a look at what we need for the proof-of-concept phase of development, and then continue our development journey onwards from there.

What do you need in order to prove your game’s concept?

To find product-market fit in those early proof-of-concept releases, you need to get to data quickly at the lowest cost possible.

In essence, you need to nail down a core gameplay loop that’s robust enough to reach soft launch, and incorporate rudimentary analytics that will allow you to determine whether or not what you’ve built is a success.

You’ll probably also want to feed into this some basic user acquisition activities that will allow you to bring enough players to your game to validate that you have a good idea.

You keep costs down by developing as quickly as possible, probably working mostly in an offline integrated development environment (IDE) to save overhead from working with live servers.

To develop quickly, you need tech and tools you know how to use in order to minimize hassle around getting started with new technologies.

And of course, you need focus and team orientation around the challenge that’s in front of you: building a proof of concept and testing out with real people to find product-market fit. (For more insights on market validation, check out our guest post by Sebastian Long from Player Research on Mastering Player Research and UX Optimization.)

Building for scale: Time to market’s bigger, scarier brother

Great! You’ve done all that. But what now?

Many studios fall into the trap of just carrying on the same path they were already on - the path they set off when they were building their earliest releases.

And that’s where things start to fall apart.

In the proof of concept phase, we’ve more than likely rushed to put out an MVP that's strung together on a flaky backend that’s not designed for scale.

If we go on to ship this MVP using the same technology, there’s no real technical foundation to drive and support our game’s growth as it scales.

And that’s a problem. Because if you want to build a game that truly makes an impact, you’re going to need at least these things: 

What do you need in order to build a game for scale?

It goes without saying that as you build your game, its features and functionalities evolve.

In progressing from pre-launch through to hit game and ultimately top-grossing, you’ll need to add a range of online and social features, plan and execute a complete LiveOps strategy, guarantee stability and security, and more. 

With each step you take on this journey, the tech and tools you’re building your game on will need to evolve too.

Breaking down each of these things at the outset of your development journey is time consuming, and not a priority when you have a concept to prove.

But the good news is that you don’t need to concern yourself with all the details from the get-go.

That said, you do need to know these things exist, and you should be aware that if your game is going to be a success, you will need to build them at some point. 

Planning for scale from the moment you start building

To get to a point where you can seamlessly integrate the features and functionalities we outline above, let’s think in a bit more detail about some of the more significant things that will change as soon as we start scaling.

That’s how we can be sure that things aren’t going to break as we grow.

Revisiting our diagram, each of the above functionalities we highlight share certain characteristics.

Actually, we can group each of them under one of four distinct pillars, or things that change as your game grows: 

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

These are our four Pillars of Scaling. 

Introducing the Pillars of Scaling: Four fundamentals that change as you grow

Like our list of functionalities and features above, the Pillars of Scaling are the fundamentals that will change as our game grows.

Let’s take a look at how they’ll change, how that can become a problem, and some of the things we could do ahead of time to effectively anticipate that problem. 

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. 

Pillar 02 - Operating a growing live game

While 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

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.

Pillar 03 - Handling a growing game team

As the number of players playing your game increases and you increase your game’s complexity by building the things your players need to stay engaged, something else will change: the size of your team.

This could have fundamental changes to the way you work, and developers who don't proceed with caution often find themselves blocked by their tools and tech stack.

Let’s look at some of them:

The need for workflows for multiple feature teams 

What works for 20 people won't work for 120 people: it's an unfortunate consequence of success that try as we might, we can't really avoid. 

Sure, this is a problem that can be addressed later. (And in fact, it should - there's no point spending a great deal of time and headspace on this while you're still in the early stages. It's an iterative thing that your leadership should develop in tandem with your team as you scale.)

But by doing a little bit of early planning, you can save yourself a great many future problems. 

Let's take a practical and obvious example. When your team grows, you'll need to split up into multiple feature teams. That means you'll need orchestration and coordination roles as well as just practitioners. And these people and teams will do their best work when they're collaborating from one central space.

That central space should have capabilities for code branching; running multiple environments with CI/CD; release management and version control (across server, client, and over-the-air updates); and of course, dedicated tooling for different disciplines - including non-technical. 

Outlining what such a space needs is straightforward in theory, but transforming that vision into practice is a multi-year, multi-person project (trust us, we've had a team over twenty people doing it for about five years now!). 

Ideally, it looks something like the Metaplay LiveOps Dashboard, which has homes for developers, product managers, game designers, DevOps engineers and even non-technical support staff to all work out of at the same time. 

For security, transparency, and easy roll-back capabilities, everything should be version-controlled. That gives everyone on the wider game team visibility over who's done what, in the same way that say GitHub does with its code repositories. 

The Metaplay LiveOps Dashboard has various levels of user access rights too - something that will be crucial later on down the line when you start working with external partners for, say, handling player support. 

Planning workflows for multiple people working on the same project within Unity is crucial, as well. On that, the Metaplay SDK comes with out-of-the-box Offline Development Mode for running servers locally, and enabling multiple developers to iterate fast without needing to run commits or merges to online branches. 

Having tech and tools in place like this is obviously useful at the start of your project, but the real value comes as your game starts to scale. 

The need for advanced debug tooling

We touched on the fact that as your game attracts more players, you'll be introduced to a world of problems in your gameplay that you never knew existed. 

Being made aware of such problems is one thing. Solving them is another. 

Most ready-made debug tools out there at the moment are fragmented and hard to use. They're not designed with user experience in mind, and quite often the player model or player save file lives in a different place to say, the player's event history, or customer support ticketing tools. That makes debugging difficult.

When your game scales, if you want to solve problems efficiently - both on the development and production side - you're going to need all of these tools in one place. 

To name but a few tools that you won't even consider at the start, but won't be able to live without later:

• Incident reports for debugging live game logic issues
• The ability to copy player states from production into your own internal development environment
• Ad-hoc tooling for modifying player data on the fly
• Easy import/exporting capabilities (also for GDPR compliance reasons) 
• Server-side analytics events for allowing non-technical (and, well, all) game staff to constantly monitor server health and live game status 

None of these are a priority while you're in soft launch (and probably even after the early stages of global launch) - and nor should they be. 

At the same time, scrambling to build them from scratch deep into a multi-year project, when your focus should be on adding new features, growing LTV, and scaling user acquisition, is not a position you want to find yourself in either. 

The practical way to avoid this is to have in mind from the start that you'll need these tools later on, and build on a tech stack that has them ready whenever need them. 

The need for non-technical team members to be able to manage, or at least access, different parts of your live game

They say a picture paints a thousand words.

Without further ado, then, rather than explain the importance of an easily-accessible and understandable player management centre, allow me to instead drop a few screenshots of the Metaplay LiveOps Dashboard:

Every effort is put into making everything usable by absolutely anybody. Your non-technical staff will know not to get anywhere near those Dangerous Actions unless they fully intend to! 

Needless to say, designing your internal tech in such a way is a huge undertaking - and one that even the largest internal tech teams struggle to undertake. 

Even the more technical pages of the Metaplay LiveOps Dashboard are pretty. (I mean, look...!)

Who doesn't want to spend all day handling player incident reports when your dashboard looks like this?!

The need to extend, customize, and integrate with 3rd party tools

Having the best tech and tooling is meaningless if it lives in a vacuum.

The same is true whether it's tech you've built yourself, or third-party game development software you license from elsewhere.

Whatever you build on, you need to have the capabilities to fully integrate with your tech with other third-party tools.

When you first start building, these needs will be unclear - or if there are any they'll relate to topics immediately applicable to game development - like, say AI coding extensions. 

But as you grow, those needs will evolve.

First, you'll likely broaden your scope third-party game development tools before extending into non-directly development-related tools that are still fed into - or feed off - your core game, like data analytics for your game and marketing, or attribution and conversion tracking for user acquisition. 

Entering maturity, you'll then notice a need to integrate third-party tooling relating to finance, accounting, human resources and more. And that's a good sign! Having the capabilities to bring all of these functions into one place in the same way that, say, something like Notion does, will be a game-changer for your team as you continue to scale.

Your underlying game backend infrastructure will finish up looking something like the below - and ideally, you want as much of this to live out of the same home as possible (otherwise things can get very messy, very fast). 

What's more, everything you build will naturally need to change over time as your game and your team evolves.

That means that when you're using external tools and tech, like a third-party mobile game backend, you need to be sure it's fully extensible and customizable so you can mould it to both your current and future needs. 

The Metaplay SDK ships as source code, so everything you see you can add to, change, or remove as you see fit.

In a world where many third-party backends have been black boxes that are unable to be modified, we never tire of hearing from developers just how much they value that they can really tailor Metaplay to the ever-growing needs of their team and their game. 

Pillar 04 - Managing the side-effects of scaling company revenue

More revenue. It just has a nice ring to it, doesn't it? 

If you're making games, you've probably got to this point by employing an effective monetization strategy in both ads and in-app purchases. 

And once the revenue machine starts rolling, you've likely done a good job at feeding that back into your growth levers to continue the vicious (but in this case, actually very friendly) circle. In the free-to-play games-as-a-live-service world, more revenue tends to mean a better return on ad spend (RoAS), which means you can then be even more competitive in your user acquisition (UA), which in turn brings more players and more revenue with it. And so the cycle goes on. 

It's mostly good news. And of course, as you start making money, the pressure ramps up to keep making even more. And that's the part that's worth planning for ahead of time. 

Mo’ money, mo’ problems (but not necessarily)

I wouldn't usually be one to argue with Biggie, but in this case we might deem his interpretation of financial success to be a little short-sighted. 

More money doesn't have to mean more problems, though indeed it could if we don't ask ourselves a crucial problem at the outset of our project. 

That question is: 'Once I have a successful, revenue-generating game in place, how can I ensure I have the foundations in place to continue to grow it?'

Successful games and businesses are built on deep-rooted and scalable architecture and infrastructure.

Scrambling to build this later on down the line when you're already deep into your project sure is possible, but it's certainly not advisable.

The much better option is to have a robust, customizable, and extensible base you can easily add to and build on as you grow.

That way, when it comes to increasing your successful game's revenue even further by relentlessly optimizing your game, adding new revenue streams, and ring-fencing your brand and IP to guarantee business continuity, you won't need to reinvent the wheel.

You'll already have the structures in place that means you just have to add an extra spoke or two, or maybe, at a push, change a tire. 

Money makes money: Where to focus once you've scaled

To be more specific, as your game's revenue grows a world of different opportunities and activities will open up to you - all with the goal of further scale in mind. 

Your continued success will be based on which of those opportunities you choose, and which cards you play. 

It's at this point that without realizing, some of the early decisions made at the start of a game development project could have serious ramifications on the possibilities open to you now.  

The most successful studios and game developers keep all of their options open for as long as possible by choosing to build on scalable, extensible technology that will help them continue to deliver increased revenue even at significant scale. 

The choices they made at the start of their development project make it easier to optimize their game later, unlock new revenue streams via new channels at game maturity, and they've guaranteed business continuity by protecting their brand and IP at all times.

That means that they've not unintentionally closed the door to continued revenue scaling by unwittingly making bad technological choices, and all of the avenues remain open for them to keep pursuing financial success.

Let's take a look at what they could be in a bit more detail.

Optimizing your game for more revenue

Data-driven LiveOps 

LiveOps is the cornerstone for top-tier mobile games today. Indeed, mobile games can't succeed without a deep and engaging metagame that drives retention and engagement and steadily increases LTV over time. 

The data-driven element of this is crucial, too. Developers intent on delivering more revenue need to be able to ship client-side updates without trawling through a cumbersome build-and-review cycle. Over-the-air update workflows with version control and rollback capabilities, like Metaplay's Game Config toolkit, are a necessity.  

Ads or similar for low LTV cohorts

It's the nature of mobile gaming that the vast majority of your players won't be spenders. 

You need to make sure you're monetizing those in some way - usually via ads. At scale, you don't just want to be serving ads to anyone. Your high-LTV players could be put off, and might be driven away from your game.

But that doesn't mean that you should leave revenue on the table by not targeting your low-LTV cohorts. To do that effectively, you need to build your game's economy on dynamic segmentation and personalization pipelines which will allow you to build bespoke gameplay experiences for whichever cohort you choose. Metaplay's segmentation tools are a handy and time-effective way to do that. 

IAPs and/or subscriptions for high-value/paying players

Similar to above but opposite: with your big spenders, you need to make sure you're leaving no economic stone unturned and capturing any financial surplus they'd be willing to part with to enjoy your game.

Creating segmented buckets, analyzing user behaviour in those buckets, and extrapolating that to other buckets, areas, and monetization avenues is one way to do exactly that. 

Off-app purchases for better revenue share and circumnavigation of high platform fees

Platform fees suck. And they've sucked for a long time. But fortunately we live in an age where we can now do something about it. 

Building your game's shop off the app stores will help you increase your margin and reduce unit costs. At scale, the gains from this will be significant. 

There are still other factors in play such as the platform's treatment of third-party stores, but over time, as scrutiny intensifies and regulation increases, the platforms have to start playing ball and being fair. When they do, developers that have built their shops on third-party stores will win. (If you're in the market for a web store and need a recommendation, then look no further than Appcharge.)

Unlocking new revenue streams to increase revenue potential

Regional and localized versions of your game, perhaps published by external vendors (in say China, India, EMEA) 

Games that show promise in local markets and deliver exceptional revenue for their studios should be spread as far and wide as possible.

Geos like China and the Middle East are tough to crack for lots of reasons (that we won't go into here), but that doesn't mean that the possibility shouldn't be explored for studios looking to truly take their game global. 

When that time comes, partnering up with a local distributor is advisable. This means your tech and infrastructure needs to be in a place that makes it easy for an external party to come and work with your project. Keep that in mind throughout - where possible, the use of homogenized, common tooling rather than custom-made, single-use tech will make this process much more straightforward for both you, and your new external partner. 

At Metaplay, we've helped Dodreams publish their hit game Drive Ahead! in the Middle East via global publication house Sandsoft, and also work closely with China distribution partners Mygamez.

Licensing and merch 

The biggest brands are more than games. Look to strike up licensing and merchandise deals with distributors and vendors who can help bring your brand to life beyond a phone screen. 

Similarly to above, when the time comes to partnering with such providers, make sure you have an extensible platform they can work with in case they'd benefit from first-party access to your game project. Metaplay's permission management model is a good benchmark to follow in that respect. 

GOING CROSS-PLATFORM (WEB, PC, CONSOLE - EVEN WEB3?)

At scale, it makes sense to try and existing audiences (and probably previously untapped audiences, too) in new places. Porting your mobile game to say web could be the logical first step, while bigger brands may even make the decision to go full cross-platform and publish on PC and console too. 

At Metaplay, we helped Playsome publish their game Friends & Dragons on the web via our in-built WebGL compatibility. 

When you start making your game, make sure the tech you're building it on will support multiple distribution channels later on if you seriously want to take it big.

Protecting your product, brand & IP to guarantee long-term business continuity

Source code access to all key tech

Most third-party tech that exists is built in a black-boxed vacuum that a game studio couldn't get its hands on even if it tried its hardest.

At scale, this causes problems. You need to know how the tech you're building on works so that a) you can fix it when it breaks and b) you can extend it with custom features.

Some externally-made tech, like Metaplay, is built with developers in mind. Metaplay ships as source code so studios will never have this problem, and can even be deployed into your own cloud - which brings us nicely onto our next point...

Self-hosting - especially of your game data

Self-hosting is another one of those things that's not critical at the start of a game project. Actually, self-hosting from the outset is more likely to slow you down, rather than speed you up. 

At the start of your game project you just want to build, deploy, test, and improve. There's no need to be protective about where your game's hosted when you don't even have a product.

But that doesn't mean you shouldn't have a plan for how you're going to tackle that later. 

The best course of action is to begin on a managed service plan which allows you to ship quickly and scale fast, like Metaplay's.

Then, when you're ready, migrate your game project to your own cloud for full control of your game and your data. That way you'll be safe in the knowledge that whatever happens to the vendor you're working with, your game will keep on running. 

Fast and efficient incident response processes

At millions of dollars in daily revenue, expect millions of daily problems to have to deal with - especially in areas where you thought problems could never have existed before.

It's impossible to foresee what these problems might be and how they could take shape, so the best course of action is to ensure that you have a thorough incident response process in from the start - whether that's regarding reporting internal problems, external (vendor) problems, or player problems.

Be sure that each party you're working with, whether internally or externally, is aware of those processes too and what the SLAs might be. That way, you'll ensure that at scale, you'll be capable of quickly and efficiently putting out the fires that will inevitably pop up. 

Automated testing pipelines to ensure no fatal bugs in builds slip through the cracks 

This is a big topic with a short answer: All successful games at scale have to pass a thorough end-to-end testing process before being shipped.

Building these tools and pipelines yourself is time-consuming, and frankly, not very fun. (It's much better to be working on actual games.) 

But it's one of those things that if you get wrong, it could have disastrous consequences for your brand and your business. You don't want to be shipping broken builds to players and risk losing them to a competitor. In today's competitive landscape the cost of switching has never been lower, and if a player has cause to jump to another title, then more than likely, they will. 

We've built an extensive automated testing pipeline - complete with testing tools like our proprietary BotClient - which ensures that even at the most global scale, developers making games with Metaplay will never have to worry about something fatal slipping through the cracks.

Mo’ players, mo’ problems

Growing games is great and exactly the thing you were put on this planet to do - but as we’ve seen, it brings with it hella problems. And there’s a lot more things you need to have that we’ve barely been able to touch on here yet. If unprepared, at best you’ll end up bogged down building all this at the crucial time when you’d want to be improving your game instead

How on earth are you going to plan for building the thing that will let you comfortably tackle all of these things? 

Making games the Metaplay way 

From your first line of code through to LiveOps and player support, Metaplay is the only game backend SDK that covers every stage of game development.

The Metaplay SDK brings customizable and fully extensible workflows, libraries, and tooling to professional game developers which were previously only available to high-end studios who had the time, money, and expertise to build it themselves, and can be used to make any kind of Unity game.

Our programmable C# game server comes pre-built with all the necessary features of top-tier games today, and full extensibility makes it easy to add new features and modify existing ones whenever you need to. Metaplay ships as source code, and games can be deployed into our managed cloud for speed and ease-of-use, or self-hosted in a developer’s own cloud for full control of your game and data. Check out our case study with Nitro Games, that leveraged Metaplay’s backend technology to support their latest game, Autogun Heroes, which launched globally in 2023.

Try out the new playable version of the Metaplay LiveOps Dashboard, or, if you're feeling especially fruity, download the Metaplay SDK and take our whole tech stack for a spin. You won't regret it.