Slashdot Mirror


Long Dev Time Equals Better Game?

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."

26 of 88 comments (clear)

  1. According to this... by 9mm+Censor · · Score: 5, Funny

    Duke Nukem Forever will be uber sweet.

  2. I have one name: by IMarvinTPA · · Score: 3, Insightful

    Daikatana

    IMarv

    1. Re:I have one name: by El_Muerte_TDS · · Score: 4, Informative

      Daikatana didn't have a long development time, longer than initially planned, but not long with respect to other games.

    2. Re:I have one name: by Rei · · Score: 3, Interesting

      I would expect long development times to work out better, given the same budget. Namely, because it reduces the number of people involved. Less integration with (and working with in general) other people's code. I'd think it would lead to greater game coherence as well (fewer artists, songwriters, level designers, etc)

      --
      I was watching this thing on TV about some guy named Hitler. Someone should stop him!
    3. Re:I have one name: by /ASCII · · Score: 2, Insightful

      The article is about the development of a PS2 game. On consoles you don't have that kind of problem. You know from day one what your target system is like, and you can write for that one specific piece of hardware. (Not true for first gen titles, which is one of the reasons they look so much worse than later titles)

      --
      Try out fish, the friendly interactive shell.
  3. More data points by tepples · · Score: 4, 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.

    1. Re:More data points by SharpFang · · Score: 3, Insightful

      I wonder about The Elder Scrolls.

      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?

      --
      45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
    2. Re:More data points by ninjamonkey · · Score: 3, Insightful
      I wonder about The Elder Scrolls. It's always delayed by a few months. It's always unplayable until the first service pack is released.
      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 game concepts work and that the project plan is as thought-out as possible. A "gameplay proof-of-concept" before full development begins (artwork, music, etc). If ample time is put into pre-production, there's a smaller chance that the game will have to be completely reworked mid-development, which most of the time results in a crappy and late product.

      2) A cohesive team of developers that believe in the project, WHO ARE SUPPORTED by their parent company and given the necessary amount of time to achieve the game's potential. This means not shipping a half-baked product just to release before Christmas.
  4. Re:Solid work by fishybell · · Score: 4, Insightful
    Having worked on several long-term projects-done-by-small-teams in the past, I can say that my experience differs greatly.

    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.

    --
    ><));>
  5. Three Words: by Lally+Singh · · Score: 4, Insightful

    Mythical Man Month

    --
    Care about electronic freedom? Consider donating to the EFF!
    1. Re:Three Words: by russellh · · Score: 4, Interesting

      Mythical Man Month

      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.

      --
      must... stay... awake...
  6. Based on My Experience by th1ckasabr1ck · · Score: 3, Interesting
    Based on my experience, it would be wonderfull in game development if we could cut down on team size and increase development time. You would think that there is a happy balance here between the cost of the project, the number of people working on it, and the length of the development cycle, but this balance is elusive. Of course the people paying for the projects basically want it done as quickly as possible so that they can get their payoff which basically negates my "longer cycles, less people" plea.

    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.

  7. Software development is like having a crap by LiquidCoooled · · Score: 3, Insightful

    Sometimes you strain and strain and strain for what feels like hours and are sorely dissapointed by the piffly splash.
    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.

    --
    liqbase :: faster than paper
  8. Awesome news!! by Rob+T+Firefly · · Score: 4, Funny

    This means all my hard work these past 20 years on my pet project, "E.T. II" for the Atari 2600, have not been in vain!!!

    1. Re:Awesome news!! by greg1104 · · Score: 5, Funny

      How many of those years did you spend at the bottom of a hole, trying to levitate out?

  9. Re:Duke? by tont0r · · Score: 2, Insightful

    You are making this comment under the assuption that someone is actually WORKING on the game.

  10. Computer Projects by paladinwannabe2 · · Score: 3, Insightful
    There was a computer science teacher a year ago (or so) who took a survey of how long it took his class to do various programming assignments. It turned out that there was no connection between how long the student spent on the assignment and what grade he got on it.

    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.

    --
    You are reading a copy of my copyrighted post.
    1. Re:Computer Projects by masklinn · · Score: 2, Informative
      Source of that comment is Joel's Hitting the High Note article, data comes from Professor Stanley Eisenstat at Yale, who teaches CS 323.

      Scroll to the middle of the page for that part, you can see the chart here, Joel's comment being

      There's just nothing to see here, and that's the point. The quality of the work and the amount of time spent are simply uncorrelated.
      --
      "The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
  11. It really comes down to how development is managed by tokengeekgrrl · · Score: 2, Insightful

    Whether it's a team of 5 developers or 500, if there isn't someone paying attention to the overall picture and architecture of a software product, be it a game or CMS, it's going to take longer.

    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

  12. Good Grief by BruceTheBruce · · Score: 3, Insightful

    I guess the money men like to have some concrete metrics they can hang their hats on, but the hard truth is just that CREATIVE TEAMS make great games. Without a good vision and good creative people behind it, no amount of time will make the game great.

  13. EVE Online... by code-e255 · · Score: 4, Interesting

    EVE Online apparently went through 11 development cycles, with several complete re-codes, over a period of a few years. Their graphics / MMO engine was so ambitious at the time that the developers couldn't do it one big go, so they did it in numerous steps. For them, it paid off.

    http://myeve.eve-online.com/download/videos/?type= 3
    http://myeve.eve-online.com/download/videos/Defaul t.asp?a=download&vid=41

  14. the primary risk of a long dev period by Surt · · Score: 4, Interesting

    Is that whatever technology you settle on may be obviously inferior by the time you release. Imagine starting a game on dx9 now that takes four years to complete. By then the world has dx11 and you have obviously dated graphics.

    --
    "Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
    1. Re:the primary risk of a long dev period by qeveren · · Score: 3, Insightful

      ... because god forbid that someone might end up playing a game that isn't based on an absolute bleeding edge engine of some sort. I mean, nobody plays the original Counterstrike anymore, that's ancient! :)

      --
      Don't just stand there, get that other dog!
  15. KOTOR by darthservo · · Score: 2, Interesting
    I have to say the first Knights Of The Old Republic was far better than the sequel. Many of the LucasArts fans attribute this to such a rushed deadline for KOTOR2. Even some artwork developers complained that their hands began to cause grief after a while.

    Also, many felt that KOTOR2 was so rushed that the storyline suffered as a result. In fact, a petition 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 game with cool features and better story than an early release for a poorer product.

    --

    Prove it.

  16. Re:one word by masklinn · · Score: 4, 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).

    --
    "The way we can tell it's C# instead of Haskell is because it's nine lines instead of two." -- wadler
  17. missing tag feature by Daetrin · · Score: 3, Funny

    I'm not sure if the dukenukem tag on the article should be modded "funny" or "flamebait" :)

    --
    This Space Intentionally Left Blank