Newsgroups: rec.arts.int-fiction
Path: gmd.de!jvnc.net!darwin.sura.net!zaphod.mps.ohio-state.edu!cs.utexas.edu!uunet!stanford.edu!agate!pasteur!cory.Berkeley.EDU!librik
From: librik@cory.Berkeley.EDU (David Librik)
Subject: Re: What's new in TADS 2.0 ADV.T?
Message-ID: <librik.723328745@cory.Berkeley.EDU>
Sender: nntp@pasteur.Berkeley.EDU (NNTP Poster)
Nntp-Posting-Host: cory.berkeley.edu
Organization: University of California, at Berkeley
References: <1992Dec2.104540.4333@wkuvx1.bitnet>
Date: Wed, 2 Dec 1992 20:39:05 GMT
Lines: 102

mollems@wkuvx1.bitnet (Molley the Mage) writes:

>I've just sent in my upgrade fee for TADS 2.0, and while I'm waiting
>for it to arrive, I thought I would go ahead and organize the code of
>my game in preparation for re-working it to take advantage of the new
>features in 2.0.

>With my registration, I got a copy of the code for Deep Space Drifter. 
>This code is supposedly written for TADS 2.0, and the executable was
>appended to the TADS 2.0 runtime system, but in looking through the
>code I notice that a lot of the things which were added in TADS 1.2
>are not utilized by the DSD code.

That's because Mike Roberts did not rewrite DSD for 2.0.  He just modified
it slightly so it still compiles.  Source code for DSD, or for Ditch Day,
is NOT a reliable method for deciding what TADS 2.0 looks like.

So here are some points on converting your older TADS games to work with 2.0:
(1) methods have to be called with the correct number of parameters.  in the
    old TADS, if a method -- say "doShoot" -- didn't need to know the actor
    and indirect object being passed to it, you could just define it as
       doShoot = ....
    This now causes a run time error (unless you turn parameter checking off)
(2) "do" is now a language construct, so get rid of all those variables called
    "do" (if, like me, you used them to receive direct objects).
(3) Hidden things work differently.  This is because Mike added a new feature
    to the old firstobj()/newobj() way of stepping through all the objects
    in the game.  Now you can say firstobj(fishclass), etc., and step through
    ONLY the objects which are descendents of the fishclass.  There is a
    new class called hiddenItem, which has no properties, but which you should
    list in the inheritance list of any object that's hidden.  The default
    initSearch() function in ADV.T now goes only through hiddenItems when
    constructing search lists.  You should make heavy use of this new feature
    in order to speed up your initializations of things.

By the way, all incompatibilities can be turned off by using the -1 switch
on the compiler.

Probably the most notable thing about TADS 2.0 is that it uses virtual memory.
What this means is that only the objects that are needed at any given time are
loaded from disk.  After they are loaded they sit around in a cache in memory
so you don't need to load them again.  What this means is that you spend a lot
of time going to the hard disk constantly for every item and room the first
time you encounter it.  In the old TADS, the whole game was loaded into memory.
This new system has the advantage that you can get games much bigger than your
system's memory -- like new Unnkuulian game, no doubt.  The disadvantage is
that it's incredibly slow!  (I wish Mike had made the TADS run time load as
much of the game as it could -- I don't have a big game, and I don't want to
have to go to the hard disk constantly.  Also, I'd like for people to be able
to play my game off a floppy.)

Needless to say, this makes the "slow noun resolution" problem worse.  (This
was mentioned in connection with a game that had hundreds of objects all called
"door").  But Mike Roberts is working on a fix for that problem right now.
Anyway, this is a good reason to use firstobj(class)/newobj(class) to scan
through items -- if you just use firstobj()/newobj() to go through all of
them, your initialization time can be mighty long, since the objects are no
longer all in memory.

>Does anyone know if these things were left out intentionally, to
>ensure compatability with 1.0 code, or if they have been removed from
>the 2.0 ADV.T entirely?  I'm speaking of things like the hidePlace
>classes, such as underHider and behindHider, as well as the format
>strings and the isHim/isHer pronoun attributes.  The "verb synonyms"
>were not used by the DSD code either, leaving instead a lot of those
>constructs like
>	verDoPush (actor) = { self.verDoPress (actor); }
>	doPush (actor) =    { self.doPress (actor); }
>which according to the 1.2 release notes should all be gotten rid of.

They shouldn't "be gotten rid of".  They're just not necessary any more.
But DSD was written for TADS 0.9 or something like that, and the authors
aren't particularly interested in fixing it if it isn't broken.  One really
convenient feature of TADS 2.0 is that the "self." is no longer necessary
when referring to local variables, by the way.  Nothing has been removed
from TADS at all.

>I don't want to re-write my 1.1 code with the 1.2 classes and then
>have to turn around and scrap them again when 2.0 gets here.  (Of
>course, I could always just add the 1.2 classes from ADV.T to the 2.0
>ADV.T, but if there are nicer ways to do these things in 2.0, then I
>want to use those.)

Uh, TADS 2.0 is a superset of TADS 1.2.  Personally I would just wait until
2.0 shows up.  But you don't need to re-write your code to use the
"convenience" features of 2.0 -- you can just start using them in any new
code.

The manual for 2.0 is seriously cool.  It has a chapter on how to design
an adventure, with copious warnings drawn from Deep Space Drifter, a game
the author now hates because it was so poorly designed.  And it has another
chapter of "TADS programming tricks" for doing things like making scripted
actors and vehicles.  (And I must admit that the "elevator" example looks
mighty familiar, *grin*).

Actually Ditch Day Drifter, which comes free with TADS, is one of my favorite
adventures - up there with Planetfall.  That's about the level of difficulty
I like in an adventure.

- David Librik
librik@cory.Berkeley.edu

