Wow. If you watch the trailer, the gate that closes on a monster actually crumples where the monster gets stuck underneath it. This seems like one of those guys who really nit-picks down to the very last detail. It's probably like having a Steve Jobs around, except without the sense of urgency for shipping the actual product. Saying to your team "we could build for 5 years and not deliver anything" is probably not the right attitude you want to instill in a gaming upstart.
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.
Well considering it was pre-production and research, many game titles start off with teams this small. Blizzard only had 20-25 on World of Warcraft before it went into produciton (i.e. the systems ready to start producing assets in). Now they have thousands, but before you get to production game teams are pretty small.
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)
It seems like the big problem was that they were trying to be on the cutting edge by licensing other engines. But, by the time a engine is available for licensing, the flagship title (Doom 3, Half Life 2, whatever) has already shipped and set the new standard. At the same time, they wanted to have the best looking game available, despite always being behind the curve in their base technology.
Sheer hubris. They had a certain sense of humor, they had Duke, and they had a knack for creative physics ideas that affected gameplay, like Duke 3D's cameras, mirrors, and shrink-ray. They could have made a really fun game that was a year behind on the graphics and physics engines. But they wanted to be the best at everything.
Most of the best games on those engines were produced by teams who used the engine as a starting point and built their own tech on top. Many games even contribute back to the parent engine project. Some that stick out in my mind are Soldier of Fortune (complete new damage system for Quake 3), Bioshock (advanced water effects for Unreal 3), Counter Strike (more reliable networking for Source), but there are countless more examples.
Source Engine is essentially the original HL engine + years of heavy duty modification. (This may somewhat fall afoul of the "replace all the parts in the robot one by one, is it still the same robot?" identity problem). I've never ceased to be amazed at just how flexible the orignal HL engine turned out to be!
I met Ken while I was a student at Brown. Not only is he talented (the Wired article only mentioned him as the 17 year old programmer from Rhode Island), but he is also an extremely nice fellow. Not at all cocky.
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?
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?
In the game industry the standard metric is "titles shipped" - you will see this as minimum requirements for various job postings. Not having enough titles shipped on your belt is deadly. It's hard to get people to even look at your resume.
I laughed at the analogy, but I don't think it's appropriate. DNF didn't fail because the coding was subpar. Far from it: every time they released demos, jaws dropped over the extremely high quality of the graphics and game play. Rather, it failed because the project management had no endgame.
In your analogy, the Titanic would have to be the most technologically advanced ship never to, well, ship.
The Titanic didn't fail because of bad welding either, so I think the analogy holds. It set sail auspiciously enough but never made it to port, and hubris and bad management certainly played a role in both cases.
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?
Sympathy. Apparently infinite resources was definitely a curse.
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.
They are not perfectionists. They have many small groups or "cabals" where everyone's input is heard frequently and features are cut when the look like it will not increase the fun of the game. Couple that with the fact that they have some serious talent on board and they know when it is beneficial to outsource(physics engine for HL2:Source) and you have a pretty good foundation.
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.
It may be unfair, but I'd be suspicious; it's easier to start a project than it is to complete one, and there's a lot of end-stage stuff that they may not have experience with.
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.
The problem is likely that Broussard wanted to make the DN game that would last forever. It would be perfect and without flaw. He did this instead of just shipping one in a series of polished games (which he could have made over the last decade+).
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.
That first statement kinda reminds me of Xanadu... (wonder if they're ever going to call it quits)
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...
Software never is "ready". Software might just be "ready enough", whereas "ready enough" depends on audience and domain, I think.
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.
Reminds me of another deeply troubled project out of the Dallas-area FPS community circa 1999: John Romero and ION Storm's development of "Daikatana," as described by this excellent Dallas Observer article: http://www.dallasobserver.com/1999-01-14/news/stormy-weather...
This article in Geoff Keighley's "Behind the Games" series: http://www.gamespot.com/features/btg-daikatana/, provides a more complete account of the story of Daikatana. Without Eidos, and had Romero been as rich as 3D Realms at the time, I am convinced that Daikatana would have ended up as another DNF.
Daikatana basically did end up like DNF, although it was finally shipped after nearly three years of delays to critical disappointment. The time frame of the original was similar to DN as was the hype.
I feel this is extremely relevant to startups. Most startups have no "end"- at least Duke Nukem had a goal ("release"). With startups, they really just go on forever. No startup will ever be finished, and it is far too easy to just keep toiling away with no real goal.
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.
Startups eventually run out of money. It sounds like the Duke Nukem Forever team basically had the same problem; it's just that their money lasted 12 years.
"The way a program looks in the end is not important because there is rarely an end, and if there is one it isn't planned." -- Richard Gabriel
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.
Sure, you can launch. But then what? You still have nothing but time. You can set milestones, and releases. However, since there will never be a "shipped" or "finished" product, many startups end up having no direction.
IMO, software has cycles. Early systems have lot's of known issues that can be quickly fixed. Then mid cycle have little or nothing minor wrong and so you tackle one or more major issues. Then your back to having lot's of little bugs to fix. Microsoft has discovered you can sell both parts of the cycle both new features aka Vista and then bug fixes Windows 7. But, when people talk about the minimum valuable product what they really mean is the smallest cycle where you get something people will pay for at the end.
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
Customer Development solves this problem. You have to leave the building and identify real needs among real customers, a real market niche, and to validate your product hypothesis. Then you're not aimless anymore, you're trying to solve a real problem for real people that you've personally met outside the building.
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.
If you've never read the book Predictably Irrational there is an interesting chapter regarding a professor who performed an experiment with deadlines for his 3 papers due in the semester.
[simplified]
Class 1: Set your own deadlines
Class 2: Strict deadlines from the professor
Class 3: No deadlines
I definitely think so. I remember reading an Gabe Newell interview in a 1999 PC Gamer magazine about this. Newell stated that, after the excellent critical acclaim of Half-Life, that he wasn't eager to begin Half-Life 2, because, "our fans will expect it to be the best game ever." Alas, six years later, Newell and Valve was able to deliver a worthy sequel. The Duke crowd certainly had the same problem, but perhaps lacked the managerial skills and vision necessary of such a project.
Yeah, it would definitely be tough to figure the numbers out. I got the orange box mostly for TF2, and I'm sure I'm hardly alone. But other than the actual TF2 only purchases, it's tough to separate how many units TF2 really shipped.
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.
"Second system effect" is a term from The Mythical Man-Month - the post I replied to links to the Wikipedia entry. It doesn't imply that Quake was id's second game, or that DNF was 3D realm's second game.
That why it's a good thing to get rid of the founder when
the company gets to a certain point some times. Broussard was never really running a business. It may have been a lot of fun, but never really a business.
This story is great and all, but it isn't complete. Why don't they mention the original, side-scrolling Duke Nukem games for the PC? I'm pretty sure I remember owning 2-3 side-scrolling, baddy-shooting Nukem games, and they were equally as awesome.
One of the terrible things about being your own boss is you have no one to push back against, and ridicule for their moronic opinions about cashflow, release it ready or not etc.
I don't think the points on this comment should be negative.
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.
Some comments are victims of drive-by downvotes, and it is annoying.
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.
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.