[MUD-Dev] Crunch time

[Amanda Walker]

On Wednesday, July 30, 2003, at 11:47  PM, J C Lawrence wrote:

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

I strongly disagree.

This is *exactly* the situation in "big software" as well.  Every
project has requirement shifts, technology changes, and disruptive
developments in the course of its progress.  The game industry is in
no way unique in this respect, and its internal perception that is
makes for a large blind spot.

An commercial game, particularly a large MMO game, *is* a large IT
project.  If you look at game post-mortems, where do games fall
down?

Risk management.  "Gotchas" rear up at "final integration" time and
bite everyone in the posterior.  Planning doesn't mean figuring
everything out in advance.  It means being able to measure, assess,
and respond effectively to changes that occur during the project,
and taking that into account from the get-go.

> and so you go into crunch mode so you can ship the bloody thing
> before the background technology changes so much that not
> continuing to play catch-up was stupid.

Just like in any other part of the industry.  Game technology does
not advance at a speed any faster than the rest.  Truly.

> Whaddya want, nice predictable technology evolution cycles or
> something?

Not at all.  In fact, what some of us want is the understanding that
there *will* be disruption, assessments of where the risks are,
strategies for dropping risky avenues *early*, and so on.  Good
technology planning means *not* making too many assumptions, and
revisiting them often.

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