Long Dev Time Equals Better Game? 88
Via a GameSetWatch post, a piece on Treyarch Producer Stuart Roch's blog. He discusses the long development time of Shadow of the Colossus, and what four years of work did for that title. From the article: "Granted, it's a bit of a stretch to make a simple correlation between more development time and higher quality product based on this tiny product sample, but I have to admit, there is certain attractiveness to the argument. Can it be that in a given number of development cycles, those that had more time with less resources would create better games than those that had short dev cycles with monster teams? One might think that having more time would allow for more polish and iteration and therefore yield higher quality product, but as I'm sure you're thinking, examples can be made of both good and bad games that were in production for long periods of time."
According to this... (Score:5, Funny)
Re:According to this... (Score:2)
Re:According to this... (Score:2)
In related news... (Score:1)
Re:In related news... (Score:1, Funny)
Re:According to this... (Score:2)
Re:Duke? (Score:2, Insightful)
Re:Duke? (Score:1)
I have one name: (Score:3, Insightful)
IMarv
Re:I have one name: (Score:5, Informative)
Re:I have one name: (Score:2)
Re:I have one name: (Score:1)
Daikatana: 3 years http://en.wikipedia.org/wiki/Daikatana [wikipedia.org]
Re:I have one name: (Score:2)
For a Zelda or Metal Gear Solid level game, 2-3 years sounds more normal.
Re:I have one name: (Score:2)
Deus Ex: about 3 years
Oblivion: over 3 years (started in 2002)
Doom 3: over 3 years? (~2000-2004)
Ok, a couple of long ones, it's hard to come up with real figures.
2 to 2+ years sounds more reasonable for the development of a game from the design document to the release.
Or at least, in most cases.
Re:I have one name: (Score:4, Interesting)
Re:I have one name: (Score:2)
Re:I have one name: (Score:3, Insightful)
Solid work (Score:2)
There are so many things to disprove this (Daikana). Numerous games that waddled through development hell to end up terrible or medioctre.
Re:Solid work (Score:5, Insightful)
Usually if something is taking a long time, it's not because you haven't polished it enough, or because it's not perfect yet, but rather because it's too broken to sell in its current state. Usually a 3-5 month initial devel, followed by a month or so of in house testing, followed by 3 fscking years of beta tests leads to a very polished terd with lots of useless doodads added on.
Yes, there are examples of projects that have taken a long time, and been good at the end, but you can not correlate the long dev time to the quality in way. The only thing the long time speaks for is that the developers couldn't get everything done in a smaller amount of time. "Everything" of course refers not just to features but also the features working correctly.
Re:Solid work (Score:1)
So you're excited about Windows Vista too, huh? :)
Re:Solid work (Score:2)
Yeah, Master of Orion 3 took YEARS, and turned out to be as fun as an Excel spreadsheet.
Re:Solid work (Score:1)
More data points (Score:5, Informative)
Blizzard games are not rushed. They turn out excellent because they are not rushed.
One of the developers of The Legend of Zelda: The Wind Waker disclosed that collecting the pieces of the Triforce was rushed, and that turned out to be the most annoying part of the game among critics.
Re:More data points (Score:4, Insightful)
It's always delayed by a few months.
It's always unplayable until the first service pack is released.
Shouldn't they delay it by another few monts instead?
Re:More data points (Score:3, Insightful)
If by "The Elder Scrolls" you mean "Daggerfall", I agree with you 100%.
Arena and Morrowind were most certainly playable out of the box (and yes, Morrowind was delayed probably to make certain that it was not buggy to the point of being unplayable).
To me, the recipe for a good game is mostly two-fold:
1) Ample time spent in PRE-PRODUCTION! Making sure that the ga
Re:More data points (Score:2)
Re:More data points (Score:2)
Re:More data points (Score:2)
On the matter of the triforce collection, I not quite sure what people are so mad at about it. Is it having to collect all the maps? They were all little mini-missions, so that part wasn't particularly tedious I thought. Was it collecting rupees to pay Tingle's outrageous transcribing fees? Perhaps, but with the 5000 rupee wallet I don't recall ever needing to do an
Re:More data points (Score:1)
Ocarina of Time even got me a little bored of dungeons nearing the end.
Re:More data points (Score:2)
Really? WoW, meet Tepples. Tepples, WoW, WoW, Tepples. "Hi Tepples, I'm WoW! I get patched every Tuesday, rain or shine!"
Re:More data points (Score:2)
35, ?, M5, M
3?
Re:More data points (Score:2)
Three Words: (Score:5, Insightful)
Re:Three Words: (Score:5, Interesting)
Back in the day, I used to use games as examples of great software. We were doing banking software for enormous financial institutions. We got the Big Book of Requirements and we did our best to make it happen. Not exactly an environment where you can get passionate about the results. So much software is built by people who don't really care, have no real connection (emotional or otherwise) with the final result, and don't feel like they have any way to fix real problems - like usability or bad design. The beast is huge. I always thought that games might be the one place where people really truly cared. I'd played a lot of games since the early 80s, and rarely can I remember an instance of those games crashing, for instance. Games can be better or worse, but they all seemed to have a level of quality that I assumed derived from the passion of the creators due to the unique situation of game creators as user-developers. This, of course, has changed as games became truly Big Business.
But the answer isn't found in Brooks. It's purely Christopher Alexander - when things are built by their inhabitants, they can achieve a wholeness that does not exist in any other way of creating.
Everything else results in the big book of requirements and people that don't care. To the extent that big business drives games in that direction, they will suck, no matter their development time or team structure.
Based on My Experience (Score:4, Interesting)
Of course that doesn't make sense to the publisher, but it really would be the way to get the best games as an end result. You would (or maybe wouldn't) be surprised at how much stuff has been cut out of the games that I've worked on, ALWAYS due to lack of time.
Trying to crunch the development cycle pretty much always just perpetuates this lack of time, no matter how many people you have on the project. When people start going fast they make mistakes. Sometimes they make structural mistakes, or don't think systems out enough before they start implementing. This stuff really bites you further down the line. And forget about having time to go back and clean up existing systems, that oppertunity is very very rare.
Of course these things aren't really game specific, I'm sure people in other lines of work have seen similar trends.
Re:I disagree (Score:2)
Software development is like having a crap (Score:3, Insightful)
Othertimes without even trying your bowels fall out and you almost get swept away by the tidal wave wake it causes.
Don't rush development and for gods sake, flush afterwards.
I have code that I've been holding off developing for a while now - the ideas are still fresh and there isn't any market competition, however I just don't feel relaxed enough to code it yet. The time will come, I'm not going to rush it.
Re:Software development is like having a crap (Score:2)
Best. Analogy. Ever.
Re:Software development is like having a crap (Score:1)
Ditto composing music. Some of my best pieces happen quickly, and others become bogged down (pun intended) and uninspired. Lately I've learned the value of getting my team of one to have a coherent vision from the start, instead of just starting and seeing where it will go. It makes my large scale compositions better, and the overall architecture easier, which means I can concentrate on other things (though composing should always be difficult- any composer who composes things easily
No guarantee for a good game (Score:1)
solid engineered games is no guarantee for succes (Score:1)
Re:solid engineered games is no guarantee for succ (Score:2)
Awesome news!! (Score:5, Funny)
Re:Awesome news!! (Score:5, Funny)
Re:one word (Score:2)
Re:one word (Score:5, Informative)
95% of the gaming population swears that it sucks, 5% didn't answer the question.
100% of those numbers were pulled out of my ass a few seconds ago.
(seriously, it sucks, badly, it was the worst FPS of that time, and it basically ended Romero's career as a PC dev, and more or less shut Ion Storm).
Computer Projects (Score:3, Insightful)
I suspect it's the same with video games- one person with a great idea and good programming skill could program the next "Geometry Wars" in a couple months, while some shovelware games have taken huge groups of people years. (Daikatana is the first that pops into everyone's head, but there have been others). Don't judge a game by how much time has been spent on it- it's like saying a movie will be good because it had a high budget.
Re:Computer Projects (Score:3, Informative)
Scroll to the middle of the page for that part, you can see the chart here [joelonsoftware.com], Joel's comment being
It really comes down to how development is managed (Score:3, Insightful)
I've worked on teams of 10 or less where everything was disorganized and took forever to complete, regardless of additional resources, and ones where there was a Tech Lead making sure everything was on track enabling us to produce far more than we had promised under schedule.
I've also worked in a big company on larger teams and the same logic holds true. An incompetent manager meant lots of programmers stepping on each others toes and producing conflicting code. A competent manager meant lots of parallel and complementary development.
Disclaimer: Of course, I'm generalizing based upon my anecdotal experience and leaving out a ton of external factors that affect development, (funding, policy, overriding and sometimes harmful decisions of executive management), so this is just my overall impression based upon my limited work experience that did NOT involve game development.
- tokengeekgrrl
Good Grief (Score:3, Insightful)
EVE Online... (Score:5, Interesting)
http://myeve.eve-online.com/download/videos/?type
http://myeve.eve-online.com/download/videos/Defau
This is the reason for no Duke Nukem Forever (Score:2)
Could be worse (Score:1)
Far from the truth (Score:2)
the primary risk of a long dev period (Score:5, Interesting)
Re:the primary risk of a long dev period (Score:3, Insightful)
Re:the primary risk of a long dev period (Score:2)
It's about focus (Score:1)
KOTOR (Score:2, Interesting)
Also, many felt that KOTOR2 was so rushed that the storyline suffered as a result. In fact, a petition [petitiononline.com] was raised surrounding that very point.
I have to agree, longer dev times can only help a game's success. I personally would rather have a functional
Re:KOTOR (Score:1)
I mean, I loved PS:T for what it was. But the type of story wasn't Star Warsy.
Cohesive vision (Score:2)
SotC was made pretty much by a single team, and they pretty much had a cohesive vision of what should go into the game. It may have taken them a long time to find out what that vision was, but the team, being small for game team standards, managed to pull it all together in the end through communication and a common goal of making a great game.
Romero... how many teams did he go through to produce Daicrapola? 3? Didn't he bring in a bunch of game mod kiddies
I don't have good statistics... (Score:2)
First up was a graphics overhaul (it needed it). But that again lead to some new opportunities in gameplay, which lead to new game features, which lead to ne
missing tag feature (Score:4, Funny)
Re:missing tag feature (Score:1)
the question here invalidates the question (Score:1)
"examples can be made of both good and bad games that were in production for long periods of time"
Doesn't that tell you something... perhaps there are other factors at play here.
Additionally, there isn't much benefit to using a term like "longer" in the question without providing a "than" to go along with it. longer than what? "longer than a very short time and shorter than a very long time" would be an appropriate answer to a poor question.
Meteos? (Score:1)
Starcraft Ghost (Score:1)
Speaking from experience... (Score:1)
Good games shouldn't take a long time. That isn't to say there is one way to make a game, but "taking a long time" is the suckers route, not to mention the most expensive (and in part why many game dev houses fail after a year or two).
To avoid this,
Battlecruiser 3000AD (Score:1)
Another data point (Score:2)
Malice (xbox) (Score:2)
Seems that the 'talent' were not working on it all that time, the original trailers would have made it a must buy for me.
But the question is should it have been completely killed off instead of taking the long way around that it did ?
Has anyone got any good links detailing what went wrong ?