

And now for a few words from our sponsor...

Elves '87 is a Christmas text adventure written using David Betz's ADVSYS
Version 1.2.  Many thanks to David for all the work that went into ADVSYS,
I think now that ELVES is finished we have some appreciation for the amount
of effort required.  We lost count at 600 hours+ of programming time that
went into ELVES '87, not to mention several trips to the North Pole and to the
local malls to check the facts with the old elf himself.

Elves '87 is actually the second adventure we've done with ADVSYS.   The
first, (known as just ELVES) was done with the original version of ADVSYS
and the original runtime package which David provided at the time.  Well
Christmas '86 came and went and most of what we tried to do in ELVES had
flopped.  It turned out that about all we could get ADVSYS to do was give
us room descriptions, allow us to pick up objects and run around the
adventure.  This was pretty boring and we nearly gave up on ADVSYS.  We
started looking around for another method of producing text adventures.  I
even went so far as to consider writing something totally from scratch using
Modula-2.  The thought of writing my own parser scared the daylights out of
me.  So Marlene and I kept looking.  We played some with EAMON but found it
lacked any real substance.  We kept thinking of the potential of ADVSYS.  Then
we came across Version 1.2 (advsys) and I tried again to improve on the
original ELVES.  I still found the documentation and the runtime package sadly
lacking.  ELVES remained essentially a cute little 'joke' for our local users
group to chuckle over.

   It wasn't until two things happened that we decided to take another crack
at it.  First in April I found ADVRUN.ARC on a Citadel BBS in Minnesota.  I do
a bit of long distance (very long distance from Halifax) modeming and had been
watching for signs of ADVSYS life out there.  ADVRUN.ARC contained a more
advanced runtime package and a very simple sample adventure.  In May, David's
article appeared in BYTE magazine which helped to lift some of the fog
surrounding ADVSYS.  We had the tools to rebuild ELVES.  We considered ourselves
armed and dangerous and decided to re-write the ADVRUN runtime package.  The
accompanying arc file contains our version of the runtime code along with
full sources for ELVES.  Files with the .BOA extension (BOA stands for Burnt
Out Adventurers) are the more generic runtime files with verb and actions, etc.
.ELV files are those specific to ELVES containing object descriptions.

   In August ELVES '87 was born.  We set about in earnest to re-write our
original Christmas adventure.  All went well until about October.  We hit the
limit of the ADVSYS compiler.  ARGH!  Too many actions!  OK, no problem we
said, we'll just have to re-write it, we've got time...  Two weeks later the
re-write was done only to hit the compiler limit AGAIN.  This time in the 
DATA department.  I was ready to throw in the towel.  I sulked for a weekend
and then hit upon the idea of recycling objects within the adventure.  I
created a new concept of FLOORS in the game.  Floor 1 would be all the rooms
and objects at the North Pole.  Floor 2 would be all the South Pole parts.
We even recycled Frosty The Snowman into a Penguin.  Frosty becomes Percival
Penguin depending on where you are in the game.  Percival has a completely
different personality and keeps track of his inventory separately from Frosty.
By recycling objects we were able to greatly reduce the load on the compiler.
The FLOORS concept makes liberal use of SETP to modify objects relative to
which floor of the adventure you are on.  Percival/Frosty is an indepently
moving Actor.  The only limit to his movement is that he has to stay on
one floor.  I've numbered FLOORS 1 2 4 8 16 etc, although only 1 and 2 are
used in ELVES '87.

    My only real regret now that ELVES '87 is finished is that I didn't comment
the source code.  Some of it is pretty obvious but the XLISPish brackets
can make for some pretty odd looking code.

 (If(I(never(see)another)(bracket))again)(It will)(be((too)soon))

As we were writing ELVES it never crossed our minds that someone else might
actually be interested in our source code.  Also, the addition of the FLOORS
concept half way through writing the adventure really messed up that neat and
tidy modularity I was trying to maintain in the sources.  Bits and pieces of
code were moved and shoved all over the place.  At three in the morning (which
often was the case) if it runs without crashing, who cares if the code is
commented.

My biggest frustrations with ADVSYS came from three areas.  I found the ADVSYS
docs to be very sketchy.  It's easy once you know how, but in the beginning
the docs weren't much use.  The BYTE article really helped there.  Second
frustration was from the inability of the compiler to interpret long complex
statements.  No error gets generated, it's just that the adventure doesn't work
correctly.  After hours of examining the code, I finally broke the complex
statement into two simpler statements and everything worked 100%.  Moral of
that story is KISS (Keep It Simple Stupid).  Third frustration was just in
the overall limits on the compiler.  As I said, we hit the limit for ACTIONS
and DATA on more than one occasion.  In the very end we stripped ELVES '87 down
to the point where we couldn't even add one more SYNOMYM.  Perhaps my coding
is just really sloppy.  If anyone can show me a way/s to cut it down some
I'd been very happy.  If you browse through the source code you'll find a few
items which were commented out at the last minute due to space restrictions.
At the very last minute as were preparing the finishing touches we accidentally
created a minor bug which we didn't take time to fix.  There is an error in the
calculation of the total weight an actor is carrying.  You may find that you
have to drop more items than you would think normally necessary in order to 
pick up large items.  This should only be a minor annoyance and will not affect
successful completion of the game.  Several other minor bugs in the original
ARC'd release of ELVES '87 at Christmas time have been corrected in this version
of the sources.  We haven't looked for the WEIGHT bug.  If you find it please
let me know and I'll fix it at my end.  In the meantime we're putting ELVES
behind us and are planning on re-writing the runtime package to make the code
tighter and to better facilitate FLOORS and object recycling.  We are already
doing research for the next BOA! adventure.

What I'd like to see in upcoming versions of ADVSYS would be:
 
 1.  Higher limits on data and actions for the compiler or alternatively a
        way to call another adventure file from within the current adventure.
        I don't think this is as far fetched as it sounds if the second file
        was written in such a manner as to be compatible with the first.  I 
        very well could be totally out to lunch on this last part.  I would
        think it would all depend on exactly how ADVSYS keeps track of
        everything.  You most likely would have to write out the status of 
        Part A to some kind of temporary data file. Probably just easier to 
        expand the compiler limits.
        
 2.  An external PEXEC call (on the Atari ST version, don't know what you call
        it in MSDOS Land)  which could be used for possibly a graphics loader
        or even call another game from within ADVSYS.  Picture this... You
        enter the Arcade room in StarShip Columbus, instead of playing
        Murray, you grab for your joystick and play a game of Space Invaders.
        Of course we'll need a pipeline open from the outside routine to pass
        a parameter back to the ADVSYS calling routine.  How about a system
        variable which we can poll for the result of the outside call?  I'd
        even settle for the ability to run a graphics loader and be able to
        create text/graphic adventures.  (Alas, I am not a C programmer or
        I'd try to add this myself.  I use Modula-2, GFA Basic and Assempro)
        I'm not asking for a loader of course, as this is very machine/
        resolution specific.  I'll write the loader, etc, I just need to be
        able to make an outside call with parameters passed to and from ADVSYS
        and the routine being called.  Possible parameters passed to the outside
        routine could be the name of a picture file to load, the player's
        current score, health status, etc.  Parameters passed back to ADVSYS
        could include error messages (File not found, etc), a score from an
        outside game of blackjack, etc....

3.  In ELVES '87 we had a @#$# of a time creating output which might look like
        this...
                            _____________________
                           |                     |
                           |    Text Goes Here   |
                           |_____________________|

        In the end we had to resort to....

............................................................................
............................_____________________...........................
...........................|.....................|..........................
...........................|....Text.Goes.Here...|..........................
...........................|_____________________|..........................
............................................................................

     and call it a piece of "lined note paper".   This was the more generic
way of doing it as ADVSYS takes repetitions of white spaces and compresses
them into a single space.  Since we thought ELVES '87 was to be aimed only at
our local ATARI user's group we resorted to VT52 control codes for direct
cursor addressing and clearing the screen.  VT52 codes were used in the diary,
for the "It's too dark to see" routine and the clear screen at the end of
the penguin map.  While it would have been possible to use control codes, we
used the ...... method above for the penguin map as it was too complex and 
would have required far too much effort to direct cursor address that much
information onto the screen..  

     I'd like to see a way of inputting literal text strings and have them
reproduced verbatim including all white space characters.  I realize that this
negates the ability of ADVSYS to modify it's output for variable screen width
but most machines supporting ADVSYS are 80 column anyways.  This should only 
affect online BBS gaming with the 8 bit crowd.  Apologies to those of you
who are using computers that won't support the VT52 control codes.  We have
used them several places in ELVES '87.  Feel free to modify the sources to
give proper display for your terminal type.



Features I particularly liked in ADVSYS, but didn't know they were there from
the docs include...
 
   Passing the screen size (rows and columns) to ADVSYS as parameters when the
interpreter loads.  This could be particularly useful in a BBS environment where
the same game could be provided with both 40 and 80 column screen width.  

   Creation of a game log file.  Again passed as a parameter when ADVINT
loads.  Great for play testing.  We could run ELVES '87 with a journal file open
and let someone play away to their heart's content without watching over their
shoulder.  We were able to view the entire game at our leisure after the person
had finished playing.  The game only slows down slightly from increased disk
read/write cycles but on the hard drive this wasn't noticeable.  Unfortunately
with a Christmas deadline fast approaching us, we did not get to have ELVES '87
play tested to the degree which we would have liked.  There were quite a few
minor bugs in the release which was posted to Usenet in mid December.


   Greatly under-utilized features of ADVSYS which I plan to explore further...

   Probably the most powerful, yet least used are the bitwise operators.  I
scratched the surface of their potential with the FLOORS idea but suspect we
could reduce a lot of code by setting bit flags rather than wasting an entire
integer to see whether the player has gone potty or not.  Will have to check
that one out.  Might take more code to do the bit check than if you just used
BOOLEAN logic on integer values.

   An area I'm still foggy in are the OPTIONAL/REQUIRED/FORBIDDEN flags.  I
had no problem with OPTIONAL, but haven't tried working with REQUIRED or
FORBIDDEN yet.

   Yet another concept I didn't really work with.... SUPER-CLASS.  Would like
to see some more source code examples of how to use it efficiently.  I was
just using (class obj).  I suspect one of the reasons that our code is more
verbose than possibly it could be is that I did not approach CLASS in a more
organized fashion.  We ended up with a hybrid combination of our own work
together with the ADVRUN runtime package.  There are a lot of ADVRUN remnants
which need to be stripped out or reworked.  The key to creating a successful
ADVSYS adventure is in the development of an intelligent runtime package.  I
would be VERY INTERESTED in working together with others on the development of
a standardized series of runtime modules.  Individual adventure authors could
readily add their own runtime enhancements in the form of additional modules
but I'd like to see a foundation worked out.

     Here are some of the concepts which would be common to most adventures and
should be developed as part of the Advanced Runtime Package (can we agree to
use a .ARP extender on each module filename?).  Some work will no doubt be
required to sort out Integral Parts, Stationary Things, etc...  It's just that
there is no sense in each author re-inventing the wheel with every new adventure
that's written.

     Here's that short list of a few concepts I'd like to see incorporated in
addition to the obvious ones like movement directions, basic things, etc...:

                    Floors - so we can recycle objects, rooms and actors
                             as required to keep within the limits of the
                             ADVSYS compiler.
                    Actors - independently moving if desired similar to Frosty
                             in ELVES '87 but with more interaction with the
                             player.  "Frosty, get the fork."  
                    Fuses &
                    Demons - timed events based on the players actions in the
                             adventure.
                    Events - one-time events that only occur at given points
                             in the action.  Perhaps the first time a player
                             enters a room or picks up an object.  We need
                             something generic here rather than coding each
                             as entirely separate.  Similar to the VISITED?
                             flags maybe?  In ELVES we worked around this by
                             putting some things in the Long Description of
                             the object or room.  This worked fine as long as
                             the player didn't do a LOOK in the room again.
                             Sometimes you get an awkward response back.  Try
                             it in the first couple of rooms in the ice floes.

    I'm sure there's lots more, this is at least a start.
                    
            
   
******************************************************************************

     Well enough rambling for one text file.  Hope the comments and questions
above can generate some discussion.

Bruce MacKay
January 04/87
