When will Duke Nukem Forever be released? When it's done. DNF is the most popular whipping boy for a game development schedule gone horribly wrong, but there have been plenty of similar examples (including the original Unreal). Game developers are notorious for scope creep and gold-plating, as well as massive mid-stream changes in design and architecture. Why is that?
I've become convinced it's not solely due to "unprofessionalism" or lack of effective project management. You see, if you're creating a business application, or a device driver, or control software, you can specify the requirements, from which you can create a design, from which you can create code, which you can trace back to requirements. It's not hard to write effective, measurable requirements for this type of software, which means it's not hard to justify or drop a given feature with objectivity.
But games have a damnable, hidden, unwritten Requirement Zero:
Thy Game Shall Be Fun.
Requirement Zero is a real killer. Because it's not objectively measurable, it's not easy to manage. You can pick on Daikatana because of its schedule slips, or because you don't like its designer, but the bottom line was it just wasn't a fun game, and for more reasons than the obvious "sidekicks get squished by doors" bugs.
I once had a conversation with Danielle Bunten Berry (of M.U.L.E. fame) and a colleague about a particular game. It was gorgeous, free of technical glitches, pushed the envelope on technology, and had a decent storyline. But my colleague summed it up this way: "There's a big hole where the fun should be".
You see, users don't expect their word processor, or their spreadsheet, or the software that dispenses their soda at the local mini-mart to be fun. It's sufficient for it to be "fun-neutral": so long as it isn't so badly designed, defective, or poorly-performing as to be "un-fun", it's acceptable.
You can create a game that completely satisfies the spec, is totally free of bugs, finishes on-time, stays within its budget, and has a flawless marketing program--and it can still be a miserable failure if it isn't fun.
Yes, games ARE different.
5 comments:
What you're saying makes a lot of sense. I especially like the term "requirement zero".
You have to be careful to qualify this and put it in context though. I've heard the "games are different" rallying cry in the past, but it's always been to justify some variety of laziness: we don't need a schedule, we don't need a coding standard, we don't need an architecture, we don't need tests, even sometimes for truly insane things like "we don't need version control".
All of these things can help a game just as much as they can help any other piece of software. HUGE chunks of a game don't need to be "fun": does your memory allocator need to be fun? Your widget set? Your scene graph? Not to downplay "fun", it's hard to get right and sometimes it does extend unforseen tendrils of new requirements down into every layer, but it's only required at the highest level. It's much easier to build a fun game out of robust, industrial-strength parts than out of random pieces of crap developed in a huge rush because "games are different".
Making different things requires different processes. If you follow different processes you will come up with something different.
Game code can be crap, and buggy... and that is ok.
Who cares if it is not 100% right if it looks ok?
Those massive hacks that allow you to approximate something a lot more complex is what brings magic to games.
Especially when you might need to change it, or delete it. In games there is a lot more throw away stuff. Like in drawing, you try different things to see how they look.
The 80/20 rule applies. It can be quicker to hack up something fun that works ok in a few minutes. Especially when doing a short game in limited time.
Non automated version control can also get in the way when trying to make something at speed. It moves your thought process away from the problem. Kind of like managing memory. Simple things like automated rsync to time stamped directories using the changed flags so you can also see what changed at certain times.
Working to make the libraries which you make the game from solid can be a bonus. Especially if those libraries are easy to figure out and use.
However on a limited time working on those libraries instead of working on the problem can be distracting.
*more hand waving, and stuff about magic*
glpyh said:
You have to be careful to qualify this and put it in context though. I've heard the "games are different" rallying cry in the past, but it's always been to justify some variety of laziness...
Right. That's what I meant by "not in the way they intended"--games are different not because the usual rules don't apply, but because there's one additional "boss" rule.
HUGE chunks of a game don't need to be "fun".
Those "chunks" aren't much different from non-game development, though, and they're easier to specify and test than the "must be fun" requirement.
Hmmmmm, I don't quite agree that games are *that* different.
Often enough I've met a game that shows some real promise and is genuine fun, but the technical and design failures are so massive that they outweight any fun there is.
Any software projects development methodologies vary by political beliefs, developer personality, customer personality, problems to tackle etc.
In the end in choosing what practises to follow is a matter of expirience, as in every other software project too.
So where's the big difference?
Indeed, games of today are of different concept than before. Nowadays, games are obviously addicting but they are very character oriented as well.
Post a Comment