home *** CD-ROM | disk | FTP | other *** search
/ Atari FTP / ATARI_FTP_0693.zip / ATARI_FTP_0693 / Games / dinkum3a.zoo / readme < prev    next >
Text File  |  1993-02-10  |  5KB  |  85 lines
  1.                       Comments on Dinkum, Version 2.12                
  2.                               30 January 1993                            
  3.  
  4. I'm releasing this version of Dinkum sooner than I should because of
  5. the appearance of six bugs coupled with extensive revisions which I
  6. performed on Dinkum during the Christmas holidays.  The bugs are:
  7.  
  8. 1) If the player was chased by a monster for a long distance in the game and
  9. the player survived after killing the monster then for certain random initial
  10. configurations other monsters would have their memory locations changed. 
  11. These changes sometimes resulted in the pointers for the other monsters being
  12. pointed towards garbage causing an abnormal ending and core dump.  This bug
  13. is fixed but was very difficult to locate.  This bug effected ALL earlier
  14. public versions of Dinkum.
  15.  
  16. 2) If the player shot a movable object (non-monster) in Dinkum versions made
  17. after 1.27 then this would lead to an abnormal ending and core dump.  Version
  18. 1.27 did not have this bug. This bug has been fixed with the logic supporting
  19. the shooting of movable objects significantly improved.
  20.  
  21. 3) If the player shot off an ammunition clip, ejected it and then reloaded
  22. the clip then all of the ammunition would be "magicly" restored.  This bug
  23. did not occur if the clip still had some ammo left in it.  Goofy bugs of
  24. this sort are easy to fix but hard to find.  Thanks to Byron Rakitzis for
  25. discovering this bug and bug #2.  
  26.  
  27. 4) If the user put Dinkum into its privileged mode and used some of
  28. the privileged commands then a core dump could result for a special case.
  29. Thanks to Per-Anders Eriksson for discovering this bug.  The privileged
  30. mode is for maintenance and debugging use only and not recommended for
  31. people playing Dinkum for entertainment.  I'll explain in private e-mail
  32. the use of this mode to anyone who has won Dinkum in ordinary user mode and
  33. is interested in hacking on the game.
  34.  
  35. 5) There was a bad Ccp definition (I defined DINKUM.C instead of DINKUM)
  36. which kept Dinkum from compiling in certain environments reducing
  37. portability.  Thanks to Darryl O'Neill for discovering this bug.
  38.  
  39. 6) There is a bug in the C compiler used in Ultrix.  This bug caused
  40. Dinkum not to compile because structure pointers were used explicitly
  41. in function parameters.  The fix was suggested by Christopher M. Conway.
  42. This fix simply involved converting all structured pointer declarations
  43. over to typedefs.
  44.  
  45.                      --------- Revisions -----------
  46.  
  47. An important revision to Dinkum can be seen in the Makefile.  By
  48. de-commenting one line and deleting another, the user can have a prompt
  49. for Dinkum command inputs.  This improvement was suggested by Chris Herborth.
  50.  
  51. More than one person has complained about Dinkum's time out feature.  The
  52. argument made was Dinkum is often played on a window running in background
  53. with the user doing constructive work in foreground. Consequently it can
  54. be many minutes between moves resulting in the game often timing out. This
  55. leads to an interesting design problem because I want winners of Dinkum to
  56. have won on a uniform game (no advantages for people using special features
  57. like script files, etc.).  My solution is to go back to my trusty "data
  58. recorder".  If you start Dinkum with the "-s" switch then the game starts
  59. with a data recorder appearing as an object in the game.  If you take the data
  60. recorder and examine it then you'll find it now has an additional feature,
  61. viz. an orange button.  If you press the orange button then Dinkum's internal
  62. clock stops and no further play is possible.  The user is then presented
  63. with a yes/no question.  When the user says "yes" then the game resumes
  64. with the internal clock reset such that no time elapsed while the orange
  65. button was engaged.  The orange button is derived from a suggestion made
  66. by Christopher M. Conway.
  67.  
  68.                      --------- A Short Sermon -----------
  69.  
  70. I now have Dinkum revised into a form that is not overly embarrassing
  71. (unlike before).  Something I've discovered is that all of the stories they
  72. tell about the virtues of structured programming are absolutely true.  Dinkum
  73. though written in C, previously had a FORTRAN coding style with the resultant
  74. logic being so convoluted that further maintenance and debugging was almost
  75. impossible. In the process of getting Dinkum into a proper C form, I found
  76. many low level bugs and brought about many improvements.  The lesson which I
  77. have learned is if I'm programming in FORTRAN, BASIC, COBOL or any of the
  78. other old fashioned languages then I'm simply being stupid and punishing myself
  79. needlessly.  Six years ago I would have come up with all sorts of facile
  80. arguments why FORTRAN should be maintained but I now know these arguments are
  81. spurious.  If you're still fighting with FORTRAN then I urge you to learn from
  82. my experience and convert over to C.
  83.  
  84.                             Gary A. Allen, Jr.                           
  85.