Coverage -- giant words
[open-adventure.git] / notes.adoc
index 067ddf16a69a316ca67efe6aa7847925d3ed5218..be36ddc6fba1203755ab21a2a750519ef478509d 100644 (file)
@@ -11,7 +11,8 @@ The principal maintainers of this code are Eric S. Raymond and Jason
 Ninneman.  Eric received Don Woods's encouragement to update and ship
 the game; Jason signed on early in the process to help. The assistance
 of Peje Nilsson in restructuring some particularly grotty gotos is
-gratefully acknowledged. Petr Voropaev contributed fuzz testing.
+gratefully acknowledged. Petr Voropaev contributed fuzz testing. Aaron
+Traas did a lot of painstaking work to improve test coverage.
 
 == Nomenclature ==
 
@@ -28,22 +29,39 @@ with the BSD Games version.
 == Philosophy ==
 
 Extreme care has been taken not to make changes that would alter the
-logic of the game as we received it from Don Woods.  By policy, all
-user-visible changes must be revertible with the -o (oldstyle) option.
+logic of the game as we received it from Don Woods, except to fix
+glitches that were clearly bugs.  By policy, all user-visible
+changes must be revertible with the -o (oldstyle) option.
 
-It is a goal of this project to exactly preserve the *behavior* of
-430-point Adventure, but the implementation of it is fair game for
-improvement. In particular, we are concerned to move it to a form that
-is (a) readable, and (b) friendly to forward translation to future
-languages.  It has already survived a move from FORTRAN to C; a future
-as a Python or Go translation seems possible, even probable.
+It is a goal of this project to exactly preserve the *intended
+behavior* of 430-point Adventure, but the implementation of it is fair
+game for improvement. In particular, we are concerned to move it to a
+form that is (a) readable, and (b) friendly to forward translation to
+future languages.  It has already survived a move from FORTRAN to C; a
+future as a Python or Go translation seems possible, even probable.
 
 == Functional changes ==
 
+Bug fixes:
+
+* Reading the relocated Witt's End sign in the endgame didn't work right.
+
+* Behavior when saying the giant's magic words outside his room wasn't
+  quite corrected - the game responded as though the player were in
+  the room.
+* Attempting to extinguish an unlit urn caused it to lose its oil.
+
 By default, advent issues "> " as a command prompt.  This feature
 became common in many variants after the original 350-point version,
 but was never backported into Crowther & Woods's main line before now.
-The "-o" (oldstyle) version reverts the behavior.
+The "-o" (oldstyle) option reverts the behavior.
+
+There is a set of standard one-letter command aliases conventional in modern
+text adventure games; 'l' and 'x'; for 'look' (or 'examine'), 'z' to do nothing
+for a turn, 'i' for 'inventory', 'g' for 'get', and 'd' for 'drop'.  The 'd'
+alias collides with 'd' for 'down', but the others have been implemented.
+The "-o" (oldstyle) option disables them.
 
 A "seed" command has been added.  This is not intended for human use
 but as a way for game logs to set the PRNG (pseudorandom-number generator) so
@@ -60,11 +78,11 @@ Using "seed" and -l, the distribution now includes a regression-test
 suite for the game.  Any log captured with -l (and thus containing
 a "seed" command) will replay reliably, including random events.
 
-The adventure.text file is no longer required at runtime.  Instead, it
-is compiled at build time to a source module containing C structures,
-which is then linked to the advent binary. There is an adventure.yaml file
-as well; this is also compiled to C code, and will eventually replace
-adventure.text altogether.
+The adventure.text file is no longer required at runtime.  Instead, an
+adventure.yaml file is compiled at build time to a source module
+containing C structures, which is then linked to the advent
+binary.  The YAML is drastically easier to read and edit than
+the old ad-hoc format of adventure.txt.
 
 The game-save format has changed.  This was done to simplify the
 FORTRAN-derived code that formerly implemented the save/restore
@@ -73,8 +91,8 @@ necessarily pretty ugly by modern standards. Encryption and
 checksumming have been discarded - it's pointless to try
 tamper-proofing saves when everyone has the source code.
 
-A -r command-line been added. When it is given (with a file
-path argument) it is functionally equivalent to RESTORE command.
+A -r command-line been added. When it is given (with a file path
+argument) it is functionally equivalent to a RESTORE command.
 
 == Translation ==
 
@@ -85,14 +103,14 @@ ugly and quite unreadable.
 Jason Ninneman and I have moved it to what is almost, but not quite,
 idiomatic modern C.  We refactored the right way, checking correctness
 against a comprehensive test suite that we built first and verified
-with coverage tools (we have over 90% coverage, with the remaining
-confined to exception cases that are difficult to reach). This is
+with coverage tools (we have over 95% coverage, with the remaining
+confined to exception cases that are very difficult to reach). This is
 what you are running when you do "make check".
 
-This move entailed some structural changes.  The most important was
-the refactoring of over 350 gotos into if/loop/break structures.  We
-also abolished almost all shared globals; the main one left is a
-struct holding the game's saveable/restorable state.
+The move to modern C entailed some structural changes.  The most
+important was the refactoring of over 350 gotos into if/loop/break
+structures.  We also abolished almost all shared globals; the main one
+left is a struct holding the game's saveable/restorable state.
 
 The original code was greatly complicated by a kind of bit-packing
 that was performed because the FORTRAN it was written in had no string
@@ -103,10 +121,15 @@ of sixbit code points in a restricted character set, packed 5 to a
 verb was one of these words, and what would be string operations in a
 more recent language were all done on sequences of these words.
 
-We are still in the process of removing all this bit-packing cruft
-in favor of proper C strings.  C strings may be a weak and leaky
-abstraction, but this is one of the rare cases in which they are
-an obvious improvement over what they're displacing... 
+We have removed all this bit-packing cruft in favor of proper C
+strings.  C strings may be a weak and leaky abstraction, but this is
+one of the rare cases in which they are an obvious improvement over
+what they're displacing...
+
+We have also conducted extensive fuzz testing on the game using
+afl (American Fuzzy Lop).  We've found and fixed some crashers in
+our new code (which occasionally uses malloc(3)), but none as yet
+in Don's old code (which didn't).
 
 The code falls short of being fully modern C in the following
 ways:
@@ -117,10 +140,9 @@ ways:
   and the choice to refrain will make forward translation into future
   languages easier.
 
-* There are a few gotos left that resist restructuring; all but of these
-  are in the principal command interpreter function implementing its
-  state machine. the remaining one is a truly mysterious artficat in
-  the player-movement code.
+* There are a few gotos left that resist restructuring; all are in the
+  principal command interpreter function implementing its state
+  machine.
 
 * Linked lists (for objects at a location) are implemented using an array
   of link indices. This is a surviving FORTRANism that is quite unlike
@@ -128,16 +150,18 @@ ways:
   to fix it because doing so would (a) be quite difficult, and (b)
   compromise forward-portability to other languages.
 
-* The code still has an unfortunately high density of magic numbers - in
-  particular, numeric object IDs.  There are plans to fix this.
-
-* Much of the code still uses FORTRAN-style uppercase names.
-
-* The code still assumes one-origin array indexing.  Thus, arrays are
-  a cell larger than they strictly need to be and cell 0 is unused.
+* Much of the code still assumes one-origin array indexing.  Thus,
+  arrays are a cell larger than they strictly need to be and cell 0 is
+  unused.
 
 * The code is still mostly typeless, slinging around machine longs
   like a FORTRAN or BCPL program.  Some (incomplete) effort has been made
   to introduce semantic types.
 
+We have made exactly one minor architectural change.  In addition to the
+old code's per-object state-description messages, we now have a per-object
+message series for state *changes*.  This makes it possible to pull a fair
+amount of text out of the arbitrary-messages list and associate those
+mesages with the objects that conceptually own them.
+
 // end