[MUD-Dev] Crunch time

[Mark 'Kamikaze' Hughes]

Wed, Jul 30, 2003 at 11:47:27PM -0400 in <29127.1059623247 at kanga.nu>,
J C Lawrence <claw at kanga.nu> spake:
> On Wed, 30 Jul 2003 09:13:00 -0400
> Yannick Jean <Yannick.Jean at meq.gouv.qc.ca>  wrote:

>>  The main reasons why the gaming industry is such a mess when it
>>  comes to managing large project is that it's still employing
>>  mostly geeks, in both high or low positions. Geeks, great as
>>  they are for working days and night for your project, are
>>  notoriously atrocious at planning and keeping tight
>>  schedule. Give me a ruthless, cold-blooded, project manager and
>>  a full staff of "8 to 5" workers who got a life and a family at
>>  home and I'll give you MMORPG on time, on budget and with a
>>  stable codebase.

> A large element is how well the problem space is known before
> hand, as well as how well defined it is.  In the game arena both
> tend to be rapidly shifting sands well into the development
> process.  You're inventing the field, raw CS-work, as you go
> along, _and_ and a result defining the game definition as a
> product of the capabilities you've just invented.  If you attempt
> to refute that fact and pick your absolutes early in the process
> you end up shipping a game using three to five year old technology
> -- something the market doesn't tend to relish.

> This is rather different than most business software development
> where the field and the technologies used as well developed, well
> explored, and well known.

That is very much not the case, in my experience.  In over a decade
of freelancing, I've worked on maybe two business projects which
were known quantities.  You almost always have to do true innovation
and hard research and design work.  If anything, it's more difficult
than games, more experimental and technology-driven.  Graphics cards
are not the only form of technology, though I'm sure there are
people who'd disagree with that ("No, no, there's sound cards, too!"
<sigh> ).

Games don't have to meet prior customer requirements, as long as
they're fun when released, so, sure, you *can* develop them in any
direction you like to take advantage of the technology.  And if you
do that, if you don't specify and plan up front, you will forever be
chasing the next new tech or random game design idea.  That's not a
virtue, that's bad planning.  Business software is developed to
difficult or apparently impossible customer requirements, which you
then have to make work.

There's a very good reason why I write games for fun, rather than
writing, say, a distributed document storage, editing, and
conversion system.

Yannick hit the nail on the head.  Bad management and the
willingness of geeks, especially the naive twenty-somethings who
mostly work in the games industry, are to blame.

True horror story time:

  The year I spent in the commercial games industry convinced me of
  just how bad and incompetent games management is.  There was no
  planning, there was no organization, there were no specifications;
  the design document was 300+ pages long and yet useless to us, a
  mere brochure to attract the VC.  The game design changed,
  sometimes radically, from month to month on the whims of the lead
  developer.

  In a routine week, you were expected to put in 50-60 hours.
  During the three crunch periods I experienced--the VC demo, the
  alpha-test, and the beta--you were expected to put in at least 80
  hours per week, and got called a slacker if you were short of 100;
  hours were tracked and shown on a corkboard, so everyone knew who
  was "slacking".  I finally quit during the beta crunch because it
  was killing me, I was sick of eating pizza, and I wanted to see my
  girlfriend once in a while, maybe even spend a whole weekend with
  her.  I was the only person there except for the secretary who
  *had* a relationship, and I was considered a "wuss" for bitching
  about the long hours and for trying to have a life.

That's not technology-driven.  That's not necessary.  That's
incompetence, plain and simple, and it's perfectly typical
incompetence for the games industry.

I've talked to a lot of burned-out games developers since then, and
heard identical stories from them, so this was not a one-off bad
experience.  This is how most, maybe all, games companies are
mismanaged.

IBM has done statistical research on their developers which showed
that the optimum level of work is 6 hours per day; if you try to get
more productive work than that out of a developer, their work
quality decreases, and you get *less* total productivity.  Which
explains a lot about why games suck so much these days...

Staying up all day and night working on a project doesn't make you
more macho (if anything, it makes you a eunuch), and doesn't make
the product better.  The developers who are doing it right are the
ones who can go home every night and have a personal life, still get
out their product on time and under budget, and not coincidentally,
get paid twice as much as game developers.  Failure to do so is just
bad planning.

--
 <a href="http://kuoi.asui.uidaho.edu/~kamikaze/"> Mark Hughes </a>
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev