It’s quite common in the MMO industry to run into people who want to tell you: what kind of game you should build, what audience you should target, what business model you should use, how you should interact with your players, where you should focus your development efforts, who you should hire, how you should advertise … and generally how you should build and run your game.

Some of these people are industry veterans with amazing amounts of talent and experience; some are armchair designers with amazingly loud voices. Often, it’s hard to tell the difference.

But here’s my secret method to distinguish good advice from bad: If someone tells you what you should do, you can probably ignore them. There is no ’should’ here. There are only goals and paths towards those goals. If someone offers to share the paths they took and how those worked out for them, that that is incredibly valuable information — take it! Use it! But don’t get caught up in should. We’re too young an industry for should.

A recent post by Keira Peney got me thinking about crunch time. One of Keira’s points is that managers need to work to avoid crunch time. But I’m not sure that’s where it should start. It’s a losing battle from the trenches, because from the perspective of the company, crunch time works. It’s only when we bring the perspective of the individual into the picture that the problem arises.

The trouble comes at the very beginning of a project, long before most of the team is even on the job. It happens quietly and without fuss.

Attacking the Time Estimates

Let’s look at engineering. Game company engineers are not inferior to programmers in other industries. An experienced game engineer can create as good a time estimate as an engineer in another industry. We all know that no estimate can be perfect, but … if the game industry’s problem were just about flawed estimates, then every software company should have similar crunch issues to the gaming industry. (They don’t, in general.) So what happened? Someone cut the engineer’s time estimate.

Snipping the time estimate is easy for a manager to do. They can do it in such a way that they don’t even feel like they’re doing something bad. Hell, they usually feel good about how they’ve reined in the project’s budget. At least at first.

The trick is to cut something nobody is paying attention to right now. For instance, nobody will notice if a manager trims the beta from six months to two months. At least, they won’t notice early in the project. But later, when they do realize what’s happened, everyone will agree that a six month beta is mandatory. Since the budget has already been finalized, that means everybody just has to get done four months faster so that there’s time for the beta! Four months of crunch time for everybody!

Other easy places to cut: QA passes and bug-fixing time between each milestone, padding time to account for unexpected surprises, art revision time to rework content from contractors. Attacking these boring, tedious parts of the schedule is infinitely easier than cutting down the schedule the right way by cutting features from the game. Everybody on the team squawks and squabbles and gets demoralized when you tell them there’s no time for Crafting, but nobody cries when you cut bug-fixing time from the schedule. Who wants to fix bugs anyway?

Crunch Time Works

The trouble is that, although we often create elaborate explanations about why crunch time doesn’t help a game, it clearly does work in the short term. EA didn’t create a culture of permanent crunch time — and become incredibly rich — by mistake.

For perhaps a year, you can get more work out of your people by grinding them up. It doesn’t work forever, but over the period of, say, an expansion pack? Absolutely. Later, these people burn out and quit the industry. But you can hire more because there’s tons of people who really want to work in game development. You can pay them squat, abuse them for a few years, and let them leave. In fact, in many areas of game development, the economics seem to demand that you do just that.

Economic (Dis)-incentives

Every mainstream game team does this, to some extent. Publishers demand amazing games on shoestring budgets. If your game company doesn’t force slave labor out of their team, some other company will.

For a company like EA, I don’t know why they would ever stop crunching. They can create tons of reasonable-quality games while paying people terrible wages. They are amazingly successful, monetarily. You can’t deny that it works.

But ahh, MMOs are a bit different from your average FPS game, aren’t they? For one thing, they take 3 to 5 years to make, which means if you burn your people out every year, you notice the productivity hit whenever you have to train up new people. And because the project is so long, you can get into morale issues: the team morale can get so amazingly low after a year or two of crunch time that the entire project can easily disintegrate. You can lose everything by over-crunching an MMO.

So in a way, MMOs are safe havens. Smart MMO companies don’t want to perma-crunch their MMO developers. They wait until the home stretch — the last year — and then they crunch them to jelly. But hey, the employees at least got a few years of non-crunch-time work out of it first. Maybe they should feel lucky.

Fixing It

Fixing it has to happen at the corporate-culture level. If your company is content to be a faceless corporation with constantly-changing underlings, then there’s no incentive not to grind people up. A culture that values longevity is a good starting point.

Longevity can bring its own rewards. The best games come out of teams with a lot of experienced team members. But on the other hand, in order to get longevity, your company has to somehow survive long enough to reach old age. If you don’t crunch in the mean time, how are you going to meet publishers’ insane demands? That’s the question you have to answer, at a company level, before crunch time can end.

It is my firm hope — not quite a firm belief, because I have yet to see it first hand — but a hope that it’s really true: that having a team full of folks with 5+ years of experience is much more efficient than having a team full of brand new folks who are working twice as many hours. I can’t prove this is true. But I hope it is.

Other Venues

Crunch is a hard problem to solve for traditional games. It’s not something a middle manager can just fix unless they’re ready to have some epic battles with the senior staff.

The traditional answer to this problem is a union. I don’t think we’ll see a game developer’s union for another decade or two, because the job roles are too variable to create much common ground.

But there is an easier avenue. There are new audiences for games, like XBLA and Kongregate. These don’t yet have the same baggage as mainstream games do, so it’s a bit easier to avoid crunch time. On the other hand, these new niches don’t have a lot of well-defined genres or conventions, either, so the risk of screwing up is very high. But nothing worth doing is without risk.

This isn’t an MMO news site — we try to focus on practical advice, not ongoing drama — but recently Blizzard made a particularly interesting decision that I want to use to illuminate what goes on inside a dev team. And believe me, unless you’ve seen it first-hand it can be difficult to believe what actually goes on inside a dev team.

A Decision Badly Communicated

In WoW Patch 2.3, Blizzard inadvertently introduced a new creature (a ghostly wolf) that was obviously not intended to be tamable by hunters, but which could be tamed through very clever use of game mechanics (including putting together a small group and dropping a couple hundred gold in specialized equipment). This wolf had no special qualities other than a transparent appearance and no gameplay benefits over other wolves in the game. Players loved it because it looked cool, but it was obviously a mistake so they asked for clarification from Blizzard … and got it: a Blizzard CS Rep posted in the European forums that Blizzard had “no plans to address this issue - it will still be possible in future for everyone who wishes to tame this NPC to do so.” Unfortunately, six weeks later Blizzard apparently changed its mind; the ghostly wolves were removed in a stealth hotfix early one morning. Frantic inquiries resulted in a post by a Community Manager on the US forums, that said: “Through a hotfix we’ve recently removed the ability to tame a Grimtotem Spirit Guide [ed. -- that is, the ghostly wolf].” Although no direct reason was given for the change, they were apparently concerned about the precedent set by “(t)he unintended nature of the taming, the undead status of the guide, appearance of the wolf in relation to the feel of the hunter class, and the complex processes of taming”. Players who had already tamed a ghostly wolf, by the way, got to keep their pet.

To sum up, Blizzard removed content that did not affect game balance after stating that they would not remove the content, and they did so in a stealth hotfix with no prior notice despite the fact that doing so caused a number of players to waste their hard-earned gold.

It’s Not That Simple

Now, I’m not here to rant about this as a player. (Plenty of people are doing that elsewhere!) But let’s look at this situation as a developer: Obviously this isn’t great for Blizzard — it will blow over (as these things always do), but in the meantime it’s doubtless causing some headaches for their CS and Community teams, especially increased CS tickets (which means increased wait times for everyone). Things like this are almost never the core reason that players quit the game, but as we’ve seen from exit surveys they are often the straw that breaks the camel’s back — the trigger that prompts a fence-sitting player to cancel their subscription. A situation like this is not the end of the world, but it’s definitely to be avoided.

So why did Blizzard handle this situation the way that they did?

Sometimes an unpopular, unannounced change is well worth the cost, if there is some good reason to make the change — for example, if a bug threatens game balance and announcing the fix beforehand increases the chance that a lot of players will exploit the bug. And it is even possible to come up with a situation in which a detailed explanation cum apology afterwards is a bad idea because other similar bugs may still remain. But was that the situation here? Since the bug was a misplaced content flag and they let hunters who had already tamed the beast keep it, that seems unlikely.

Sometimes the best reasons for a change aren’t visible to players — and aren’t intended to ever be known by players. For example, as producer of AC1 I once decided to delay a fix for an unfortunate economy-wrecking crafting bug for several weeks. Why in the world would I do that? Because our publisher was in charge of hotfixes; because I wasn’t satisfied that the personnel they had available was sufficient to perform a hotfix safely at that time; because the political situation between us and the publisher was such that attempting to negotiate a safe hotfix would have severely hampered other, more important development priorities; because I knew that in the end, the game would recover from the bug, but I couldn’t guarantee that the team would recover from pissing off the publisher. I’m certain that from the players’ point of view, my communications about that situation were appallingly obtuse. But again, that hardly seems likely to be the situation here.

What Really Happened?

I can’t actually tell you why Blizzard decided to handle the ghostly wolf matter the way they did. I don’t know anything about the internals of WoW’s development process or team. But I’ve seen similar situations develop so many times that I can make a pretty good guess as to what happened. The following fictitious story could easily happen at any of a half-dozen MMO companies:

So. It all started when CS was bombarded with questions about the ghostly wolf. The lead on duty first tried asking the Community team if they knew anything about it. CS and Community don’t always get along — Community is too close with the Marketing team, and everyone hates and fears Marketing — but at least they answer e-mails, unlike the damned Dev team. But unfortunately Community didn’t have a clue either, although they had been noticing similar questions.

And CS was left to pick up the pieces.

The Big Secret

The big secret is that the typical team of 40+ individuals is completely incapable of working as a single entity. There are cliques, there are squabbles, there are stupid dramas getting in the way of everything. Most dev teams suffer from incredible levels of internal miscommunication and politics.

Whenever I interview with an MMO company, I talk about the need for strong internal communication. Most of the time my interviewer just smiles and nods. They usually believe that they already have great internal communication. They are always wrong. Strong communication doesn’t just come from conveying information — it also requires trust, understanding of intent, passion for the game, and the ability to put aside personal disputes for the good of the team.

A live team can become one coherent whole and when that happens everybody is so much more productive, it’s incredible. A gelled team is a beautiful thing, and once you’ve been part of one you will never want to work any other way. But bringing strong organization to a team of 40+ requires extremely masterful leadership as well as hard work, plus some good old-fashioned luck.

[By the way, if the concept of "gelled teams" is new to you, I recommend the classic book Peopleware: Productive Projects and Teams, by Tom DeMarco and Timothy Lister.]

World of Warcraft just launched their winter holiday content, aka the Feast of Winter Veil, and that got me thinking about how enjoyable seasonal content can be to develop. But as usual, there are also some caveats. So here, in no particular order, I present my tips for seasonal content development. Note that these are not limited to the winter holiday events — they can apply to summer festivals or independence celebrations just as easily.

1. Develop a consistent philosophy of seasonal events. Most modern MMO games treat seasonal events as generally light-hearted activities accessible to players of all types and levels and with a strong roleplaying component.
2. Make a yearly schedule of events. Work out which seasonal events you will be celebrating — before launch if you can. This way you can schedule the necessary resources from the beginning and space out your events so they don’t all clump up in one part of the year.
   • For example, EQ2’s largest seasonal event is Frostfell, their winter celebration. Unfortunately since that game has settled into a once-a-year expansion launched in mid-November, and much of the team is traveling and on vacation starting in mid-December, Frostfell has become a real scheduling problem.
3. Plan to reuse much of your hard work each year. Develop a basic event that meets your goals (for example, accessible content for all levels, if that’s your goal) and then vary this slightly every year. New players will find the entire thing interesting and new, while players who have been with you awhile with appreciate both the lasting traditions of the event and the new tweaks that keep it fresh for them.
   • The variations each year can be relatively simple. Have a few small side quests and rotate them, one or two in and one or two out each year. Or do the same with souvenir items: this year you can get a red Santa hat or a green Santa hat, but next year it’s red or gold and the year after that red or silver. Remember that rotating items out is just as important as adding new ones, but it’s also fine to bring an item back after a few years.
   • Many teams give an event to a favored designer and turn them loose to “be creative”, but be very careful about that. Seasonal events are fun to design, which means that unless your designer is very disciplined, you’ll soon have sunk more time and effort into it than you have planned. And if the event becomes ‘Bob’s hallmark’ then next year some other designer will want to top it to prove their worth — and there goes your careful plan of efficient reuse.
4. Don’t make the event too short — you need to give the majority of your players the chance to participate. Generally I’ve found that a full week is the shortest appropriate length for a seasonal event. You can easily extend this to 10 days (from Friday morning to the following Monday morning) if you want to encompass two weekends.
   • And there are exceptions: April Fool’s Day, for example, is generally best handled as a single day of festivities.
5. Don’t make the event too long. Jolly music and silly buffs begin to wear rather quickly, and a shorter event will help keep the enthusiasm for the holiday high.
   • There are exceptions here also, of course — because so many players will be traveling during the winter holidays, extending that one to cover three to four weeks may be the best approach. (On the other hand, this means that you need to be even more careful about content that gets wearisome — especially those Christmas jingles!)

Even with such a seemingly simple topic as seasonal fluff content, there are a lot of factors to think about. But a modicum of planning up front can make the holiday just fly past smoothly, with no muss and minimal fuss.

Zubon from Kill Ten Rats recently posted about why he doesn’t use the test server. His points, valid or not, are pretty common-place: I’ve heard similar complaints from other players over a broad swath of games.

And that’s unfortunate, because a test server can be a wonderful tool for developers to check their assumptions and straighten their collars before their work goes before the entire playerbase. On the other hand, a lot of current games are not making terribly effective use of their test servers, so I completely understand where Zubon is coming from.

So, what are the most important factors behind a successful test server?

1. Know your goals.

   Are you setting this thing up primarily to promote new content or to find bugs? What kinds of bugs? The kind that require lots and lots of players just playing normally (i.e. a stress test)? Or the kind that require intelligent investigation by the players (for example, finding exploits)? Are you looking for feedback? On specific items or on general gameplay systems? Only on the new stuff, or on everything in the game? And if you answered “All of the above”, you need to prioritize!

   In addition, you need to communicate your goals, not only internally — QA works best when they know why you just made their lives hell by adding a test server — but also to the players who might use the test server. Set their expectations accurately and they’ll give you a lot less grief and a lot more help.

2. Work out your processes and priorities.

   How do players report bugs? (And how do you respond when they report bugs in other ways, which they will?) Who is responsible for vetting the reports? How do the bugs from the test server line up with new development? In other words, will the development team drop everything until this update has made it out the door? Or will they continue blithely on their way developing new content while the bugs from the test server rot in a queue somewhere? Or do you hope to handle both new development and the test server at the same time — and if so, how?

   Once you have the bugs fixed, what then? How often do you push a new build through QA? What determines when you push a new build to the test server itself? A fast turn-around makes players feel good about their efforts and makes it easier for them to continue testing. But push too fast and you’ll lose control, introducing more additional new bugs than you fix. Again, setting expectations is a big help here. If you can’t update but once a week, for instance, then let players know — and perhaps post a list of issues that will be fixed in the next build so they can still see that you’re paying attention.

3. Write decent change notes.

   I know this one is hard — believe me, I know how hard it is! — but it’s essential. I’m speaking to the producers here: If you seriously don’t know what’s in the patch that you are foisting on your players, you fail! Try again. (And if you have so many changes going in with each patch that it’s not feasible for you to keep up, you need to slow down your development cycle — your players can’t keep up either.)

   If you do know what’s in the update, you need to tell your testers. You don’t neccesarily have to describe every typo you fixed (especially if you are using the test server primarily for stress testing), but you still need to give them a decent idea of the broad areas that may have changed. Indeed, full disclosure of changes is your best route to avoiding potentially embarrassing unintended consequences.

   Now for my mini-rant: Surprising your players is not an acceptable excuse for leaving things out of the notes. Wanting to give them the joy of exploration by hiding new content is not an acceptable excuse. (If they read the patch notes, their going to read the spoilers that go up 9.5 seconds after the patch is live.) Finding and fixing bugs trumps lore.

Test servers are a useful tool, but they aren’t nearly as simple as just standing up a server and letting players poke around. You either put some thought into what you are doing (and how!) or you’re just wasting precious time and money.

I keep an eye on the help wanted ads for MMO development teams — among other things, it’s a handy way to see who’s doing what, often before they officially announce. And sometimes it’s pretty amusing to read about who people think they want to hire.

For instance, I recently ran across an open position that specified an experienced developer who had shipped at least one triple-A MMO title.

Let me give you a hint here, anonymous hiring manager. You don’t want someone who shipped a triple-A MMO title. All too often, MMO development breaks down into a morass of death-march crunches and frantic, disorganized flailing several months before launch … flailing that includes hiring anyone who can type and can therefore (probably) implement the masses of incredibly behind-schedule content. If ’shipped an MMO’ is your only criteria, you have no idea what you might be getting.

Even the team members who were with the project from the beginning aren’t neccesarily a good bet. It’s likely that they were rolled off to another project as soon as the game went live. And that means that while they spent two or three years setting up delicately balanced code or intricately detailed content, they weren’t around to see how any of it survived when exposed to a plague of players. They went their merry way in ignorance, happy with their creation but utterly unknowing of whether it actually worked.

No, your best bet is to seek out the people who stayed on or were brought onto the project after launch — the live team members who had to clean up the mess made by those frantic final pre-ship months. They’re the ones who learned to work within the limitations of the engine and the budget and the schedule, because they had to — because suddenly there was no more three-years-of-development stretching out in front of them, no more we-have-to-ship-NOW-so-we’ll-hire-fifty-random-people-to-help-and-money-be-damned budget — just a small team and a voracious audience. These are the people who learned how to make the game go. These are the people you want.

Of course not all live team members are competent, any more than all pre-launch developers are incompetent. You’re going to have to interview all the likely candidates, after all; there are no short cuts here. But if you really want to put an experience requirement on the job description, I’d suggest “six months on a live team” rather than “shipped a title” — it’s more likely to be useful.

And don’t worry about the triple-A thing, either. I don’t know exactly how “triple-A” is determined in the MMO space, but if you’ve been paying attention you may have noticed that the biggest launches of the past five years have largely failed. To be sure, the smaller launches have largely failed also, but at least they cost less time and money! There’s no inherent value to being part of the more extravagant failures. On the flip side, you also can’t afford to set aside candidates who happened to be involved with a failure (unless they were directly responsible!) — there’d be no one left!

Hiring for an MMO is hard enough as it is. It always takes way longer than you think it possibly could to find the right people for your team. Don’t make it harder on yourself by seeking out the wrong kind of experience in your candidates.

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!

Meeting Expectations

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.

It’s both a running joke and a truism in the MMO industry that no one quite knows what a producer does. Not only is the job description very flexible depending on the needs of the project, but each company has its own system of producer titles. For example, I’ve held the title of Producer for five products (counting expansions) at three companies, and not only were my actual duties different in each case, but my relative authority and autonomy in the company structure varied widely as well.

I recently had cause to sit down and formulate a unified theory of producer-hood based on three different continuums of responsibility. (In other words, I broke up what I’ve seen producers do into three main areas.) Keep in mind, however, that this organization is based entirely on my own experiences; if you have a different organization, I’d love to hear about it — please drop me a comment or an e-mail!

Responsibilities

First let’s take a look at the three axes of producer-hood: bizdev, task management, and leadership.

Bizdev

Bizdev is short for business development. For a producer, this usually means being involved with the business side of the game: talking to publishers and investors, working with marketing and upper management to expand the franchise, or fending off advances from would-be business partners. Bizdev types may also be deeply involved in contracting and outsourcing (for art, sound, mo-cap, what have you). These duties tend to be very outward facing, in contrast to the other two axes.

Task Management

In many ways, task management is the defining duty of a producer. Many producers are first and foremost schedule monkeys. Of course, there are different levels of schedule monkey: a senior producer might build a high level schedule aimed at meeting the business goals over the course of a three-year development cycle, while a junior producer might check up on a list of tasks every day and then report any discrepancies upward. But it is generally true that all producers, no matter what their title or level of authority, are involved with scheduling on some level.

Task management isn’t just about scheduling, though — it may also be about making sure that the team has the tools that they need to work, that the necessary communication is happening between and within the departments, that there’s a coherent process for getting feedback to the right people, that the wiki isn’t useless, that the hiring process is more or less working — in short, that all of the million and one chainsaws are kept up in the air and that no-one is losing fingers. So task management also implies a high level of general trouble-shooting and organizational duties.

Moreover, the more task management you do the more you become point person for external departments and random requests. Since the producer is the person who knows the status of things, they are also the person that the Platform team comes to when they need an answer about character storage, the person that Customer Service calls when a server goes down, and the person that Marketing e-mails once a week about the expansion launch date (yes, even though it’s on the front page of the wiki in large font). This goes for random requests within the team also: if the toilets near the art room back up, the artists will come to the producer for help. They don’t expect him to fix the toilets himself, but they do expect him to call Facilities for them.

In other words, producers are the people you interrupt with your problems so that you don’t bother the people who are doing real work.

Leadership

While task management is fairly easy to explain (even if it does tend to sink its tentacles into everyone’s pie) the producer’s role as a leader can be a lot more nebulous. The producer may or may not be the “Vision Holder” — that is, the person who safeguards the central focus of the game. Often this role is filled by a Creative Director or Lead Designer. But whether or not the producer holds the vision, they are responsible for transmitting that vision — and not just the game vision but also the company culture. In many ways, the producer is the den mother — making sure that everyone is sufficiently excited and happy, that the leads are taking care of themselves and their people, that new employees aren’t being thrown to the wolves, that everyone has a voice but that all the voices are coming together harmoniously to move the project towards its goals.

Titles

Now let’s look at some of the many producer titles that are in common use, and the main ways that these titles match up to responsibilities. Again, keep in mind that this is just based on what I have seen myself and is by no means definitive — each company seems to have its own system for assigning producer titles.

Executive Producer

An executive producer (EP) is a producer, but also an executive. They are often deeply involved in bizdev and even when they aren’t they tend to be much more business-oriented. For example, an EP usually spends more time thinking about the optimal target audience and how to mitigate risk, but less time troubleshooting the art pipeline. EPs are also more likely to be deeply involved with budgeting. In my experience EPs tend to have less day-to-day contact with the team, but they may also be strong leaders, inspiring the team from above.

Senior Producer

Senior Producer seems to be a somewhat less common title that, like Producer, can mean almost anything. Senior Producers are generally somewhere between Producer and EP in terms of authority and autonomy, but this is highly variable. Sometimes the ’senior’ merely indicates a regular producer with more experience (or one who suffers from title inflation from below), but sometimes it’s used for a very experienced producer who wants some portions of the EP job and not others. For instance, a Senior Producer may be a leader and Vision Holder who wants to avoid the bizdev aspects of being an EP, or one who likes the bizdev but also dips down into troubleshooting the art pipeline on a regular basis. Or they may just be allergic to the word ‘Executive’.

Producer

The Producer title is a tricky one because it might mean any of the different producer types, or it might even be applied to all of them at once. (I used to confuse the EQ2 team by talking about ‘the producers’ — Wasn’t I the only one? — until I realized the problem and switched to the phrase ‘production staff’.) In general it seems safe to assume that the Producer is the main point person, the one who runs the team (and therefore heavy into task management and leadership) unless there is a Senior Producer or actively-involved Executive Producer in the picture.

Line Producer

Line Producer is a term that comes from Hollywood, although the Hollywood version is rather different than the game industry version. In some contexts a line producer is a low-level schedule monkey — someone who maintains the schedule but doesn’t make scheduling decisions. In other contexts, a line producer is a producer who concentrates wholeheartedly on the task management octopus and leaves the bizdev and leadership duties to someone else. Regardless, the line producer is almost always spending a significant amount of time running around talking to people in an attempt to find out what is actually going on.

Project Manager

I nearly didn’t include Project Manager as a production title here. Most of the Project Managers I’ve met haven’t been part of the teams they work with at all — they are more similar to an outside auditor assigned by another department. For example, the Platform team may assign a Project Manager to work with a game team on a particular platform upgrade. On the other hand, I have occasionally seen the title Project Manager used as an upscale alternative to Line Producer. Either way, Project Manager seems to indicate less active involvement with the team — less running around talking to people and a lot more fiddling the colored boxes in MS Project.

Associate/Assistant/Junior Producer

This role varies quite a bit also, from completely independent producers who are responsible for a subsection of a team (i.e. an Art AP, who handles everything a producer would but only for the art team) to people who fetch coffee. The most common role in my experience seems to be similar to a junior line producer — minding the schedule, making sure tasks are getting done, and letting someone higher up know if there is a problem. On the other hand, the EQ2 team had a complement of experienced APs who would have qualified as full producers on a slightly smaller team.

So there you have it — my answer to the age-old question, “What does an MMO producer actually do?” is “It depends.” … which makes it somewhat difficult to explain what I’ve been doing for the past five years. But the important thing, when you’re trying to hire a producer, is not to get too hung up on titles but instead figure out which roles your team needs. You can use these three axes as a guideline — or you can just wing it. After all, most producers are good at winging it.