X-Git-Url: https://jxself.org/git/?p=open-adventure.git;a=blobdiff_plain;f=notes.adoc;h=be36ddc6fba1203755ab21a2a750519ef478509d;hp=07602ec40b50a2101a02b842bee959c33c36d42f;hb=481d198d392dded279274bd4152c8a2c8891fe41;hpb=cad701f54d286efc911cff69d65a87f596802671 diff --git a/notes.adoc b/notes.adoc index 07602ec..be36ddc 100644 --- a/notes.adoc +++ b/notes.adoc @@ -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. +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,9 +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. +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 @@ -71,6 +91,9 @@ 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 a RESTORE command. + == Translation == The 2.5 code was a mechanical C translation of a FORTRAN original. @@ -80,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 88% coverage, with the remaining 12% -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 @@ -98,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: @@ -112,9 +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 of these - are in the principal command interpreter function implementing its - state machine. +* 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 @@ -122,13 +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 and room IDs. There are plans to fix this. - -* Much of the code still uses FORTRAN-style uppercase names. +* 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