🚀 go-pugleaf

On Wed, 19 Aug 1998 17:35:21 GMT, sjan...@fasainteractive.com (Scott
Janssens) wrote:

>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

You've got a lot of valid points here.  However I must re-iterate that
you are missing the point.  Not to sound condescending but I've been
programming since the 70's.  I also spent most of my corporate career
rescuing projects that were YEARS behind scedule, so I'm well aware of
how costs/scedules can spiral out of control-if it werent for the HUGE
number of deadbeat/braindead programmers I wouldnt be where I am
today.  Before you take this personally, I am also a member of the
programming profession.  Just look at the AOJ fiasco.  The thing was 4
years into development and the thing was practicaly at the beginning
of the development cycle(when you consider how much longer it would
have taken to finish according to their most optimistic
projections-projections I might add that come from people that already
missed 7 hard deadlines.)  Everyone was slinging mud at Microprose for
canning the project but you can see by your above figures that even if
it was a mega-success it might not have been a money maker.  Some of
these Simtex guys come out here whining for sympathy after they're (at
least partly) responsible for the worst financial debacle in gaming
(and perhaps programming history).  Next time you go to get the
financing for your next project don't you think that the money-man is
considering if your project might turn into another AOJ disaster?
Sorry to go ballistic there for a second but I'm VERY aware of the
finances of programming-both in my everyday business and the gaming
industry.  I'm also aware of how your paymaster(producer, client,
etc), who often knows nothing about programming will re-write the
specs on your project requiring a complete restructuring of the code
when you are already 99% done.  These kind of guys should really have
more accidents.  I agree that people outside of the industry, even
programmers outside of the gaming industry often view the actual coder
as as the whold show when he is really a cog in the machine.  A
designer or project manager who succumbs to "feature creep"(constantly
chaning specs, etc) can absolutley doom a project.  What used to
constitute breakthroughs by a single guy are now breakthroughs by a
team.  Back to the original point-most coders feel as you do-it just
can't be done.  However if you just look at the gaming industry today
you see varying levels of performance between games of the same genre.
You often have two products that took the same amount of money to
produce yet one is clearly better coded than the other.  I'm sure that
the coders of the inferior work felt that THEY had gotton eveything
possible out of the machine but they were clearly wrong.  In the past,
there were huge, clearly visible  strides in programming techniques
because of the more static hardware aspect.  Today you can't achieve a
breakthrough with one inspired guy, you need 20 inspired guys(or at
least 1 inspired guy who can dominate the other 19).  Also with the
rapid hardware improvements, it may not be time/money prudent to
develop better programming techniques.   Things are moving so fast now
that a P400 might not even be the median computer in 18 months.  There
was once a lotus trick book that had hundreds of methods to get better
results/performance/features exploiting bugs(you might call them
undocumented features).  Today it might be cheaper to hand the guy a
faster computer than to teach him to use the tricks.