Re: Program bugs and Game bugs

[Rubywand <rubywand@swbell.net>]

KFergason writes ...
> 
> My question for you is this:  Since apparently the problem is documented as
> an OS problem, what code in the game does he change?  The game
> programmer in this situation has nothing to fix.  IS there anything in the game
> he can change to fix this problem?
> 
> Kelly
>


     Consider the game Dungeon Master. It is a larger game with more
detailed action figures and more sound effects than Wolf3D. You can boot
the Dungeon Master diskette and play for hours; and, it does not crash
upon exiting.

     My reason for not answering, simply, "Yes" is that the DM example
just tells us what is possible given at least five persons who can
devote quite a lot of time to a project and can look forward to being
paid for their work.

     Sheppy, the main Wolf3D programmer, had some help for various
components like music, artwork, and play testing; and, Nathan helped
with some final fixes. Still, it seems that Sheppy was stuck with doing
nearly all of the program coding which puts things together so that you
get a nice, smooth 3-D display, find stuff where it's supposed to be,
and can have fun shooting bad guys.

     Getting one Mission selection screen to work right can take several
days. Besides this, your stuff has to fit in memory without squishing
INITs, drivers, patches, etc. and without getting squished. During
development, just keeping track of where what piece is on disk and what
version of a routine is the one that works are major tasks. And, Sheppy
was not going to be paid.

     Anyway, a project like Wolf3D is a _lot_ of work. If, with a
deadline closing in, you see a way to save time or memory by making a
possibly risky ToolBox CALL, you are, probably, going to do it.

     Is there another way beside the CALL to achieve whatever fix or
enhancement the CALL helps take care of? Sure, you can write the code
you need. The catch is that writing and debugging the code could be
pretty time-consuming.

     My guess is that to handle the whatever it was task via in-line
coding, what Sheppy needed was to wake up on February 1 and discover
that it was actually New Year's Day. Setting back the deadline may seem
like an easy alternative; but, really, it is not. When you work on a
project like Wolf3D you usually set and pass several deadlines.
Eventually, though, you set The Deadline and commit to it.

     What all of this boils down to is that, now, there may well be no
reasonably easy fix to the game. I do not know enough about the program
to say. Evidently, the OS patch takes care of the problem; but, this
means the game will continue to crash on quit a few systems for some
time to come.

     Fixing the game is best. After all of that work, it's something
Sheppy owes himself.



Rubywand