I recently co-wrote this article for the second issue of Gamesauce magazine with my friend and colleague Kenn Hoekstra. In it we break down some of the roles that development-side producers perform, and what a good producer and a not-so-good producer would do in each role.  Hope you find it useful, or at least good for a laugh!

Speaking of Gamesauce, it’s incredibly late to be mentioning it now, but I’ve been working on helping the fine folks there (most of whom I count as friends) host the 1st annual Gamesauce Conference, which will be held next week in Seattle, just before the Casual Connect conference.

Our goal with the conference is to do a really solid, grassroots devs-only program that isn’t cluttered with thinly-veiled marketing pitches or mobbed with students and vendors.  Somehow I got roped into being designated Conference Director as well as Emcee (along with industry legend Chris Taylor!) so hopefully I don’t embarrass myself too much

After the show, video and slides of ALL the talks (along with other supplemental material) will be posted online for free.  If you can’t make the conference, stay tuned for the slides.  We should have some really great talks!

At the same time, a producer has to know when to communicate.  Bonding with the team, listening to their concerns, even shooting the bull at the water cooler are important and necessary, but every hour you spend talking is an hour you spend not doing — likewise with your team.  You can have the tightest group of ninja developers on the planet who get nothing done but talk if you’re not careful.

So how can a producer manage a team virtually?   Isn’t this a recipe for disaster?

So far, it turns out that it doesn’t have to be a disaster, but it is a huge shift from everything you’re used to.     Here are some best practices for remote production:

1. Team size may be the single biggest determiner of success in this kind of endeavor.
   This is probably not very surprising.   Since team size plays into your scope as well as how much it’s going to cost to complete, you want to keep the core team as small and ninja as possible.    Not only does additional headcount increase burn rate, but it also slows down decision-making and iteration.  It is almost always better to have fewer people for longer, than more people for less time.  Sadly, most publishers would disagree with that position, doubly so if you think you’ll miss the quarter. 
   
   Naturally a smaller team probably means a smaller scope.  This is not a coincidence




2. You need a multidisciplinary team.  Emphasize broadness over depth of expertise wherever possible.
   This goes hand-in-hand with #1, but if you’re keeping headcount as low as possible, you really cannot afford the luxury of a team comprised of specialists who can’t help you with brute force gruntwork.   At the same time, you will certainly need experts in specific areas.  Be judicious where you spend your personnel XP.




3. The 9-to-5 (or more likely, 10-8) as you know it is over.   Track results, not effort.
   This is a really, really big thing to adjust to, and even harder to train a team to do.  If people are working from home, don’t expect them to be chained to their computers every waking moment of the day.   They will have distractions.   Real life will deign to intrude on your project in their mental to-do list.  Spouses, children, and pets don’t necessarily care that it’s officially “work time” — all they know is the person they’re looking for is home and accessible.   This can be a great selling point, of course — what better for work/life balance than to be able to see your kids every day during work?The trick is to focus on results, not effort.  Don’t be concerned with ensuring your team’s collective butts were in their seat for 8 hours yesterday, be laser-focused on when systems and assets will be finished.    Much has been written about this style of management and how hard it can be to implement in a 9-to-5 culture, but a virtual team is a great context for this kind of philosophy to take root.




4. Minimize Rabbit-Hole Depth.
   What I mean by this is to make sure nobody on your team can go off on a task and waste a week working on the wrong thing.  Because you’re not engaging in “face time” with your team, and because nobody is walking around noticing obvious problems, you need to make sure you avoid rabbit holes, or at least avoid deep ones.  Employ agile processes like daily “stand up” calls to get this kind of information flowing on a regular basis, and focus on getting to Always Playable Build status as soon as is reasonable.




5. Make extensive use of communications tools, but pick your battles.
   I’ll cover specific tools more in-depth in a seperate post, but this is critical (and rather obvious).  No face-to-face meetings?  Skype or conference call.   Overcommunicate via email and use extensive filtering.  Require mandatory IM availability (and allow DND mode as needed for productivity’s sake).  Use wikis rather than Word documents.
   
   However, just because you HAVE communication tools that can pierce the veil of virtual solitude does not mean you should be cavalier with how you use them.  Constantly IM’ing and intruding on your team members and causing context-shifting during their work day is no less irritating and productivity-killing on a virtual team than on a physically colocated one.    In fact, it may be more so, assuming that their own workspace may be subject to built-in distractions that an office environment may not (family members, a fully stocked fridge, the temptations of ESPN, etc.)
   
   Finally, there is no substitute for a face-to-face meeting, so budget for them and plan to hold them at critical points (kickoff, beta, pre-launch, etc).  It is important to put faces and real people to the names one sees in a project file or IM list.  It reduces the chance of teammates jumping to irrational conclusions about motive and helps to build a sense of team unity in attacking a common goal.

My take on this study is that the majority of companies seriously contemplating a layoff are probably so unhealthy that taking an alternate action probably isn’t a viable choice, anyway.    Thus, the layoffs will continue.  Here’s an idea — perhaps curbing irresponsible growth would allow companies to better focus on the employees they have right now.  Too radical?

• Founded brand-new development studio in Austin for a major publisher to work on top secret project.
• Recruit fantastic group of 10 people to join said studio.
• In roughly 7 months of development time, go from zero lines of code to working client-server MMO prototype (which is actually really fun), create extensive design documentation,  produce concept art book, run market analysis and business plans.
• Receive word that corporate benefactor is not interested in pursuing the project any further.
• Lay off fantastic group of 10 people.
• Lay off myself.
• Joined the ranks of a small local company as a contractor, managing a totally virtual project.

There’s a lot to discuss and a lot of valuable production insight and experience I gained over the last 12 months, and I plan to spend more time chronicling that experience and insight here.  I’m also penning an article with my friend and colleague, Kenn Hoekstra (Pi Studios) for GameSauce magazine (which is the brainchild of the very brilliant Jessica Tams and the incorrigible Jake Simpson) that will discuss some of the roles producers play on a development team.

“Fixing All Your ‘C’ Bugs”

 I was being cheeky, but the truth is, those “C Bugs” are a really great metric for how polished your game is.   If your QA department is worth its salt, those testers are going to be actively trying to bury you in bugs, and the quickest way to numerically overwhelm a dev team with bugs is by enumerating all the C’s.  

It’s hard to reproduce a lot of crashes, and gameplay B’s that aren’t showstoppers require a lot of research, but an exhaustive inventory of all the rough edges, typos, UI inconsistencies, graphics errors, poorly designed scenarios/levels and inaccuracies?  That’s money in the bank

Depending on the kind of game you’re making, it might be a lot more difficult for testers to point to obvious design issues that reflect on the polish of the game, but hopefully your designers are playing the game enough and being objective and critical enough to know before anyone else when the game isn’t a very polished experience.   

It’s easy for a developer to develop a blind spot for all those “little things” like your terrible tutorial (you’re an expert, so you never use it anyway), spelling errors (after a while, you don’t even notice them), graphical errors (a little clipping never hurt anyone!)… but testers, you can’t pay them to turn a blind eye to that stuff.  

So the next time you fire up your bug database and look at your bugs, try mentally substituting the word “polish” for “C”, and ask yourself if you can afford *not* to tackle them!

Mr. Costikyan apparently took issue with a comment made by Michael Capps, President of Epic Games, who said rather candidly that Epic really isn’t interested in hiring someone who isn’t willing to put in overtime to make a hit game, if that’s what’s required.   Considering both Costikyan’s penchant for attention-grabbing rants and Epic’s track record of developing hit games and handsomely rewarding its employees in turn, this seems like a classic case of seizing on an out-of-context quote that really isn’t a fair representation of the organization’s M.O. and using it to drum up controversy.  

That, of course, hasn’t stopped the gaming media from milking the headline for whatever traffic they can get from it, and voila!  We’ve got this year’s EA_Spouse tempest in a teacup. 

To be fair, Costikyan’s primary beef appears to be that Capps used to be an IGDA board member, which proves that the IGDA can’t even get its leaders to stamp out abusive practices at their studios, much less effect change elsewhere.  For what it’s worth, I let my IGDA membership lapse and stopped volunteering to help because I really don’t think they serve any purpose to me as a developer.  In this respect I agree with Costikyan. 

I do, however, think a lot of the ensuing commentary about crunch and how badly game developers are being abused is, frankly, a lot of shite.    This isn’t going to win me any popularity contests, but here are my observations about some of the myths of crunch. 

Myth #1: All Crunch Is Created Equal

One of the biggest problems in the debate on crunch is that the terminology is totally broken.   “Crunching” to finish a game used to refer to the sort of manic, frenzied overtime that always accompanied the close-out phase of shipping a game, and this process lasted a couple of months at most.   (This is key — crunch was a temporary thing.)   Young men would see this as an opportunity to earn their Merit Badge in Hardcore Game Developing, and the rituals of eating dinner together and tracking down elusive bugs until 3am and then crashing on couches, the floor, or on your desk were born.  

Somewhere along the way, a month or two of crunch became a couple of months, and a couple of months gave way to six months.   Every standard distribution has some really sad sack cases, and so the horror stories of the yearlong crunch even entered the collective consciousness at a certain point.   

The thing is, mandatory 60-hour weeks for a year isn’t a crunch.   It’s no longer temporary when you can’t remember what eating dinner in your own home feels like.   Thankfully, the software development industry has already coined a term for this kind of torture: the death march. 

Hell, in Japan, they actually have a word for literally working yourself to death: Karōshi.   You won’t find many people willing to stand up and defend the legitimacy and necessity of the death march.    Adam Martin goes a step further here and decries the use of the term “crunch” entirely, suggesting that it’s an unethical, almost evil practice to require unpaid overtime of employees, and then trying to sugar-coat that evil by nicknaming it something innocuous like “crunch”.   I think this is a little extreme, personally, but you get a sense of the passion that this issue ignites.

Unfortunately, a lot of commentators choose to ignore the extreme difference between a temporary “crunch” period and a death march, and as a result there’s a lot of wasted outrage and indignation that could be put to much better use, like creating online petitions to bring back Firefly or something.    Considering that in the two decades between 1977 and 1997, the average  American full-time worker’s work week increased from 43.6 to 47.1 hours a week, you could even make the case that it isn’t really a game industry issue at all, but a much larger problem. 

Myth #2: Crunch Is Entirely A Result of Management Failure

There was a time I naively believed this to be true (as a fledgling manager, no less!), so folks can be partially forgiven for propagating this meme, but it’s also borne out of laziness, because it implies a neat and tidy villain for the issue of crunch and absolves individuals of any responsibility for the problem.    Don’t get me wrong — if you’re death marching a year before you’re scheduled to ship, there are some pretty significant problems that aren’t being addressed, and odds are good that the folks who own them are not in the trenches.  

That said, game developers take a LOT of freedoms and flexibilities for granted that, when taken individually, are probably inconsequential, but when aggregated do have an impact on the schedule.  I’ll cover a few of these in a minute.  

Probably the most well-documented impetus for crunch outside of the “incompetent management” straw man is “those damn youngsters trying to prove they’re hardcore”.  I don’t personally think this is anywhere near as prevalent as it used to be, but OTOH I’ve had the luxury of selecting my teams for most of the recent past and I haven’t had too many damn youngsters in the mix, or at least not enough to generate any appreciable internal pressure towards the “crunch for street cred” ideal.

Another factor that has very little to do with management “failure” is simply the desire of devs to make a great game, and the demands that places on a plan and schedule.     Most teams have no desire to work even a 9-to-5 job making shoddy, inconsequential games.  (this makes the rhetorical attack on Epic even more absurd)  

Even making a 70+ metacritic game is no trivial matter, as evidenced by the vast majority of titles that fail every year to hit that mark, much less an 85+ or the real Holy Grail, the 95+ game, which is Sports Car Bonus Check territory.     Given that so few teams can execute even once in this manner, much less consistently and reliably, you may start to form a hypothesis here — making smash hit games is really hard.    

It therefore stands to reason that it’s unlikely any team is going to be able to lay out an accurate and exhaustive blueprint for how to build a monster hit game, accurately forecast and schedule it, and then execute that plan to perfection without relying on any overtime.   Reality check: if you think you’re The One True Developer who can make this happen, I invite you to fall on that grenade and get back to us in 25 years when your masterpiece is complete.

You may be thinking, “a-ha!  If you were only using agile methodologies, you wouldn’t *need* to build a perfect blueprint up front!”  And this is true.  Sort of.   Agile allows you to react to shifting priorities better, and helps you to realize when you’re totally overbooked.  But you still have to deal with the issue of how to fit all the toys into the box.   And if you run out of room, you either throw out some of your toys, or get a bigger box.  

Myth #3: Other Professions Don’t Have This Problem

This is a logical offshoot of the “gaming is still an immature, Wild West medium that needs to grow up” fallacy.  Even if you toss out some obvious parallels in competing media, like television and film (“but they pay overtime so it doesn’t count!”) or writing (“but the author himself chooses when to write and nobody’s making them work late!”), you have situations like the legal field, where people work themselves to exhaustion to try and make partner, or medical students, or even teachers, who aren’t paid overtime to do lesson planning or grade papers. 

Even retail, which could arguably be considered one of the most rote and mundane types of jobs, have seasonal hours that stretch long into the night.   Sure, the cashiers and hourly employees get paid extra for that, but most store managers generally don’t.     And if you told them that they’d been relieved of the burden of having their stores open an extra four hours a day during the holidays,  do you know how overjoyed they’d be?  Not very, since the bulk of the annual sales they need to hit to make their sales goals occur in that timeframe, and I’m guessing they’d generally prefer to remain gainfully employed.    

OK, so we can argue that they are being taken advantage of just as badly in this situation as we are, but when you really compare the plight of retail store managers to the average game developer, which group sounds more worthy of sympathy?    The bottom line is that as well-paid professionals, the vast majority of us are hired to get results, not to put in a quota of hours each week.   

Myth #4: Crunch Is Totally Unavoidable In A Creative Medium

A lot of beleaguered managers adopt this position, under the impression that if there’s no silver bullet to fix the problem, there’s no value in even trying.  

Simply being open about the company’s view of overtime and commitment is a big step for a lot of organizations (which again makes Epic’s position even more sympathetic), because potential applicants know up front that the company is realistic about crunch and won’t shy away from it if it means the difference between a marginal product and a wildly successful one.  

That said, it is totally possible to design, schedule, and develop a game without any crunch.   The caveat here is that you have to dramatically limit your risks to achieve this type of development footprint, and rarely is risk reduced without a corresponding reduction in reward.    I’m sure there are a few examples of highly successful products that endured a negligible amount of uncompensated overtime, but I suspect no more than a few, and I certainly can’t think of anyone who can pull this off consistently.  Even the IGDA’s Quality of Life group has precious few real-world examples to point to in this regard.   Blue Fang did pretty well with Zoo Tycoon for a while, but you can see from their product portfolio that they are the very definition of risk-averse and sticking with their core competency. 

Besides, if your boss ends up asking you to crunch, are you more likely to agree if he tried everything in his power to avoid crunch, or if he just goes to this line and tells you to suck it up?

Myth #5: The “Quality of Life” Myth

As I’ve tried to illustrate above, our industry is not unique in struggling with work/life balance, nor are we likely to get much sympathy from a lot of other occupations, especially given the extremely specialized nature of what we do, the fact that we’re reasonably well compensated for doing it, and that we don’t risk our lives or (much) of our health in return.  

Sure, extended crunch periods or death marches wreak havok on one’s personal life, caused people to miss moments in their children’s lives, and have put stress on their marriages.   This is regrettable and something we should continue to strive to improve, but the fact is that these problems are part of nearly every other industry, too.  And let’s consider just a handful of the freedoms and “soft benefits” that game development affords:

• The freedom to arrive much later than most “traditional” jobs.   Anecdotally, of course, but it is rare in my experience for developers to arrive before 9:30, and fairly common for people to arrive as late as 10am at times.   The concept of “Core Hours” is fairly prevalent among game development studios and demonstrates the need to accept flexibility from employees while still maintaining a single team feel for communication and coordination purposes.�
   
• A significantly relaxed atmosphere in terms of clothing, freedom of expression, and individual space.   Having worked in Corporate America before joining the game industry, it’s worth recognizing just how big a deal this is, and how easy it would be to take this for granted, especially for those who enter gaming right out of college.    Not having to wear a suit every day is A Big Freaking Deal.   Being able to have tattoos, piercings, dreds, or extremely poor hygiene in general and *not* have your career negatively impacted is A Big Freaking Deal.�
   
• The freedom to play games at work!  Sure, a lot of the time it’s research, and it can get tedious.  Yes, even the guy who tastes the ice cream at the Ben & Jerry’s factory gets sick of ice cream, but it sure beats the hell out of being the guy who has to taste the sardines at the sardine packing plant.  �
   
• Lucrative financial rewards / bonuses / profit sharing when products are successful.    What?  You’re calling bullshit?  Okay, fair enough.   There *are* companies who do this well, but most do not.    Epic is one of the ones who does it right, as did Firaxis (my former employer), and I’ve heard Blizzard is pretty good about this now that they’re worth more than the entire nation of Iceland.    But I think this is really the root of most of the bitching about crunch:  people don’t want to kill themselves to ship a game that tanks and doesn’t reward anyone for the effort.  

Does any of this mean that it’s “OK” for game developers to be forced to work unpaid overtime?  Certainly not.  What it does illustrate, however, is that compared to a significant amount of other professions, we’ve actually got it pretty easy.    I pretty much agree with everything that Erik Bethke said in this comment on the subject.  The fact that “Quality of Life” is constantly being used as shorthand to describe how awful game developers have it is incredibly ironic, in my view.   

Myth #6: You Don’t Have A Choice

A lot of younger developers believe this, and it’s unfortunate.  To begin with, we have to take a step back and realize that we’ve chosen to work in this field and not, say, business software, IT consulting, or manual labor for that matter.  It’s a choice.  Even at the organizational level, unless you happen to live in a market where there is literally only one employer, you probably have a choice of where you want to work.  And not all workplaces are equal, not all projects are equal.   Dare I say it, but not all team leaders/producers/management types are equal.  

Even beyond that level, though, you as an employee have a choice to say “no, I’m sorry, I can’t do that”.    You’re (probably) not going to get fired, especially in today’s climate.  You WILL be scrutinized, though.  Are you really working a full eight hour day?  Did you take a smoke break every hour and an hour  lunch break?  How long did you spend on SomethingAwful before the morning meeting?    Run some WoW raids during lunch that spilled over into the 1 o’clock hour, maybe?  It’s a two-way street.      As Scott Jennings correctly points out — 60 hour workweeks usually aren’t, and the truth is, the 40 hour workweek often isn’t, either.

As a producer, I’ve had to accommodate people who couldn’t or wouldn’t work any overtime, and most of the time, those guys were like clockwork.  They weren’t the ones chatting for an hour in the morning about the news or taking extended breaks, because they knew they had a lot of work to get done to get out of there on time.   I had no problem working with them and knew exactly what to expect and what not to expect.   Any producer worth his or her salt should be able to handle both types of lifestyles.  But you can’t have your cake and eat it, too.      

Finally, I’ll say the opportunities for indie game developers and smaller-scale teams to make a living off of games have never been more plentiful than they are right now, so there really isn’t any excuse for people to feel forced to crunch to the detriment of their health, family, or job performance.   Vote with your feet and raise the issue and/or leave if you’re in the situation.    There’s never been a better time to be in control of your own destiny.  It’s your choice.  

So You’re a Crunch Apologist, Then?

Here’s what I believe — when something is offensive to you, you have a choice.  You can suck it up and keep doing what you’re doing, you can try to change it, or you can leave and try to find a better situation.   The trick is to make sure you’re really being critical and objective about just how bad the problem is, and whether the grass is really greener.  

As a producer, I don’t really care for crunch.  It makes people cranky, it’s a pain in the ass to coordinate dinner every night, and it’s debatable if the additional hours outweigh the brain fog-induced errors, but there are times when you cannot cut any more fat without damaging muscle and bone, and crunch is your option of last resort.   I try to limit its use to all but the final hectic days before an important milestone if at all possible, and I don’t believe in mandatory overtime, so I ask rather than mandate, and only when I feel it’s absolutely needed.  Even then, I won’t ask my team to do anything I wouldn’t, so I’m right there with them. 

I also recognize that because it’s likely I will need to ask my team at some point to volunteer some unpaid overtime,  I try to be as flexible and generous with accommodating team members’ needs during the times when we’re working a normal work week.    Perhaps most importantly, I believe that you should only hire people who share your passion for the project, and I believe you need to give those people a sense of ownership and investment in what you’re trying to accomplish.   That means giving them a say in major decisions, and rewarding them financially when things go well.

I suspect that is really what Mr. Capps was trying to emphasize, and based on friends and acquaintances of mine who have worked at Epic over the years, it sounds like most of their employees feel the same way (and have no regrets about the products they created or the way they were compensated).   I just don’t see how that’s a bad thing for our industry.

I break these down into the following categories:

• Failures of ideas / design
• Failures of execution
• Failures of management (including HR, strategy, marketing, and sales) 

Failures of ideas / failures of design

Despite having a solid team and unfailing support from management, the game just never “clicked”.  

1. The game just wasn’t fun.
2. The game didn’t differentiate itself or bring anything new to the market.
3. The game was not something consumers could relate to.
4. The game was too difficult for the majority of the target audience.
5. The game simply failed to find its audience.

Failures of execution

You had smart people, a good idea, a solid plan, and plenty of resources.  So what happened?

1. The team lacked cohesiveness and failed to “get on the same page”. 
2. A significant portion of the team were just underachieving.
3. The technology requirements didn’t match the demographics of the target audience.
4. The team was unable to reach an acceptable level of production values and/or lacked the engineering skill to implement the game systems.
5. The team made poor technology architecture and/or art direction choices.
6. The game neglected end-user usability.

Failures of management

The bogeyman of failed projects.   It’s always easier to blame management, but hey, most of the time we/they deserve it.  That said, the items on this list are often the gaming equivalent of postmortem wounds.   They would have killed the victim… if the victim hadn’t already been dead.

1. The game was shipped too soon (lack of polish, or too buggy).
2. The game was scheduled for release at the wrong time.
3. The wrong people were selected for the project team.
4. The project was not given sufficient resources to achieve its stated goals.
5. Wait, I didn’t know we had stated goals!
6. The plan was unrealistic and/or didn’t account for risk.
7. Development costs were out of line with audience demographics and/or sales projections.
8. Marketing / PR was “phoned in” and never really helped sell the product.

“The game just wasn’t fun”

Probably the scariest of all failure cases, because fun is so subjective and there are no easy fixes to this problem.   Fun is like smut.   It can be described to a rough degree of precision but there will probably never be clinically definable standard for what it is.   However, “you always know it when you see it”.    So how do we prevent this failure case?   Iterate early and often.    You may not be able to permanently dodge the gremlin of a boring game with this tactic, but at least you find out quicker and cheaper that the game idea you were pursuing just wouldn’t work.

The game didn’t differentiate itself

This happens most often when a competent but unimaginitive team sets out to make a derivative or clone product because an opportunity is seen in a particular space, as opposed to working on something they all have a burning passion to do.    It should be mentioned, however, that this can be a perfectly viable approach if everyone involved knows that this is the goal upfront. 

The game was not something consumers could relate to

Sort of the exact opposite of #2 — here your unique snowflake of a game was perhaps too different.  Human beings need to be able to classify and pigeonhole things to make sense of the world, and there’s a reason some types of genre formulas endure so well.   Another offshoot of this failure case is the failure to tap into player fantasy.   While not a 100% universal rule, this is a pretty good litmus test for killing an idea for a game.  “What’s the fantasy I get to live out here?   Is that really an escape others aspire to?  Who do I expect is going to go for this?  Are the fantasy and the audience expectations aligned?”

The game was too difficult for the majority of the target audience

Two words: SHELF MOMENT.  You don’t see this that much anymore, mercifully, but there are still a lot of games whose designers forgot that I play games because I like to have fun.  One of Sid’s great maxims is that the player should be having the fun, not the computer.   I’d like to add to this that the role of AI should be to challenge me, and yes — maybe even let me win — rather than crush me under its unstoppable binary bootheel.   

“The game simply failed to find its audience.”

It’s hard for me to believe that this isn’t just a catch-all for a failure case or combination of failure cases that haven’t been identified yet.  But, this happens enough that it seems to warrant consideration for inclusion onto the list.

The team lacked cohesiveness

This could just as easily live in the management section but communication is a 50/50 proposition and too often people don’t want to go digging for answers they aren’t getting, because they’re afraid they’ll be rewarded with more work.   Regardless, this is just a classic manifestation of a team that has no idea what they are supposed to be doing.   

The team underachieved

A brutal failure case but the most straightforward in terms of how to fix.  That said, actually doing the fixing is another matter entirely.  “Performance improvement plans” (or if you prefer, the “Come to Jesus” meeting) are well-intentioned, but inspire the kind of dramatic turnaround one would hope for.   Firing is difficult, not only from a legal and CYA perspective but also from a personal perspective.  Or at least it has been in my experience; YMMV. 

The technology requirements didn’t match the demographics of the target audience

One of my all-time favorites!  We pretty much nailed this one on Railroads, actually.   This one should be common sense but it’s surprisingly easy to convince yourself that “everyone” has a dual core box with a GeForce GTX.   Not every game needs to have massively detailed models that look like they’ve been dipped in super-saturated, wet shiny paint.     If your game does, that’s OK, just make sure you’re doing it for the right reasons.  Namely: your target audience expects and demands it.

The team was unable to reach an acceptable level of production values and/or lacked the engineering skill to implement the game systems.

This is sort of a cousin of the underachieving team case, and probably a variant of the management failure case of assembling the wrong team.    But sometimes you just end up with goals that are too ambitious to be realized with the team and/or resources you have.   To put it another way, a team must know its limits.  It’s okay to reach high, in fact it’s a great thing.  But doing so is a risk.  You need to have a fallback position.

The team made poor technology architecture and/or art direction choices.

Here’s a case that’s possible when you have the right people and you’re not even necessarily being overly ambitious.  You had a number of ways you could go when determining fundamental architecture of the game server, or you needed to decide between two different art styles each with compelling positives and some risks.   You pays your money and you makes your choice.  Yeah, sometimes you can make the wrong choice and it can be catastrophic, but this is another case that can be mitigated somewhat through iteration and “failing early”. 

The crazy thing about this one is that fear of this is probably the single biggest driver of bad hiring practices (looking for “experienced” people at the expense of green but passionate young developers, ignoring your gut, etc) even though I suspect the majority of failed game projects didn’t die at the hands of this case.

The game neglected end-user usability

I almost left this one out, thinking instinctively that it was probably a variant of the failure to polish, but then I thought about the number of games that epic failed the new user test and decided to include it on its own.   This is really just inexcusable in today’s day and age, but for some reason, we in the games industry treat usability like a crazy third world automobile manufacturer who thinks seatbelts should be a customer option rather than standard equipment. 

I mean, think about this — we spend multiple millions of dollars developing products and don’t bother to make sure people can actually figure out how to use them properly!  And the worst part is, it’s relatively CHEAP and EASY to do the testing!     The good news is, if you actually do care about usability, you’re probably going to beat the snot out of the optional seat belt guys you’re competing against.

The game shipped too soon

Probably the single most casually dropped reason for a game failing; everyone thinks their game shipped too soon.   Tabula Rasa was in development longer than my two children combined, and the majority of NCsoft Austin said they felt the game should be held back a few more months in a now-infamous survey that was conducted right before the game went live.   Thing is, few games actually fail because of this alone. 

What people think they mean when they say the game shipped too soon is that  it needs more polish.   You’re talking 4-8 weeks — maybe a little more — but mostly, time to get rid of what’s likely a tsunami of B- and C-bugs, to polish and spit-shine that game as much as possible, but not to fundamentally change the game.   Most games in this situation are not going to suffer failure in the market because of a few weeks of polish, unless they are competing with products that are noticeably more polished — and that’s a scary small margin of error for any project to operate in.  

The far other end of the spectrum is where games who fall victim to this actually fail — games that need another 12 months.   I’d argue that any game that’s coming up on its initial projected ship date and only then realizes it’s actually a year behind schedule has already suffered through a litany of other failure cases that just haven’t been diagnosed yet.

The game was scheduled for release at the wrong time.

Here’s one that I wish more press and pundits would call execs on because this is something that can be controlled, isn’t black magic like so much of the rest of game development, and yet continues to sink games every year.    It’s time once and for all to do away with the “help us, Kris Kringle, Christmas is our only hope” myth.    

No other time of the year is more jammed for retailers, buyers, platform certification gatekeepers, and marketing folk, yet the herd mentality prevails because we believe that increased holiday shoppers will lead to more impulse buys … which will somehow… more than make up for the fact that TEN TIMES the freaking number of SKUs are vying for those impulse buyers?!  

And let’s be honest here — shooting for Christmas means you have NO FAITH in your product to stand alone and sell because it’s a great product.  We’re implying that we can’t sell without the help of people accidentally putting our box in the cart.   Perfectly logical for the makers of the Pedi Egg or ShamWow, but I’m not sure it makes sense on a $50 video game.    

Here’s an idea: go look at when Valve and Blizzard have released their last several super-successful products.  Amazingly, because they make killer games with incredible long tail shelf life, they can have their cake and eat it too by releasing new products pretty much whenever they please and gold packs and GoTY editions during the holidays.

The wrong people were selected for the project team

Could be ability, could be motivation, could be two awesome people who just become intolerable whiners when they get within 50 feet of one another.  Regardless, you had the wrong people for the job.  The only thing I can offer here is to try to identify this early, either through one-on-ones or through “in situ” postmorts, and try to offer to move people around, shuffle tasks, or otherwise try to be sympathetic.  But at the end of the day, this is a job.  We’re professionals.  We get paid to make games.  Anyone who can’t get on that train probably has bigger issues.  And your team only has so much carrying capacity for issues.  You want to waste some of it on *that* problem?

The project was not given sufficient resources to achieve its stated goals.

When developers refer vaguely to “management failure”, they’re often thinking of this one.  Simply put, the producer or project lead never had the necessary and oh-so-pleasant discussion with the stakeholders to say “what you guys are asking for is completely out of scope for the time/budget/quality you’re letting me spend”.   Or, the producer DID have that talk, and management said something like, “I don’t want excuses, I want results!” and that was that.   Often teams are bribed, goaded, begged, threatened and cajoled into sacrificing huge portions of their personal lives to try and bridge the gap between What Is Expected and What Can Reasonably Achieved.  We call this sacrifice a “Death March” (not to be confused with Crunch).  

Unfortunately, the best answers to how to deal with this failure case often start with the word “Quit.”.  I don’t think that’s a particularly effective strategy, though.  Just as games can get out of hand when scope creep sets in, one way of dealing with this kind of scenario is to begin implementing cut creep — start cutting things early, small bits at a time, starting with the most expendable, trivial things.   Unfortunately this strategy is likely to just shift your failure rather than avoid one entirely, but hey, at least you avoided a Death March, right?

Wait, I didn’t know we had stated goals!

A personal pet peeve of mine.   And the reason it’s so maddening is that I’m actually Quite Okay with the idea that I’m not working on the flagship project.  I just want to know what the parameters are so I can meet them.   Some people have the belief that whatever they’re working on Must Be The Best Game Ever — they’re the game developer equivalent of Reggie Jackson and figure they’re going to go deep or strike out.  Me, I don’t mind a base hit.  Hell, I can live with a sac fly.  I’ll even bunt if it makes sense.   But you don’t put Reggie in and tell him to swing for the fences when the bases are loaded with one out and you’re only down one run.   For the sports metaphor-impaired: not every title is going to be AAA.  Some titles serve a different strategic role in a product portfolio and must be treated differently.  But the team has to know what their mission is in order to fulfill it.  

The plan was unrealistic and/or didn’t account for risk.

Basically: you suck at estimating.   Don’t feel bad, pretty much everyone sucks at estimating.  You probably failed to give yourself a realistic scheduling reserve, or you were challenged about that reserve by your boss and you caved.     A lot of projects also seem to think that ignoring risk is a viable mitigation strategy.    I’d like to point out how well that’s worked for our financial institutions here recently…

Development costs were out of line with audience demographics and/or sales projections

I really believe that one of the great things about today’s gaming market is that there is a market for almost any kind of game.   You want a hardcore wargame where you get to be Great Britain fighting Argentina in the 1980′s?  You got it.  Want to make a game about h4x0ring computers, stealing information and industrial espionage?  Thank you, drive through.  No matter what game you’re making, there are probably people who want to pay you for the right to play your games.    Statistically, though, it’s just very unlikely that there are one million of them.   So don’t spend yo development cash like it, fool!

Marketing / PR was “phoned in” and never really helped sell the product.

I’m not going to sit here and say this doesn’t happen.  It does.   In EA’s case it’s a famously self -fulfilling prophecy — marketing team isn’t sure a game is going to be a hit, so they allocate less advertising spend and the salespeople don’t push it as hard as they could with the buyers, so the game tends to sell less.  

I will say this, though:  developers have the right and the responsibility to push back.  An enthusiastic and communicative development team that owns the PR process and constantly pushes back for what their product needs can be the most effective campaign you run.    Too many developers think their responsibility ends at making the game, but there is no better advocate or evangelist than a dev who believes in their product.

So this is it.  I’ll be blogging about games, specifically issues relating to game production and management.   Hopefully on a more frequent basis than I updated my old website