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.
  13
  14 == Nomenclature ==
  15
  16 This project is called "Open Adventure" because it's not at all clear
  17 to number Adventure past 2.5 without misleading or causing
  18 collisions. Various of the non-mainline versions have claimed to be
  19 versions 3, 4, 5, 6, 7 and for all I know higher than that.  It seems
  20 best just to start a new numbering series while acknowledging the
  21 links back.
  22
  23 We have reverted to "advent" for the binary to avoid a name collision
  24 with the BSD Games version.
  25
  26 == Philosophy ==
  27
  28 Extreme care has been taken not to make changes that would alter the
  29 logic of the game as we received it from Don Woods.  By policy, all
  30 user-visible changes must be revertible with the -o (oldstyle) option.
  31
  32 It is a goal of this project to exactly preserve the *behavior* of
  33 430-point Adventure, but the implementation of it is fair game for
  34 improvement. In particular, we are concerned to move it to a form that
  35 is (a) readable, and (b) friendly to forward translation to future
  36 languages.  It has already survived a move from FORTRAN to C; a future
  37 as a Python or Go translation seems possible, even probable.
  38
  39 == Functional changes ==
  40
  41 By default, advent issues "> " as a command prompt.  This feature
  42 became common in many variants after the original 350-point version,
  43 but was never backported into Crowther & Woods's main line before now.
  44 The "-o" (oldstyle) version reverts the behavior.
  45
  46 A "seed" command has been added.  This is not intended for human use
  47 but as a way for game logs to set the PRNG (pseudorandom-number generator) so
  48 that random events (dwarf & pirate appearances, the bird's magic word)
  49 will be reproducible.
  50
  51 A -l command-line option has been added. When this is given (with a
  52 file path argument) each command entered will be logged to the
  53 specified file.  Additionally, a generated "seed" command will be put
  54 early in the file capturing the randomized start state of the PRNG
  55 so that replays of the log will be reproducible.
  56
  57 Using "seed" and -l, the distribution now includes a regression-test
  58 suite for the game.  Any log captured with -l (and thus containing
  59 a "seed" command) will replay reliably, including random events.
  60
  61 The adventure.text file is no longer required at runtime.  Instead, it
  62 is compiled at build time to a source module containing C structures,
  63 which is then linked to the advent binary.
  64
  65 The game-save format has changed.  This was done to simplify
  66 FORTRAN-derived code that formerly implemented these functions;
  67 without C's fread(3)/fwrite() and structs it was necessarily pretty
  68 ugly by modern standards. Encryption and checksumming have been
  69 discarded - it's pointless to try tamper-proofing saves when everyone
  70 has the source code.
  71
  72 == Translation ==
  73
  74 The 2.5 code was a mechanical C translation of a FORTRAN original.
  75 There were gotos everywhere and the code was, though functional,
  76 ugly and quite unreadable.
  77
  78 Jason Ninneman and I have moved it to what is almost, but not quite,
  79 idiomatic modern C.  We refactored the right way, checking correctness
  80 against a comprehesive test suite that we built first and verified with
  81 coverage tools. This is what you are running when you do "make check".
  82
  83 This move entailed some structural changes.  The most important was
  84 the refactoring of 355 gotos into if/loop/break structures.  We
  85 also abolished almost all shared globals; the main one left is a
  86 struct holding the game's saveable/restorable state.
  87
  88 The original code was greatly complicated by a kind of bit-packing
  89 that was performed because the FORTRAN it was written in had no string
  90 type.  Text from the adventure.text file was compiled into sequences
  91 of sixbit code points in a restricted character set, packed 5 to a
  92 32-bit word (it seems clear from the code that words were originally
  93 *6* chars each packed into a PDP-10 36-bit word).  A command noun or
  94 verb was one of these words, and what would be string operations in a
  95 more recent language were all done on sequences of these words.
  96
  97 We are still in the process of removing all this bit-packing cruft
  98 in favor of proper C strings.  C strings may be a weak and leaky
  99 abstraction, but this is one of the rare cases in which they are
 100 an obvious improvement over what they're displacing...
 101
 102 The code falls a short of being fully modern C in the following
 103 ways:
 104
 105 * We have not attempted to translate the old code to pointer-based
 106   idioms (as opposed, in particular, to integer-based array indexing).
 107   We don't need whatever minor performance gains this might collect,
 108   and the choice to refrain will make forward translation into future
 109   languages easier.
 110
 111 * There are 19 gotos left that resist restructuring; all of these are
 112   in the principal command interpreter function implementing its state
 113   machine.  A 21st, a two-level loop breakout, is not reducible even
 114   in principle.
 115
 116 * Linked lists (for objects at a location) are implemented using an array
 117   of link indices. This is a surviving FORTRANism that is quite unlike
 118   normal practice in C or any more modern language.  We have not tried
 119   to fix it because doing so would (a) be quite difficult, and (b)
 120   compromise forward-portability to other languages.
 121
 122 * The code still has an unfortunately high density of magic numbers - in
 123   particular, numeric object and room IDs.
 124
 125 * The code is still mostly typeless, slinging around machine longs
 126   like a FORTRAN or BCPL program.  Some (incomplete) effort has been made
 127   to introduce semantic types.
 128
 129 // end