[MUD-Dev] Crunch time

[Mark Terrano \{XBOX\}]

Let me take a second to give Crunch Time a little bit of credit
where it is due.  (I come not to bury crunch time, but to praise
him! It's a long post, I started with a couple comments but ended up
with a soapbox)

Yannick Jean wrote:

> within the expected time frame and without any kind of "crunch
> time".  In my humble opinion, as blunt as it may sound, crunch
> time is an excuse for sloppy planning and should never be
> tolerated (some overtime is fine, sleeping at the office is
> not)....

The major difference between large IT projects and games has not
been mentioned in the discussion so far.  Games -must- be fun to be
successful.  IT projects 'only' have to meet their specifications
and be tolerably bug-free. There are shop cultures and methods and
skills that can get you a game a fun game faster - but nobody can
pick a date on the calendar 6 months in advance and say "July 31,
Today the game is 100% fun".  You iterate toward fun, you polish
towards fun, and hopefully you started out form a prototype that
already had a spark of fun.

I have a 20 year background in IT development and have my name in
the credits of 10 million sold games so I've seen both industries;
while there are many similarities between applications development
and games it is the -differences- that drive much or most of the
crunch time.  I'll concede that there are still too many shops that
have basic management problems that lead to disasters, but
entertainment software development is not just a quirky subset of
IT/applications programming.

Not all crunch is from 'bad management, geeks, cowboy programmers'
either: Crunch time comes from people being passionate about their
game and wanting to make the best possible product they can, or have
a killer E3 showing (just a little more polish on that level will do
it) or crank out just a few more screenshots for the fansites.

Having an artistic, creative, or quality standard that doesn't just
stop at 'meets the spec, move on to next task'.  Making a game the
best it can be is sometimes having to take a gamble on a feature
just a month before code complete - and that usually means crunch.

We are a hit-driven industry and the tiny minority of games are
keeping publishers profitable while they publish way too many 'met
the spec, shipped in the fiscal year' not-fun crappy titles.

Amanda Walker wrote:

> The marketplace is littered with the dessicated corpses of games
> produced on crunch time.

The marketplace is also crowned by products that are very
successful, high quality, and still involved serious crunch time.

Ben Tolputt wrote:

> the Starcraft game has been widely acclaimed as a pretty
> successful game (both as a game & as a marketed product). I think
> many people would agree that the "technology" of that game was not
> 'up-to-date' when it was released. It is still a very popular game
> and I

Games like Starcraft and Diablo *by necesity* are not cutting edge
technology because they get more than 50% of their sales outside of
the US.  If you need a Geforce4 card minimum, what happens to your
title in Japan where 75% of the gamers are using Laptops?  If you
want your title to have broad adoption in Europe you'd better target
'last year's machine as your spec. If your gameplay is good enough,
people will upgrade their hardware to play (I'm thinking SWG's
responsible for the recent demand in memory chips :).  In the
console space where 'all things are held equal' on the technology
side - there is more sensitivity to content quality and
aesthetics...but gameplay still rules over technology on all
platforms.

--In Defense of Crunch--

For Age of Empires II - we had planned crunch times (12hr days, 6
days/wk meals provided - 2 or 3 weeks at a time max)at milestones,
E3, etc - and a month of crunch to push the baby out of the door.
There is a certain excitement involved with crunch that you don't
see at any other point in the project, when a ton of new art, music,
animation, and gameplay comes together all at once - the game
practically leaps forward and each playtest is like unwrapping a
great present.  People are invigorated and excited when they see the
game starting to come together and get more fun with each build.

Crunch time can be a bonding experience when you rely on and work
closely with your teammates, and even a path of self discovery (like
a climber or endurnace runner I know what my real coding performance
limit is - and it was much higher than I would have guessed).  And
yes, Crunch time can also be a hellish grinding waste of human life,
health, and relationships - but so much depends on the project, the
attitudes of the team, and how long that crunch goes.

For Age of Empires we crunched for nearly a solid year - it was our
first title and we were never asked once to stay extra time.  As a
team we knew we had to make the best possible game that we could -
in a crowded field of 43 RTS games announced in 1997 we exceeded all
expectations.  Did I write some embarassing 3:00am code that took
extra days to debug - of course.  Did I make some mistakes I might
not have made - yes. Did we work out subtle, artistic, and sometimes
beautiful solutions to problems after a midnight playtest - many
times.

Would AoE have been a success, built a company and one of the
strongest franchises in PC games without a lot of sacrifice by a
very dedicated team...not a chance. That probably falls under your
'geeks just want to work all nite and code' observation.

Are those experiences typical?  Possibly not - but they are much
more common at successful companies (ES, Blizzard and a few others)
than at the shops that shut down or don't ship games.

--So why all the 'bad crunch time' then?--

The thing I always hope will get better but doesn't show any sign of
doing so is the strange lying dance that happens between every
publisher and 3rd party shop.  If you actually bid how long it will
take to do the title with 'Acceptable and Reasonable IT Management'
comfort padding for contingencies and 8-to-5 days and vacations -
the publishers cry "too expensive", "takes too long!" you will have
no funding and will fold.  Or tell them that a great game needs 3-6
months of polish *after* it is fun and they look at you like there
are lobsters dancing on your head.  So developers always bid far too
optimistically and publishers go in trying to get the real schedule
while always expecting some slip - and the difference between those
two disparate equations is made up with crunch time and killed
projects.  The few bold attempts at correcting this problem (G.O.D
among others) have fallen by the wayside.  [Note-these comments
assume AAA games and publisher deals, I know you can have no crunch,
live free, and be quite profitable making card games, cell phone
titles, Java find-a-word games or whatever too]

--Moving past crunch--

There is hope for a 'less crunch' future for the industry as it (and
we) mature.

The companies that are still doing high quality products while
keeping good control of their schedules are typically innovating
between games - and reducing the risk to their shipping titles by
using known gameplay features and proven technologies.

Progressive organization and management (such as Matrix management,
etc) is allowing better cross-team application of resources and
talent and making more effective development teams.

Development on dedicated gaming platforms (consoles) is removing the
hardware compatability risk (believe me, having to test on those
3000 combinations and make allowances for the annoying differences
in video cards takes its toll) and improving the overall quality and
stability of game software.

And the rise of quality middleware is splitting the risk of engine
technology devleopment and gameplay/content devleopment (innovating
between games) - so every shop does not now have to be masters of
both the science and the art but can play to their strenghts.  So
there is even hope for the small shops.

Improvements in tools (and a smaller number of standard tools),
better content pipelines, and better asset management (another area
where game development is significantly different from IT
development) are improving productivity for game development.
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev