From: dmb@case.ai.mit.edu (David Baggett)
Newsgroups: rec.games.int-fiction
Subject: Learning TADS, TADS Hacks, etc. (was Re: TADS fragment & moaning)
Date: 13 Nov 1992 18:15:14 GMT
Organization: MIT Artificial Intelligence Laboratory
NNTP-Posting-Host: case.ai.mit.edu

In article <BxMp21.2GH@news.cso.uiuc.edu> amead@s.psych.uiuc.edu (Alan Mead) writes:
>Or maybe we just disagree on the meaning of "getting started".  IMHO,
>the objects & etc defined in ADV.T are as important to the TADS as the
>stdio & etc are to the C language.  I think they should be documented in
>the manual as well or better than the (simple) built-in functions like
>cvtstr() or askio().

This is SO true.  Though I like TADS a lot the way it is now, I think
it could be improved just be redoing ADV.T.  The "required senses"
stuff I mentioned here before is (I think) a good example -- you could
add that to TADS mainly by changing ADV.T.

I would venture that even more complex things like the light/sound
filters recently discussed here could be added by rewriting ADV.T.
TADS is essentially a complete programming language, after all.

The way I personally learned TADS was that Leary and I sat down with
the 1.0 shareware distribution, struggled through all of DITCH.T and
some of ADV.T and then proceeded to try to write some games (i.e.,
without the documentation).  I wrote "Dave's Treasure Cave" and Leary
wrote "Sociopath."  (You don't want to see either, trust me.)  Anyway,
both these games were terrible, and full of all sorts of brain-damaged
attempts at using the language.  (For one thing, the "ver" methods
really confused us at first.  This is a pretty fundamental part of the
system.)

By the time we registered the system (and gotten the manuals), we'd
already figured most everything out the hard way.  Nevertheless, the
manual did clear a few things up here and there.  :-)

To people who want to learn TADS, I'd recommend just sitting down and
writing a silly game, stealing code liberally from DITCH.T.  It's
pretty obvious how to define rooms and objects, and when you need to do
something harder (like making a new verb), you can just hunt through
the manual, read about the topic, and then rip some code out of Ditch
Day Drifter.  Above all, DON'T WORRY about how your first game will
turn out.  Worry about higher-level issues like making the game fun
later, once you've mastered the basics of the language.

Once you get proficient at the language, many things will come to seem
rather tedious.  Adding deocrations is the most obvious example of
this.  I now have macros for my favorite editor that insert decoration
templates for me so I just have to fill in the slots.  This helps
prevent bursts of creativity from fading in the time it takes to add
a dozen unimportant (to the plot, at least) decorations in every room.

>Also, just because the ADV.T source is there, I woudn't advise anyone
>to alter it except as a last resort.  You will have to edit the game to
>make it compatible with future versions of ADV.T (even running the
>slight risk that your changes will be incompatible with some future
>expansion of ADV.T).

I find that I really *have* to make some changes to ADV.T, and yes,
the compatibility issue is annoying.  Mike has been trying to come up
with a way that people could define only their changes to stuff in
ADV.T in their own source files, thereby eliminating any need to alter
ADV.T itself.  But he's never hit upon a really nice way to do it.  If
anyone has any ideas, please mention them; this is really a problem.

I just had to go through UU1 and UU2 an apply all the changes to the
1.0 ADV.T to the 2.0 ADV.T and it was not only tedious but
error-prone.  Who knows if I left something out in the transition?

>Further, I think you can do most things by defining new classes in your own
>source file.

This works for *adding* capabilities, but not for changing exisiting
ones.  For example, if I want to change the verDoEat method for thing
I *must* change ADV.T, because it's already defined there.  It would
be nice to be able to say something like:

override class thing:
	verDoEat(actor) = {
		"Didn't your mother ever warn you about putting every
		random thing in your mouth?"; 
	}
;

>I'd like to see other people's tricks too.  I haven't implemented any verbs
>more complicated than the above.

Here's a litle hack I came up with that I use all the time now:

//
// A decoration that's in multiple places at once.
//
class floatingdecoration: decoration
	locationOK = true	// OK for location to be method
	location = {
		if (find(self.loclist, Me.location))
			return Me.location;
		else
			return nil;
	}
;

You use this like so:

grass: floatingdecoration
	sdesc = "grass"
	ldesc = "It's just ordinary, albeit very healty, grass"
	noun = 'grass' 'lawn'
	adjective = 'healthy' 'green'

	// places where we find this decoration:
	loclist = [ courtyard clearing outsidehut inn ]
;

This makes it possible to define decorations that are in many locations
without a lot of typing.  You can put as many locations in the loclist
as you want.  You can also add or subtract from the loclist
dynamically.

Dave Baggett
--
dmb@ai.mit.edu           MIT Artificial Intelligence Laboratory                  
ADVENTIONS: interactive fiction (text adventures) for the 90's!
dmb@ai.mit.edu *** Compu$erve: 76440,2671 *** GEnie: ADVENTIONS
Newsgroups: rec.games.int-fiction,rec.arts.int-fiction