19 September, 2009
It’s the eternal question: When something goes wrong, who (besides yourself, of course) is to blame? In the corporate world, the term “blamestorming” is used to describe a meeting where people try to assign the blame to someone else.
Game development is no different. Sometimes games don’t “live up to their potential”, or some other euphemism meaning “didn’t make the piles of money desired.” Who is at fault? Unfortunately, while the answer might be useful to avoiding the problem again, it’s not always easy to come up with the solution. And, this isn’t just because people prefer to blame others rather than take a long, hard look at themselves.
So, who really is to blame?
Those who have too much fun
In what I can only hope is an attempt at trolling, Tobold complained that game developers have too much fun. He references some comments that Robert Kotick, CEO of Activision Blizzard, made about how “The goal that I had in bringing a lot of the packaged goods folks into Activision about 10 years ago was to take all the fun out of making video games.” All work and no play make Jack a highly productive resource, I guess.
Tobold’s argument is that developers have too much fun making the game and thus shun the “unfun” parts like QA and bug fixing. Given that my first advice to people wanting to get into game development is making games is not the same as playing games, I will disagree with this. Anyone expecting game development to be all, er, fun and games is not going to last long. To an outsider the idea of game developers playing MMOs and having nerf gun wars may be a popular conception, it’s not the case. The nerf guns are there because after 12+ hours of being at work you need to blow off some steam or you’ll blow up at everyone.
No serious game developer who has lasted more than a few months making games is going to say the process of making games is “too fun”. Everyone knows there has to be some part of the job that’s going to suck, like chasing down that one last impossible bug. You don’t get into an industry that has long hours, crap entry-level pay, and high burnout without some sort of resolve.
Uh oh, time to make every PR person out the cringe. Am I insulting my current and potential customers? Will I ever get a job in game development ever again?
But, let’s face it, sometimes the players do make the game suck. In the realm of single-player games you have the “pirates” who would rather rip off any game, regardless of if it’s a big, nasty corporation or some indie dev who depends on people paying for his game to keep his family fed. Take a look at the comments when a developer speaks in favor of protecting his games to see how people turn wanting free stuff into an ideological crusade. Pirates take resources away from just focusing on making a fun game. (Note: Screeds about DRM or piracy in the comments will most likely be removed. Go post on Jeff’s blog, he’s the one that opened this can of worms.)
In multiplayer games, particularly MMORPGs, your experience is influenced by others. The guy spouting racist epithets over voice chat harms your experience and eventually the reputation of the service as a whole. The gold farmer monopolizing a spawn that happens to also be a quest target is frustrating. Or perhaps your nemesis is the “10 gld plz its not mcuh 2 u plz” beggars who hound you in the main cities.
Of course, in situations where people can more directly affect you, such as PvP, the problems increase. A good PvP game requires a really good community. Unfortunately, PvP tends to attract the type of people that aren’t good for the community; they aren’t the majority, but they are a significant force. When people have to worry about more directly about intimidation, spying, and some some random schmuck ruining their day, the you start to see other players as obstacles instead of fellow travelers in the game.
Sadly, this is a case where one bad apple really can spoil the whole thing. There are a lot of kind, wonderful, patient, sharing people you meet in a game. But, one asshole harassing you at the wrong time is all it may take to make you leave the game ind disgust. The power of larger numbers doesn’t always work the way you might hope. Once a few of the good people leave, then there are a fewer people around to counter-act the effects of those bad apples.
Of course, we should look at developers as the culprits, right? They do, after all, create the game and are most directly responsible for it being complete and fun. As Tobold pointed out, if the developers shirk their duties, then the game can end up sucking.
Of course, I’m a developer. And, as I’ve said, people rarely want to take the blame themselves. This isn’t a mea culpa blog post. Sorry M59 fanatics who hate me with the burning passion of a thousand white hot suns.
The most obvious response is that there are often extenuating circumstances. I know from first-hand experience that even if the previous developer is a smart guy, there are always going to be ugly parts to the project. And, smart guys have their off days (or periods of learning how to code in a proprietary scripting language….)
You also have the team factor. A team of artists working their fingers to the bone don’t matter if the programmers can’t deliver on what was specified. A project at 3DO hit an unhappy roadblock when the artists were told the programmers couldn’t make enemies “fly” in the game late in the development cycle. This means that all the neat flying enemies wouldn’t go in, and the artists had to rush to put in new enemies to fill the gap. Even if 3DO’s projects weren’t all on unrealistic timelines by that time, it was an impossible situation no matter how bright the people were.
Of course, then there’s the developer’s favorite target…
Or, “the publishers” for developers who have a publishing contract. Really, what can’t be blamed on the pointy-haired bastards?
Sometimes people ask why managers get blamed when things go badly, but developers take the credit when things go well. That’s the harsh reality of entertainment. If you go to a concert and the lighting is poor, you don’t say, “Wow, the band really sucked!” If the lighting is perfect, you are likely to have a better impression of the band and maybe not even spare a thought for the person in charge of lighting. Even if the band’s performance didn’t change, your opinion of the experience changes and you don’t necessarily give credit where credit is due.
It’s the same thing with games. If the game goes well, the manager’s work is likely to be nearly invisible. Making sure the resources are available to complete the project, making sure the different parts are done and working together, and resolving problems that spring up between different people happens beyond the view of the end user. On the other hand, there can be some bone-headed management maneuvers that do hurt a game quite visibly: Setting and sticking with a shipping date that is too early, cutting necessary resources like QA testing, not providing enough marketing funds for the project, or any of a lot of other problems can hurt a game. It relates to the team problem again: even if all the developers are working hard to do everything they can, a few management blunders can make all that hard work moot. Of course, when things go well it is often the management who is most handsomely rewarded financially, so it tends to balance out.
One problem with blaming a faceless group (and this goes for developers, too), is that it’s just so easy. “The managers fucked it up” is a lot easier to spout off than naming a specific name. One time while at 3DO I was talking to an M59 player they complained about how “the programmers” were screwing up the game. I explained to him that I pretty much was “the programmers” so he was saying I did a terrible job. He became much more subdued after that. Developers don’t name names because that waste of oxygen who screwed the project over may still be your boss the next company you work for.
The nature of game development
Perhaps the blame doesn’t always lie with a person. I’ve said before that the problem with game development is that fun is not easily quantifiable. If you program a calculator, you can see if it works pretty easily. If you program a game, determining if it is “fun” is much harder, especially if you’re a small developer with few resources.
Plus, fun is not universal. As I mentioned recently, I enjoy inventory management. I don’t know why, because my desk is a mess of stacked paper and other stuff; I have a roll of duct tape next to my stuffed Mickey Mouse in his Sorcerer’s Apprentice outfit. (I’m not using them together, they’re just there on my desk!) So, organization isn’t exactly a way of life for me. Perhaps that’s why I like organizing things in the game, because it’s more controllable for me. At any rate, putting in lots of inventory management is probably not a good idea, even if some of us crazies do enjoy it.
Who is really to blame?
Every project that “doesn’t live up to expectations” is unique. You can’t always say one thing or the other is to blame. Possible solutions to one problem (like “take all the fun out of making video games”) may bring other problems much later (like “franchise fatigue”).
The real reason we want someone to blame is because nobody wants to stare failure in the face. If your favorite MMO is being closed down, you want somewhere to throw blame. If your favorite game doesn’t live up to the press it got before release, you want someone that is at fault.
But, whomever it was, it certainly wasn’t me at fault.