MMO games are notorious for their enormous development teams. We hear stories of 80-person teams, 100-person teams, 150-person teams. But setting aside the wisdom of those numbers, what happens to a development team after launch? Most shrink to some extent, although sometimes it’s difficult to tell: some companies regard their live team sizes as top secret information. But how many people do you actually need to support a live game? What is the right size for a live team?
The answer, of course, is: It depends! But let’s look at some of the factors.
Who’s on ‘the team’?
‘Live team’ is usually shorthand for ‘live development team’; it is often meant to include just the core development personnel such as artists, programmers, and designers (plus the production staff needed to support them). ‘Live team’ usually excludes peripheral departments like Operations (the team that monitors the server hardware) and Billing. This makes sense from a conceptual viewpoint: the artists and designers are usually very focused on the specifics of the game itself, while external departments are providing fundamental services to subscribers (who happen to be playing a game but who might as well be trading stocks or running a blog). This attitude especially makes sense when a company has multiple live games and resources like Operations can be shared between projects.
But there are other departments that ride the fence between ‘development’ and ‘service providers’, such as QA, CS, and Community. Some companies use a pool of QA resources that can be assigned to test projects as needed, but in my experience at the very least you need several dedicated QA resources that know the game inside and out to adequately direct such pool resources. Similarly, the majority of CS is usually made up of in-game support (a la “Game Masters”) who will ideally be quite knowledgeable about the game — as will your Community Representatives. (Not only does knowledgeable CS/Community improve the players’ perceptions of support, it also improves the quality of feedback coming back to the dev team — for instance, reports on nasty bugs or exploits.) So do we consider these groups — who are intimately tied into the development of your game even if they aren’t directly building content — part of the live team? And just to complicate matters, consider that Customer Service doesn’t just include in-game support, but also Technical Support and Billing Support, both of which may be largely game-agnostic.
Also, note that, regardless of how you want to conceptually split up your personnel, any MMO game needs to provide all of these pieces to its players in one way or another.
Scaling with Subscribers
Another factor that may influence the size of your live team is the size of your subscriber base. Now one of the interesting aspects of MMO design is that, while the player base may reach truly massive proportions, the relationship between the designer and the player is still largely one-on-one. That is, for the most part each player will experience the content individually — having more players does not necessarily mean that you need more content. (Of course you can argue that more players per world means you need more content in order to space the players out properly, but that’s a different question.) This means that the size of the core development team — the artists, designers, and programmers — doesn’t need to increase with the number of players playing your game.
(Incidentally, I should give proper credit here: It was Brian “Psychochild” Green who first mentioned this equation to me and got me thinking about it.)
On the other hand, this doesn’t hold true for those fence-straddling groups. Customer Service obviously needs to scale with your subscriber base: the more people playing your game, the more will be calling you for help — and that’s true for in-game support as well as tech support and billing support. Similarly, the more community you have the more Community Representatives you are going to need. There’s a trick here, though — your Community team needs don’t scale smoothly. More players means more forum posts means more forum moderators, but it does not necessarily mean more Community Managers generating content for your web site … unless one of their main duties is sorting and distributing fan content, in which case more fans will mean more community content.
In short, you can plan for a live team with a static core of development personnel and a scaling layer of support personnel. I don’t have numbers to hand you about how much support you need per 1000 subscribers, but from what I hear a good support director will. So that’s a start!
So how do you figure out how many core developers you need on a live team? If a larger player base doesn’t mean you need more core devs on your live team, what does? Well, more development obviously! And the amount of development that’s right for your game is a direct reflection of the expectations of your players.
Have you committed to monthly updates? Seasonal events? Two expansions a year? What level of polish are you committed to providing? How fast will major bugs be fixed? Minor bugs? Typos? How often will you add entire new aspects to the gameplay? How often will you rebalance your classes? How much new art will you be adding? New dungeons? New zones?
Once you answer these questions, you can look at how long development takes given your tools and game engine and come up with a realistic estimate for how many core developers you need to support your live game. Combine that with support personnel based on your player base, and voila! That’s the right size for your live team!
I have to admit — no one has ever actually asked me about the proper size for a live team. I’ve been on teams as small as four (including me!) and as large as 80+. Nor do I expect that this article will be magically inspiring or teach anyone amazing new knowledge they couldn’t figure out on their own. But the topic did give me a chance to touch on some interesting aspects of live development that aren’t often discussed. And anyway, half of the the problem in this industry is remembering the stupid obvious stuff we should all know.