From: librik@cory.Berkeley.EDU (David Librik)
Subject: Re: So you want to write a text adventure?
Organization: University of California, at Berkeley
Date: Tue, 10 Nov 1992 11:43:31 GMT

Russell L. Bryan <rbryan@Mail.trincoll.edu> writes:

>With this in mind, I invite anyone interested in TADS to sign themselves
>up for a course I will be running in the near future.  The first lesson
>will be sent out two weeks from today, and new lessons will come every
>two weeks afterwards starting on January 15th.  While the course will
>begin with the basics of TADS programming, later lessons will aid you in
>first developing the concept for, and then actually creating a TADS
>adventure of your own.

(I've added rec.arts.int-fiction to the newsgroups line, since
 that's the newsgroup for people who write such games)

This seemed like as good a place as any to list Dave's Quick Guide To
Getting Started With TADS.  The key to learning how to write adventures
is to start writing one.  You will need the following:

(1) Get the manual for TADS.  Register the game, and get the manuals.
(2) Print out (on a good-quality printer): ADV.T, STD.T, and DITCH.T.
    ADV and DITCH run to many pages each -- find a free laser printer.
    Staple each packet together so they aren't lost and you can flip
    through them quickly; ADV and DITCH will require two packets unless
    you have a mondo stapler.
(3) Familiarize yourself with the basic ideas of the language.  Subtleties
    (syntax details, daemons, fuses) should be left for later -- just the
    idea of objects, inheritance, and how to print text; it helps if you know
    C or Pascal.
(4) Start reading DITCH.T.  Look at the basic way items and rooms are defined.
    The main way you write TADS code is to take off from something you already
    have.
(5) Make a copy of DITCH.T, rip out all the later bits (the actual rooms and
    items), leaving the initialization code, the Me definition, all that stuff.
    On this, start implementing your adventure.  Just rooms and items.
(6) Start adding more complicated things.  It really helps if you have played
    Ditch Day Drifter; use DITCH as a reference for stuff.
(7) Use notify() rather than daemons and fuses, except for the few "global"
    events which are already present in Init.  notify() is easier.  DITCH
    gives plenty of examples of different uses for it -- find something like
    what you're looking for and see how he does it.
(8) Eventually it will be time to tear out the Ditch Day Drifter startup code
    and basic definitions (the stuff you've been building on).  Copy in STD.T
    into your file, at the beginning: by now you should have no problem reading
    what's going on there.  Remove stuff you don't want (food daemon, sleep
    daemon, whatever).  Add your own stuff -- you've probably already started
    putting initialization stuff in the Global object and in Init.
(9) When you want to start making significant changes to the basic "adventure"
    behavior, you will have to change ADV.T.  Don't worry, that's exactly
    what it's there for.  When you make a change, though, document exactly
    what you're doing -- put comments at the beginning, and down in all the
    places you change.  CALL THIS NEW ADV.T BY A NEW NAME, SPECIFIC FOR YOUR
    ADVENTURE, by the way.  (An example: in my game, I wanted to add that
    you couldn't leave the room if there was an Armed Guard in it: he shoots
    you.  Since this is a basic modification of the Room object, I changed
    the Leave method to check for the Armed Guard.  This would obviously apply
    only to my game.)  When a new ADV.T comes along you will need to re-apply
    these changes to make a new special file; that's why you comment it well.
(10) Finally: this adventure that you're writing will probably be a practice
     game.  It helps to have the basic idea already laid out, so you can
     concentrate on learning to code.  You can keep adding stuff -- improved
     Actor behaviors -- as you master TADS.  The only problem with this
     approach is that you spend all your energy on the "practice" game, getting
     it really spiffy, and don't feel up to moving onto some Real Adventure
     Game Design and Implementation.  Yet your "practice" game, however cool,
     isn't going to be that great -- simply because your original design should
     be simple so you can code it.  (I started by implementing in TADS a game
     I already had in BASIC).

There is this initial "bump" you have to overcome when you start with TADS.
I didn't get over it until I had the printouts in hand and could look in the
manual.  (Even so, I didn't understand most of what was going on in the
"initialization" part of a TADS game for quite a while).  The best thing
you can get if you are programming in TADS is examples of pre-written code
to do the kind of things you want.  That's why source code to working
games is so useful.  It might be cool to assemble a collection of cool
algorithms for doing things (basically clever hacks) -- suitably neutered
so they don't give away the game they come from.  I'd like to see the
circulating actor code for Robert Abernathy, for instance.  And somewhere
I have rather clever code to implement "sudden death" situations using
daemons, a gun with ammunition, support for objects to be "listening" for
things said by the player (when you SAY a certain phrase, for instance),
and an elevator.  None of it is any great shakes but it beats developing
it yourself.  I only wish I knew where it was.

If you keep a record of this "class," send me a copy.  You might consider
holding off until the semester starts again, though -- most students will still
be on Christmas break on January 15th.

- David Librik
librik@cory.Berkeley.edu