notes.adoc

   1 = Open Adventure Maintainer's Notes =
   2 by Eric S. Raymond
   3
   4 In which we explain what has been done to this code since Don Woods
   5 authorized us to ship it under an open-source license.  There's a
   6 separate link:history.html[history] describing how it came to us.
   7
   8 == Who we are ==
   9
  10 The principal maintainers of this code are Eric S. Raymond and Jason
  11 Ninneman.  Eric received Don Woods's encouragement to update and ship
  12 the game; Jason signed on early in the process to help. The assistance
  13 of Peje Nilsson in restructuring some particularly grotty gotos is
  14 gratefully acknowledged. Petr Voropaev contributed fuzz testing.
  15
  16 == Nomenclature ==
  17
  18 This project is called "Open Adventure" because it's not at all clear
  19 to number Adventure past 2.5 without misleading or causing
  20 collisions. Various of the non-mainline versions have claimed to be
  21 versions 3, 4, 5, 6, 7 and for all I know higher than that.  It seems
  22 best just to start a new numbering series while acknowledging the
  23 links back.
  24
  25 We have reverted to "advent" for the binary to avoid a name collision
  26 with the BSD Games version.
  27
  28 == Philosophy ==
  29
  30 Extreme care has been taken not to make changes that would alter the
  31 logic of the game as we received it from Don Woods.  By policy, all
  32 user-visible changes must be revertible with the -o (oldstyle) option.
  33
  34 It is a goal of this project to exactly preserve the *behavior* of
  35 430-point Adventure, but the implementation of it is fair game for
  36 improvement. In particular, we are concerned to move it to a form that
  37 is (a) readable, and (b) friendly to forward translation to future
  38 languages.  It has already survived a move from FORTRAN to C; a future
  39 as a Python or Go translation seems possible, even probable.
  40
  41 == Functional changes ==
  42
  43 By default, advent issues "> " as a command prompt.  This feature
  44 became common in many variants after the original 350-point version,
  45 but was never backported into Crowther & Woods's main line before now.
  46 The "-o" (oldstyle) version reverts the behavior.
  47
  48 A "seed" command has been added.  This is not intended for human use
  49 but as a way for game logs to set the PRNG (pseudorandom-number generator) so
  50 that random events (dwarf & pirate appearances, the bird's magic word)
  51 will be reproducible.
  52
  53 A -l command-line option has been added. When this is given (with a
  54 file path argument) each command entered will be logged to the
  55 specified file.  Additionally, a generated "seed" command will be put
  56 early in the file capturing the randomized start state of the PRNG
  57 so that replays of the log will be reproducible.
  58
  59 Using "seed" and -l, the distribution now includes a regression-test
  60 suite for the game.  Any log captured with -l (and thus containing
  61 a "seed" command) will replay reliably, including random events.
  62
  63 The adventure.text file is no longer required at runtime.  Instead, it
  64 is compiled at build time to a source module containing C structures,
  65 which is then linked to the advent binary. There is an adventure.yaml file
  66 as well; this is also compiled to C code, and will eventually replace
  67 adventure.text altogether.
  68
  69 The game-save format has changed.  This was done to simplify the
  70 FORTRAN-derived code that formerly implemented the save/restore
  71 functions; without C's fread(3)/fwrite() and structs it was
  72 necessarily pretty ugly by modern standards. Encryption and
  73 checksumming have been discarded - it's pointless to try
  74 tamper-proofing saves when everyone has the source code.
  75
  76 A -r command-line been added. When it is given (with a file path
  77 argument) it is functionally equivalent to a RESTORE command.
  78
  79 == Translation ==
  80
  81 The 2.5 code was a mechanical C translation of a FORTRAN original.
  82 There were gotos everywhere and the code was, though functional,
  83 ugly and quite unreadable.
  84
  85 Jason Ninneman and I have moved it to what is almost, but not quite,
  86 idiomatic modern C.  We refactored the right way, checking correctness
  87 against a comprehensive test suite that we built first and verified
  88 with coverage tools (we now have over 90% coverage, with the remaining
  89 confined to exception cases that are very difficult to reach). This is
  90 what you are running when you do "make check".
  91
  92 In the process we found and fixed a few minor bugs. Most notably, reading
  93 the relocated Witt's End sign in the endgame didn't work. Behavior when
  94 saying the giant's magic words outside his room wasn't quite right either.
  95
  96 The move to modern C entailed some structural changes.  The most
  97 important was the refactoring of over 350 gotos into if/loop/break
  98 structures.  We also abolished almost all shared globals; the main one
  99 left is a struct holding the game's saveable/restorable state.
 100
 101 The original code was greatly complicated by a kind of bit-packing
 102 that was performed because the FORTRAN it was written in had no string
 103 type.  Text from the adventure.text file was compiled into sequences
 104 of sixbit code points in a restricted character set, packed 5 to a
 105 32-bit word (it seems clear from the code that words were originally
 106 *6* chars each packed into a PDP-10 36-bit word).  A command noun or
 107 verb was one of these words, and what would be string operations in a
 108 more recent language were all done on sequences of these words.
 109
 110 We are still in the process of removing all this bit-packing cruft
 111 in favor of proper C strings.  C strings may be a weak and leaky
 112 abstraction, but this is one of the rare cases in which they are
 113 an obvious improvement over what they're displacing...
 114
 115 We have also conducted extensive fuzz testing on the game using
 116 afl (American Fuzzy Lop).  We've found and fixed some crashers in
 117 our new code (which occasionally uses malloc(3)) but none as yet
 118 in Don's old code (which didn't).
 119
 120 The code falls short of being fully modern C in the following
 121 ways:
 122
 123 * We have not attempted to translate the old code to pointer-based
 124   idioms (as opposed, in particular, to integer-based array indexing).
 125   We don't need whatever minor performance gains this might collect,
 126   and the choice to refrain will make forward translation into future
 127   languages easier.
 128
 129 * There are a few gotos left that resist restructuring; all are in the
 130   principal command interpreter function implementing its state
 131   machine.
 132
 133 * Linked lists (for objects at a location) are implemented using an array
 134   of link indices. This is a surviving FORTRANism that is quite unlike
 135   normal practice in C or any more modern language.  We have not tried
 136   to fix it because doing so would (a) be quite difficult, and (b)
 137   compromise forward-portability to other languages.
 138
 139 * Much of the code still uses FORTRAN-style uppercase names.
 140
 141 * The code still assumes one-origin array indexing.  Thus, arrays are
 142   a cell larger than they strictly need to be and cell 0 is unused.
 143
 144 * The code is still mostly typeless, slinging around machine longs
 145   like a FORTRAN or BCPL program.  Some (incomplete) effort has been made
 146   to introduce semantic types.
 147
 148 // end