Newsgroups: rec.arts.int-fiction
Path: nntp.gmd.de!newsserver.jvnc.net!raffles.technet.sg!nf1.iij.ad.jp!news.iij.ad.jp!tyo2.gate.nec!newssv2.tmg.nec!newssv1.ho.nec!jpgate.inoc.sj.nec.com!vivaldi.inoc.dl.nec.com!psinntp!psinntp!psinntp!howland.reston.ans.net!ixnews1.ix.netcom.com!netcom.com!librik
From: librik@netcom.com (David Librik)
Subject: Re: Adventure writing language
Message-ID: <librikDqGpBG.82y@netcom.com>
Organization: Icy Waters Underground, Inc.
References: <DqD4B2.Euo@cf.ac.uk> <4lltov$k79@nntp4.u.washington.edu> <4lm88g$pu1@news.ox.ac.uk> <DqF2IB.Kwz@cf.ac.uk> <4lp984$dp5@tribune.concentric.net>
Date: Fri, 26 Apr 1996 09:06:52 GMT
Lines: 132
Sender: librik@netcom15.netcom.com

Jmcgrew@cris.com (Jesse Mcgrew) writes:

>M Walker (M.S.Walker@cs.cf.ac.uk) wrote:
>[snip]
>: Yes, it is PAW as in the Spectrum (et al.) adventure writing system

>: For those who don't know it, you create a series of tables (Locations,
>: Messages etc.), and then Action Tables (Process and Response tables in
>: PAW) to tie them all together, along with the possible ways of invoking
>: the entries in the table.
>[examples snipped]

>From what you've said, it sounds a lot like LADS (programming/lads on GMD).
>In LADS, you define a table of rooms, objects, messages, implicit actions,
>and explicit actions. An explicit action would be like:

> UNLOCK DOOR INRX 3 HASX 6 X<>Y 4 5 MSGX 2 ELSE MSGX 1 .

This all looks very familiar; the original example of PAW (now deleted,
unfortunately) especially.  The Text Adventure System from The Alternate
Source had a similar format.

All of these derive directly from Scott Adams' adventure interpreter
coding system.  When "Pirate's Adventure" was published in the December
1980 BYTE, it led curious computerists to puzzle out just what those
pages of cryptic numbers meant, and to decode how Adams' adventure system
worked.  I was one of them, and I promptly spent a lot of enjoyable
programming time writing an adventure system of my own that cloned
Scott's.  And I was not the only one; indeed, many people with more
persistence than me apparently published theirs.  They all show their
unmistakable lineage.

The way Scott Adams managed to cram a whole adventure into a 16K machine
was with the following format:

Nouns -- numbered 1-254
Verbs -- numbered 1-254
Rooms -- numbered 1-254
Items -- numbered 1-254
Messages -- numbered 1-50, 100-255

An "action list" made up of 16-byte entries that looked like this
(each capitalized word is 1 byte, and will be explained below).

Noun#  Verb#
  5 copies of:  Operand ConditionCode	   <-- these are the CONDITIONS
  4 copies of:  ActionCode		   <-- these are the ACTIONS

The Noun# and Verb# are taken from the list of nouns and verbs.  This
particular entry in the "action list" will only be considered when the
player has typed the command with the specified Noun and Verb.

The ConditionCodes are numbers that correspond to particular "conditions" --
for instance, code #1 might be "IF THE PLAYER IS DEAD", condition #2
might be "IF THE PLAYER IS IN ROOM # x", condition #3 might be, "IF
THE PLAYER IS HOLDING ITEM # y".  The "x" or "y" -- the code for an item
or a room or whatever -- is stored as the Operand, which comes just before
the ConditionCode.  If the ConditionCode was 0 that meant "no test" --
remember, there had to be five Conditions, whether or not you needed them
all, in order to keep the entry 16 bytes long!

The ActionCodes describe actions which are taken if all the conditions
(described by the ConditionCodes) are true.  For instance, action #51
might be "KILL THE PLAYER", action #52 might be "MOVE TO ROOM # x",
action #53 might be "GIVE THE PLAYER ITEM # y".  The "x" or "y" here
also comes from the Operands back in the ConditionCodes -- since you
didn't usually have five conditions, you had a few bytes left over
to store Operands for Actions.  (Actions #1-50 and #100-255 just
printed the Messages with those code numbers.  Messages are the
things that the adventure says to the player ... like "THERE ARE JEWELS
ENCRUSTED ON THE GOLDEN CHEEZ WIZ.")

Anyway, it all comes together like this.  Suppose:
    The word "light" is verb #12
    The word "torch" is noun #4
    The "unlit cane torch" is item #49
    The "cigarette lighter" is item #20
    The "lit cane torch" is item #98
    The message "You light the torch.  It is now burning brightly." is #6.

    The pre-defined ConditionCode for "IF PLAYER IS HOLDING ITEM #x" is #2
	(abbreviated HOLD? in the explanation below)
    The pre-defined ActionCode for "EXCHANGE ITEMS #y AND #z" is #60.
    A place-holder ConditionCode or ActionCode (used to fill up space so
       everything's the right length) is #0.  (I abbreviate it as "Null".)

So:
   12              4
Verb-"light"  Noun-"torch"

   49         2      20     2         49         0       98     0    0    0
unlit-torch HOLD?  lighter HOLD?   unlit-torch Null  lit-torch Null Null Null

   60        6                0      0
Exchange  Print-Message#6    Null   Null

This line runs when you type verb 12 (light) and verb 4 (torch).  It checks
if you're holding item 49 (the unlit torch) and item 20 (the cig. lighter).
If so, it exchanges the unlit torch (49) with the lit torch (98), grabbing
those numbers out of the preceding Null conditions' opcodes, so that you're
now holding the lit torch.  Then it prints message #6 which tells you that
you lit the torch.

Cool, eh?  You've just encoded a whole lot of IF-THENs, variable assignments,
and printing in just 16 bytes.  Since practically all Adventure "structure"
consists of nothing but code like this, you can fit endless amounts of
game logic into very little space.

Any time you see design like this in an adventure-writing language, you
know it's a descendent of Scott Adams' system.

Getting a bit philosophical, you might say that the coding described above,
with its "action codes" and "condition codes," was a lot like the machine
language for a very weird and specialized computer chip!  The program that
interpreted the code, and therefore "ran" the adventure game, was called
an "adventure interpreter," and it could be seen as an *emulator* for the
imaginary, weird computer chip.  Most of the adventure development systems
based on this Scott Adams model were, therefore, *assemblers* which
translated a rather cryptic set of text abbreviations directly into the
ConditionCodes and ActionCodes.  My own project, which was never finished,
was to write an "adventure *compiler*" that could take a description in
a higher-level descriptive language and turn it into this "machine code."
Since I was 16 at the time and didn't know anything about compiler design,
I finally gave up after having to reinvent a whole lot of Parsing Theory!

Did you read all that?  Let's give a BIG CHEER for TADS and Inform and
all the rest of our fine easy-to-use modern tools!

- David Librik
librik@cs.Berkeley.edu

p.s. The sample ConditionCode's and ActionCode's that I gave are hypothetical.
