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

11 of 88 comments (clear)

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

    Duke Nukem Forever will be uber sweet.

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

  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.

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

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

  8. 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
  9. 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