Part Four of our 'Building for Scale' Metaplay Miniseries covers the changes that surface once your game team starts growing. As studios scale, teams that thrive need to continuously improve their ways of working. These improvements are exciting, but often not without side-effects. Savvy developers mitigate these and give themselves the best chance of success by planning for the scaling of their team ahead of time, and ensure that when that time comes, their workflows, their game, and the people working on it are properly primed for scale.
Recapping the first and second Pillars of Scale:
Ahead of jumping into the Third Pillar of Scale: How to handle the evolving needs of a growing game development team, let's pause for breath and recap where we're at after our discussions of the first and second Pillars of Scale.
In our introductory piece Building for Scale: Part One we set out the theme of this Metaplay Miniseries: the importance of planning for post-launch growth in mobile game development.
We posited that at the outset of a game's development journey, the focus for developers is typically on finding product-market fit and achieving a successful global launch - and rightly so.
But often, a consequence of such short-term planning is the neglect of a more pressing topic further on down the line: scalability. This neglect can come at a huge cost later on.
To tackle that, we introduced the "Four Pillars of Scale" - a framework for scalability which argues that your game's number of players, game complexity, team size, and revenue - are the four essential factors to manage as a game expands.
The Pillars of Scale don't live in isolation from one another - the growth of each pillar depends on what's gone before it, and in turn, affects what comes after:
Planning for the consequences of the evolution of each of these pillars, both positive and negative, helps developers avoid common pitfalls and incorporate scalability into their initial development plans.
In Part Two, we took a deep dive into the first pillar: How to handle the increasing number of players playing your game.
The key takeaway was that as player numbers increase, developers face challenges that require scalable solutions from the start.
Some of these included a scalable backend, robust game architecture, load test tooling, and tech for dealing with the unfortunate by-products of a growing player-base, like anti-cheat solutions. Planning for effective customer support tooling at this point is also crucial in avoiding unwanted reactionary work deep into your game's project.
Building for Scale Part Three: Foundations for operating a growing live game tackled the topic of game complexity in more detail.
We argued that as games attract more players, their complexity increases, requiring developers to add new features quickly and handle large player bases without overhauling their codebase. Building on an extensible and programmable platform like Metaplay, which allows for customization and scaling, therefore becomes paramount.
To thrive in today's market teams need functionalities for fast feature deployment, seamless integration of social and multiplayer features, comprehensive LiveOps tooling, and customizable game data and economy pipelines. These capabilities are crucial for maintaining player engagement and facilitating game growth without compromising on innovation - and are all topics developers can consider at the start of a project to avoid tripping up on later.
So what does our third Pillar of Scale look like? How can we best prime ourselves for managing the needs of a growing game team as our game scales?
The third Pillar of Scale: 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
In Building for Scale Part Two: How to handle the increasing number of players playing your game 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 third-party tools and tech
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.
Summing up: Solid foundations make for smooth scalability in team size
It's a theme we've been shouting from the rooftops throughout the entirety of our Building for Scale Metaplay Miniseries, so you won't be surprised to hear that the key to effectively managing a growing team size lies in a little forward planning.
As we've said, rather than actually building out the things your growing team will be needing later on at the start of your project, this more relates to a semi-conscious mapping of what those things might be, and some awareness of which development stage you'll want to implement them.
When it comes to efficiently scaling your team, ensuring you have the right tech and tools in place that can be used by multiple team members, each likely of different domain expertise and experience, is crucial.
Building your game on a backend like Metaplay, which has hand-crafted tools designed exactly for this purpose, is the easiest and fastest way to go about doing that.
Tools like Metaplay's LiveOps Dashboard have been specifically designed with multiple departments and needs in mind, and though many of its functionalities may not be immediately useful at the start of your game development journey, as you grow, they'll become invaluable - and your new team members will wonder how your game could ever be operated without them.
The savviest developers spot this from the start and do all they can to mitigate future growing pains later.
--
In the next and final instalment of the Building for Scale Metaplay Miniseries, we'll tackle the reason most professional developers are here in the first place: revenue. Of course, we all want that to go up (and get excited when it does!) - but like everything we discuss, it's not without its unwelcome consequences.
Join us next time to discover exactly what they are, and how to plan for effectively navigating them.
