Each Month, Dev Man Talking invites a prominent developer to share their thoughts on a particular aspect of the games industry they're passionate about. This month Jeff Green, PopCap's Director of Editorial and Social Media, explains how tiny mistakes can massively change the course of game development and how great developers know what their game is and isn't. Want more Green? He can be found ranting on Twitter as @Greenspeak .
You've just started playing a new game. For a brief moment, you've forgotten your troubles, your homework, the economic crisis, and the sad fact that sometime within the next 100 years you are going to be dead. Everything's awesome! And then suddenly you hit a spot that strikes you as the most idiotic thing you've ever seen.
“Wait, seriously?” you yell at your monitor. “I have to backtrack through the entire level just to get a stun gun to beat this guy? Didn't these devs even play their own game?”
What I'm here to tell you is this: Yes, they did play their own game. And I guarantee you that someone on the team had the exact problem as you and brought it up in a meeting. Maybe 30 people brought it up. Maybe the entire team agreed. But the sad truth? There was probably not a dang thing they could have done about it.
Even on a well-managed team, there are simply too many moving parts, all dependent on one another, for things to go right all the time, or even half the time. And unless you're the rare company like Blizzard or Valve, with the luxury to ship “when you're ready,” development is a zero-sum game. You can't accommodate or perfect or even fix what's broken in a game without it impacting something else.
Too big not to fail
Here's one tiny example. One day I wrote a couple lines of dialog and then went to lunch. When I returned, I discovered that because I'd failed to save correctly, I'd broken the entire game and halted 60 people's progress. The result of that was that an engineer, who could have been perfecting one of the game's lame-looking animations, had to fix my mistake. The next day he was pulled away for something else. And so the following week, when he was finally able to fix that lame animation, he was unavailable to the designers, who had a great new idea for a puzzle, but couldn't ensure it would work without his help, except now he had no time because he'd fallen behind because of my mistake a week earlier, and so the puzzle was cut.
Every day is like this. Every game is a gargantuan, hulking, creaking monstrosity of code, teetering along in its development, ready to be wrecked by any number of obstacles, from an artist's broken stylus to a momentary server outage to an engineer eating an old burrito and getting food poisoning. As a developer, you see things you want to fix, things that could make the game better, or even functional, but you can't do it.
You start cutting your losses, not because you don't care about the game, but because you have no choice. The game has to come out that quarter, because shareholders are expecting it, because your company's entire fiscal plan counts on it, and because this is a business, whether you like it or not, and (in the short term at least) a timely broken product trumps a late, perfected product. So, against your own judgment, you swallow your pride. You plan for patches. You pray the critics and gamers won't notice.
Of course, none of this matters at all as far as gamers are concerned. Nor should it. All that matters, to gamers, is what they paid for: the game that's in the box. The secret truth is that when the critics and gamers do start bitching, the developers not drunk on their own Kool-Aid already know what's coming. They know better than anyone just what their game could have been, and they also know what it isn't. And the developers who don't know this? They'll never make a good game anyway, no matter how much time and money you give them.
