Re: Program bugs and Game bugs

[Rubywand <rubywand@swbell.net>]

DEVEN ATKINSON writes ...
>
> ....
> 
>   I encountered this same senerio at work.  I explained it to the customer
> this way:  If your car hits a pot hole and bottoms out, is it the fault
> of the car?  Should you run out and put stiffer shocks?  Or should you get
> the pot hole fixed?

     This is a very good analogy! Now, consider this: Suppose the pot
hole is marked with a flashing barrier sign reading "Pot Hole".

     Who is responsible when you swerve around the sign, THUNK! into the
pot hole, loose steering control, and end up crashing into a mailbox? 

     There is nothing wrong with your car-- i.e. the Syntax and Logic
aspects of your program code-- the car goes where you tell it to go.

     The street-- i.e the Operating System-- is drivable. Every day,
thousands of commuters in their cars-- programs executing under the OS--
traverse the street with no problem.

     The pothole-- i.e. the OS bug-- is avoidable.

     You are the one in control-- i.e. the Decision Making aspect of the
program.

     Swerving around the sign-- a CALL to SetTSPtr which may trigger the
bug-- is a decision _you_ make. If your car responds as it should-- the
Syntax and Logic are correct-- you car will go around the sign-- CALL
SetTSPtr is executed-- and there is a chance that you will hit the pot
hole-- OS bug-- lose control and crash-- system crash, Beep!


     Strictly speaking, a program which makes the CALLs you intend for
it to make, uses BCC, BCS, ... branches to make the expected decisions,
etc., is "bug-free". From what little I've seen of the program,
Wolf-3D's code is very 'clean' and easy to follow. It may well be
"bug-free". This, however, was never at issue.

     To say that "Wolf-3D has a bug" is _not_ the same as saying
"Wolf-3D's program is buggy".

    "The game Wolf-3D" is not the same as the Wolf-3D program. When we
talk about "the game Wolf-3D" we are talking about sounds coming through
speakers, displays on the monitor, response to KB and mouse controls,
etc., etc..

     Users (including programmers) can seldom know for certain whether
or not a game program performs its tasks correctly. To do this requires
knowing what specific tasks the game programmer wants the program to
accomplish together with a knowledge of which instructions the program
executes. If the program performs all of its instructions as intended,
the program is free of bugs whatever happens on the display monitor or
comes out through the speakers.

     On the other hand, users running the standard OS on a typical
system can often determine whether or not a game has major flaws because
"game" = the game's observable performance. If the programmer chooses to
have his/her program CALL a buggy OS routine and the game crashes, it is
quite proper to say that the "game has a bug". Programmer choices are an
embedded feature of any game.

     Wolf-3D crashes not because the program code contains a bug--
indeed, a bug which averts the intended CALL might avoid the crash! It
crashes because the programmer made a risky decision. The OS did not
grab him by the neck and force him to 'steer his car around the sign'.
There are always alternatives; one of which is to forget about whatever
feature the risky CALL permits.

     If you don't want your Game to have a bug, don't CALL one.



>   Perhaps the car builder should call and applogize to you because you
> hit a pothole.

     No. The driver should apologize to his/her passengers, stop blaming
the street, and be willing to admit that he/she made a mistake.


>   We are lucky to have W3D.

     Very definitely! Wolfenstein 3D is the best IIgs game in many
years. I've had loads of fun playing.


>  We are even luckier to have GUPP ....

     I know very little about GUPP. GUPP does appear to have great
potential. A critical factor is the extent to which GUPP (or any other
set of user-generated OS patches) is adopted by users. This, in turn,
will depend upon the willingness of developers to document the new
patches and how well the patches perform once installed.



> You should be thanking these people

     Thank you, Eric.
     Thank you, Nathan.


> instead of ripping them.
>

     I shall make an effort to tone down my ferocious ripping.


Rubywand