How Duke Nukem Forever Failed: Unlimited time, budget and ambition
wired.com
wired.com
I was really blown away when a friend showed me that you could blow up parts of buildings in a recent popular game, and then I realized that the effect wasn't all that glamorous after buying the game. It wasn't as if you were dynamically destroying buildings, they just had pre-calculated bits and pieces that would fall off if you shot near them. Broussard would have said "no, the buildings have to be destroyed dynamically" and at that point, the game would never have been shipped.
On top of that, 18 developers? The effects they were after seemed really cool, but as the article pointed out, game teams are growing:
"The long grind began to wear on the staff. The Duke Nukem Forever team was unusually small; by 2003, only 18 people were working on it full time. This might have been adequate back when the game was announced in the mid-’90s. But in the years that Broussard had spent tweaking Duke Nukem Forever, games had become bigger and bigger. It wasn’t unusual for a developer now to throw 50 people or more at a single title. In essence, 3-D games had grown up: It’s as if Hollywood had evolved from tiny hand-cranked three-minute reels to two-hour epic blockbusters in half a decade."
I don't think this guy had anywhere near enough people to get this done.
Even to this day here is their team:
Interesting Internals at Blizzard on World of Warcraft
Team:
- team structure max 5-8 people
- 32 programmers total
- 51 artists total
- 10 production total
- 37 designers total
Output:
- 5.5 million lines of code
- 1.5 million assets
- 900,000 web files
Points of interest:
- leads still work (art lead creates art, programming lead codes)
- structure team around employee skills and strengths
- 20,000 computer systems
- 1.3 petabytes of storage
Total people supporting (only 120 people actually making the game)
- total 4600 people support
Do you think they really have nothing to show for it? Do they take a part of the blame?
I mean, they still have a decade of experience in 3D game development and, as it seems, working with some of the newest technologies out there.
Would you consider hiring them, or would you rather hire someone who spent a decade working for someone who was a better leader than Broussard and actually finished some projects?
Programmers might not have been so lucky...
In your analogy, the Titanic would have to be the most technologically advanced ship never to, well, ship.
Someone with a better knowledge of nautical history could probably come up with a better example. Or aviation - the Spruce Goose maybe?
What do you think about all those developers who, as
the article says, spent a decade working on a project
and now have nothing to show for it?
I had the dubious luck of working on many disaster projects early in my career. The warning signs became easier to spot. I tired of the good-little-soldier routine and became confident to kick up and keep kicking up if I saw my project off the rails.
I've wondered a few times how valve managed to keep the show on the road - their major releases are routinely far later than expected, yet consistently good and successful.
Valve was started by a couple of ex-Softies with two-digit employee numbers. They could have bought the Vatican and turned Catholicism into a LARP if they'd wanted to.
The original Half-Life reached the 90%-complete point before they took some time out and played their own game. They concluded that it sucked, and started over from scratch. They had the pressure of building a reputation, and the advantage of not having to live up to an existing one.
I don't think it's the engineer's fault that the product never shipped, but with no end product we can't make a judgment either way. They could be a bunch of architecture astronauts for all we know. There's something to be said for picking a tech, sticking with it, and pushing it to its limits.
I remember when one of my friends was hired at 3DR and lamented when they were going about one of their engine changes. None of the art assets were usable after the change, meaning they could have just finished up the old game, shipped and then started work on the next one and shipped that too.
The main problem with doing a sequel to a top-selling paradigm shift project is that the sequel by its very nature will not be able to repeat the paradigm shift and still stay true to the original. Or at least its so hard that there are very, very few examples.
I'd imagine that being part of that original team blinds you somewhat to the practicalities of releasing a sequel.
What I would love to see though, is all that unfinished work (if it is still around) being released to the public, so that duke enthusiasts can collaborate and "finish" some of the work to a playable standard...
If you hire me to paint your house, I'll say "sure, happy to help." If you hire me to paint your house by Friday, I'll say "where's the paint can?"
http://www.randsinrepose.com/archives/2003/08/05/incremental...
For example, an in-house alpha test version for a game might be "ready enough" if the software can display a ball the user can control, while a mars rover control system is "ready enough" for actual mars deployment after years and years of testing.
If startups had a set end date where the developers moved on, I would argue that we'd have more useful projects coming out of the Bay Area.
After all, they have forever to get it right.
The secret is to setup your cycles so you make enough money to keep going and or know when to let a product keep without investing in the next cycle. EX: Windows ME. Or Coke with sugar, new Coke with corn syrup, Classic Coca-Cola with corn syrup. http://en.wikipedia.org/wiki/Coca-Cola
http://steveblank.com/category/customer-development/
I've never personally met any startup founders that weren't acutely aware of their limited runway. Generally they are haunted by it day and night. People do get aimless - because they don't test their idea in the real market. In a vacuum, its easy to get lost.
Developers should think and work with this quote in mind, but management (whether it's company management or a person's internal monitor) has to steer them to specific milestones and release points. A release schedule with feature goals imposes a peristaltic rhythm on development, which prevents developers from getting stuck on one aspect of development or straining for a too-distant goal.
[simplified]
Class 1: Set your own deadlines Class 2: Strict deadlines from the professor Class 3: No deadlines
Guess who performed best? Strict deadlines.
[edit]
Also, I highly recommend the book : http://www.predictablyirrational.com/
It's like the DNF story rewritten to have a happy ending.
I got TF2 for free with the orange box, which I bought primarily for portal and HL2e2.
Contrast to Quake, which succeeded under similar circumstances despite deep difficulty. A follow-up to the most successful game of the time, by a team with lots of money to burn. The original announcements described it as almost a prototypical world-of-warcraft type role-playing game, until it morphed back into something more like Doom.
The result was uneven - a weird mix of fantasy castles and sci-fi fortresses speaks to the divisions on the design team - but at least they shipped, unlike DNF, and the end result was fun, unlike Daikatana.
Here's a list of their games
* Dangerous Dave (1988)
* Commander Keen
* Dangerous Dave in the Haunted Mansion (1991)
* Rescue Rover (1991)
* Rescue Rover 2 (1991)
* Shadow Knights (1991)
* Hovertank 3D (1991)
* Catacomb 3D: A New Dimension (1991)
* Wolfenstein 3D (1992)
* Doom (1993)
* Doom II: Hell on Earth (1994)
* Quake (1996)
* Quake II (1997)
* Quake III Arena (1999)
* Doom 3 (2004)
* Quake Live (2009 - Beta)Instead, you have to play that role too.
To expand - the message I take from it is that it's easy to mouth platitudes (and indeed, "mouth platitudes" is a platitude that I've just mouthed) but in some cases they just don't apply. The big game business cannot work on the basis of "Fail early. Fail often." and to trot out that aphorism smacks of cargo-cult thinking.
Such phrases as "Fail early. Fail often." are to be regarded as starting points, something to consider, not as implacable, infallible advice. Unfortunately all too often it is taken as such.
My advice - to be taken with a pinch of salt - is that everytime you hear a well-worn phrase, stop. Is it really applicable in this context?
That's the message I get from "Four legs good, two legs bad." Probably you'd get the same message if you stopped and thought about it. In this forum, it's a shame if you didn't.
I see this problem a lot with nested comments, where people fail to read the comment within the context of the parent.
I would really like to see more people explaining their downvotes. Maybe, through this, they'd figure out the source of the quote and its point would be brought into better focus.