[MUD-Dev] Crunch time

Ben Tolputt bjt at pmp.com.au
Thu Jul 31 15:31:59 CEST 2003


I should warn the reader that this post touches on one of my
'soapbox' topics - as such, I may sound a little preachy :) And JC -
I'm not picking on you - it's just your post triggered the thought
processes...

On Thursday, 31 July 2003
J C Lawrence <claw at kanga.nu>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.

But it is possible, and not only that - but can often be quite
successful. For example, 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 think that had it
been released in the present it would still have been a success
(though maybe not to the degree it has enjoyed). There are other
games where the technology was not 'up-to-date' and still the
projects were a success - Diablo 2 and Baldurs Gate (with
expansions) to pick just two examples.

The reason I attribute to these successes is the 'focus' of the
project. In the above examples - the designers KNEW they weren't
going to sell the game on the 'technology factor', and as such
concentrated on the other aspects of a successful game. The reason
the game industry (as a whole) is stuck in this 'technology
development crunch' is, in my opinion, because technology focus is
an easy out. It is easy to see when/where it fails, it is relatively
easy (for us developers) to fix or nerf before release, and more
importantly - it is easier to market. It is easier to market because
there is ALWAYS going to be a technology improvement by the time the
next product comes out. Gameplay may be very similar to the previous
product - but the graphics are nicer.

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

This is primarily a myth associated with my point above. The major
thing that changes between the "requirements" of current MMORPG's is
interface, feature-set, & gameplay. Interface will remain a focus of
many developers because of the technology focus. Features in each
game expand, but usually in a linear fashion (there is a reason
people complain about MMORPG's being "just another
EverQuest"). Which brings me to gameplay. The hardest area in game
development to innovate and perfect. Is it no wonder that developers
focus on the other two. However, while improving the
interface/graphics is a no brainer (relatively speaking), we've all
seen issues with adding features without considering the affect on
gameplay!

> Is it really all that bad and chaotic?  No.  It just tries to be
> fairly aggressively, and there are strong forces encouraging it.
> Strong forces that you >need< to regularly give in to, to produce
> the product quality that is required.  Feature and technology
> creep during a product development cycle is s simple fact of life
> that you live with and try to manage reasonably.  And it is a
> race.  At some point you start drawing lines in the sand and
> saying,

>   "If we don't stop here we're going to be forever chasing the
>   next Great Thing!"

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

The development cycle isn't the problem - it is the expectations of
publishers, developers, & designers. We (yes, myself included) tend
to think that the next 'leap' in online gaming will be a
technological one. But as can be seen - technology isn't the
maker/breaker of games - it is the gameplay. Good gameplay CAN be
locked in, known, and planned for. There is technology we can use to
implement a decent (if not the latest) graphic interfaces, there is
technology available for networking, database management and so
on. If we as developers can let go of our "not built here" attitudes
and focus on what is really important we could mature to at least
the level of business software development (which isn't all it's
made out to be either!). Good business software development houses
focus on the problem first and use the best tools given the
requirements. Game developers tend to ignore the tools they have
because they beleive 'new tech' is a requirement. I personally don't
think so.

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

That would be nice. Where do I sign up? ;)

B.J.Tolputt

P.S. Matt Mihaly - are you receiving my emails?
_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the mud-dev-archive mailing list