🚀 go-pugleaf

On Wed, 19 Aug 1998 06:12:49 GMT, sum...@mediaone.net wrote:


>Scott, I think you're not getting the main focus of the post.  In
>early computer gaming, machines were pretty static, as opposed to
>being almost obsolete withing 12 months.  I once made a personal rule
>that I wouldn't upgrade unless I could increase my processing power
>300%, which currently means less than every 12 months, especially when
>you consider things like graphics accellerators,, increased ram, DVD
>drives, high speed CD's, etc, etc, in addition to the rapid increase
>in CPU power.  Ulitma 2, 3, and 4 were all designed to run on the same
>machine, yet U3 covered 20 times the space of U2, and U4 covered 20
>times the span of U3.  SSI had a game on the Atari ST which formated
>the  game disks for MORE than the drive was rated for.  Having static
>technology means you work with the same languages, within the same
>structures for a much longer period of time-giving increased
>familarity-meaning increased proficiency.  At the time it came out,
>Doom was a marvel of technology because it gave a framerate no other
>program could match, AT THAT LEVEL OF TECHNOLOGY.  If you examine
>Origin's releases of the last 5 years, you'll find a consistant number
>were virtually unplayable on anything but absolute top of the line
>machines of the period.  It really irks you to get home and find out
>that the over-hyped game you brought home runs like frozen tar even
>tho your machine is over the minimum requirements.  If you did the
>final version of Mechwarrior 2, I'd have to congratulate you on
>getting it out the door as I heard it was re-started practicly from
>scratch only a couple months before the deadline.  Given the above I
>would expect more than a couple nights to go past 3:00 in the morning.
>However I'd expect that you're a better programmer several years later
>than you were then-thus given the same resources you'd be able to do
>it better now than then.  Going back to Doom, this game was as much an
>advance in coding efficiency as game design.  Had technology remained
>the same you'd be seeing a lot fewer first person shooters but program
>quality would still have advanced(albeit slower).   You'll have to
>admit that as long as programmers EXPECT/RELY ON technology increases,
>there's no real pressure to tighten the code(and I mean find something
>really revolutionary that surpases all previous records at the same
>technology).

I'm going to try desperately not to sound condescending here, believe
me it's not my intent.  I thought this way before I started working in
the industry.  

It's the programmers job to look at the design doc and say it'll take
this minimum to do these things, and these other things aren't even
possible with a cray.  A lot of games are coming out now that require
3d acceleration, but those calls are made by the producers and
designers, not the programmers.  When you say that programmers RELY on
the latest hardware technology you are incorrect.  The way it
generally happens is that a new CPU comes out that has new
capabilities or a new video board comes out that can do more things,
the designers and producers see these and say "Wow, with this we can
do this, that and the other".  Where before it was hardware driven it
could not be done and still get a playable framerate within a
reasonable timeframe.  This is where the business comes in.  High
fidelity games are incredibly expensive to make (around a million
dollars or more).  The longer it takes to make a game, the more
expensive it becomes.  The more expensive it is the more copies you
need to sell.  If you don't know the industry well, games are
considered a "hit" if you sell 150,000 copies.  Very few games sell
more than 200,000 and only a handful reach 500,000.  To recoup costs a
game needs to sell usually around 100,000 copies for an average
development cycle of 18 months.  The point is, while some things may
be possible to do without the latest hardware, it will take time to
develope the tricks to do it (which usually involves assembly and
doubles the testing time).  You're looking at an increase from 6
months to a year (you have to include the time to thouroughly test not
just the time it takes to code it).  Now the game needs to sell nearly
double the projected amount, and by the time it hits the shelves, most
people will have the hardware anyway.  Again, that's a call that's
made by the producer, not the programmer.

Everyone outside the industry imagines the programmer as the top of
the pyramid.  To some extent the buck does stop with us, either we can
code it or we can't.  At the top of the pyramid sits the producer who
wields supreme power.  He can change any part of the design and
hardware specs at will.  below him are the designer(s) who create the
game for the programmers to code.  As I programmer I spend my time
doing the bidding of the designers and producer.  I do have a little
say, I can make suggestions if I feel something isn't right with a
particular part of the design and the people who make the descisions
may or may not agree with me.  It's my job to make the game be able to
run on as many machines as possible, but if the producer says, 3d
acceleration only, then I have no say in that.   My job then is to
push that 3d card to it's limits.

We do work more than a couple late nights.  The last 2 - 4 months are
generally known as "Crunch Time".  This is the point when the game
cames together and the designers make all their last minute changes.
Naturally this plays havoc with the code.  Generally, the programmers
will work 80+ hour work weeks to implement the design changes, and
killing bugs, desperately trying to stay on schedule.  (Incidentally,
this is when the unsung heroes of the industry are working: the
testing department.)  Why do we do this?  It's a labor of love.  It's
frustrating and agrivating while you're going through it.  It gets to
the point where you start to envy the fry boy at McDonald's (I'm not
joking, ok maybe a little).  Neil Gaiman once said this about writing
but it's exactly how I feel about doing games, "I love having written,
and I love that period just before I write, but I hate the actual
writing part."


Scott Janssens
sjan...@fasainteractive.com