[MUD-Dev] Crunch time

[Sean Kelly]

Mark Terrano (XBOX) wrote:
> Amanda Walker wrote:

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

An excellent point.  And one that made me stop to think.  But while
this polishing may be necessary, it should not require any
fundamental changes to the product itself.  Certain functions may be
tweaked or even removed entirely, but a solid code design should be
able to handle these issues with a minimum of time and fuss.

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

My mother used to be a painter.  She is a perfectionist.  This
weekend my grandmother told me a story of my mother when she was in
college... my mother was working on a painting meant to be a gift
for my grandmother, and was characteristically obsessive about how
it looked. She'd continually assess it, scrape off any parts she
didn't like and do them over.  Today, 40 years later, that painting
is hanging unfinished on my grandmother's wall--one corner is still
scraped clean.

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

This is no different than business software design, especially in
the IT world.  It's quite common for a feature request to come just
a few days before beta.

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

But was it *necessary* that they involve crunch time?

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

For some, perhaps.  But I like to be able to go home to my wife at
6pm and have my weekends free.  It's been a longstanding rule of
mine that if I have to stay past quitting time at work then I'm not
doing my job properly.  This is a pretty strong statement, but I've
only had a few instances where I'd say this is not true.  Though
perhaps this is more a demonstration of my priorities and the reason
why I'm not in game development.

Sean Kelly
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev