[TADS 2] Beginners' anxiety...

9 views
Skip to first unread message

J. J. Guest

unread,
Aug 15, 2003, 11:54:27 AM8/15/03
to
I am working on a TADS port of my first ADRIFT game, "Goldilocks is a
FOX!" and grappling with the very messy problem of liquids. It is the
first time I have used TADS. I wanted to allow the player to pour
liquids from one container into another, and mix them together, and
whilst I have been quite successful in doing so, I am beginning to
worry that the program is becoming untidy. I first allowed the player
to POUR the liquids from one container INTO another. Then I decided to
allow the player to EMPTY one container into another, which was simple
enough:

ioEmptyIn( actor, dobj ) = { self.ioPourIn( actor, dobj.contents[ 1 ]
); }

I then changed the liquids' doTake and doDrop methods to act on the
containers of the liquids rather than the liquids themselves. I did
the same with doPutOn. I decided to make doPutIn have the same effect
as doPourIn, which seemed logical enough, but neccesitated a change to
the ioPutIn method of the container class to give the message "That
isn't a suitable container for liquids. " when the player attempts to
put the liquid in a paper bag... etc...

But my enquiry isn't really about whether I've done all this right,
although any tips would be appreciated! The code works, and I can't at
present think of any way of simplifying it. I really just wanted to
know whether other people feel the same sense of trepidation I get
when things seem to be getting overcomplicated. I am particularly wary
of making changes to general classes such as 'container' for the sake
of a single object that doesn't fit the pattern. Don't get me wrong, I
know it's necessary, but on some level it just doesn't feel right.
Does anyone else feel this way, or is it just beginners' nerves?

Quintin Stone

unread,
Aug 15, 2003, 12:15:59 PM8/15/03
to
On 15 Aug 2003, J. J. Guest wrote:

> But my enquiry isn't really about whether I've done all this right,
> although any tips would be appreciated! The code works, and I can't at
> present think of any way of simplifying it. I really just wanted to know
> whether other people feel the same sense of trepidation I get when
> things seem to be getting overcomplicated. I am particularly wary of
> making changes to general classes such as 'container' for the sake of a
> single object that doesn't fit the pattern. Don't get me wrong, I know
> it's necessary, but on some level it just doesn't feel right. Does
> anyone else feel this way, or is it just beginners' nerves?

You aren't clear on exactly how you are changing things. Are you editing
the adv.t file directly to make these changes, or are they contained
within a separate file with a "modify container" block?

If the former, then you may be right to be wary. It's generally
recommended that you not edit adv.t directly. If the latter, I might have
a suggestion to ease your discomfort.

Have you considered a new subclass of container, such as
"liquidContainer"? This would hold all of the new behavior and verify
statements, but any normal container behavior can be punted back to the
original container class with a "pass" command.

My personal feeling is that the liquid class should contain the majority
of your new code where possible, because that class is the special case.
The containers are still just containers; the only difference being that
some of them are waterproof. For example, when pouring water into a paper
bag, the water's verDoPourIn(actor, iobj) method gets called with iobj as
the paper bag. The water can figure out for itself here that the intended
container will not hold it:

verDoPourIn(actor, iobj) = {
if (not iobj.isLiquidContainer)
"That isn't a suitable container for liquids.";
}

Voila, no need to modify the container class. For "empty pitcher into
paper bag", the pitcher's verDoEmptyIn(actor, iobj) method gets called
the same way as the water in the above example.

You mention ioPutIn, but you don't mention any of the verify methods like
the one I wrote above. Rely on these, they are very very useful.

/====================================================================\
|| Quintin Stone O- > "You speak of necessary evil? One ||
|| Code Monkey < of those necessities is that if ||
|| Rebel Programmers Society > innocents must suffer, the guilty must ||
|| st...@rps.net < suffer more." -- Mackenzie Calhoun ||
|| http://www.rps.net/ > "Once Burned" by Peter David ||
\====================================================================/


Quintin Stone

unread,
Aug 15, 2003, 12:19:45 PM8/15/03
to
On 15 Aug 2003, J. J. Guest wrote:

> I am working on a TADS port of my first ADRIFT game, "Goldilocks is a
> FOX!" and grappling with the very messy problem of liquids.

Also, you may decide there's no need to reinvent the wheel. Check out

http://mirror.ifarchive.org/if-archive/programming/tads2/examples/liquid_parser.t

for a pretty in-depth implementation of liquids for TADS. I haven't used
it myself.

J. J. Guest

unread,
Aug 16, 2003, 7:57:46 AM8/16/03
to
Quintin Stone <st...@rps.net> wrote in message news:<Pine.LNX.4.44.03081...@yes.rps.net>...

Thankyou! Even though everything I did worked as I hoped it would, I
still had a nagging feeling that something was wrong. Fortunately I
never alter adv.t directly, so it was easy enough to delete the
modifications. I already had special classes for liquids and liquid
containers, but I hadn't thought of using the verification methods in
those classes to do all the work. Thanks also for the link!

J. J. Guest

Quintin Stone

unread,
Aug 16, 2003, 12:32:24 PM8/16/03
to
On 16 Aug 2003, J. J. Guest wrote:

> Thankyou! Even though everything I did worked as I hoped it would, I
> still had a nagging feeling that something was wrong. Fortunately I
> never alter adv.t directly, so it was easy enough to delete the
> modifications. I already had special classes for liquids and liquid
> containers, but I hadn't thought of using the verification methods in
> those classes to do all the work. Thanks also for the link!

Glad to help.

Jim Aikin

unread,
Aug 17, 2003, 2:00:57 AM8/17/03
to
> It's generally
> recommended that you not edit adv.t directly.

Having hacked adv.t rather extensively (while keeping a pristine copy
around, of course), I have very mixed feelings about this.

The advantage of editing adv.t is that when you're doing a search to learn
whether you have a burnVerb, and if so how exactly it's formatted, or
whether 'pitch' can be used as a synonym for 'throw', you only have to
search one file. If you've used the modify and replace keywords in a
different file, searching adv.t can get real confusing, because you'll be
staring at code that _appears_ to be functional, but in fact is never
compiled!

The disadvantage of editing adv.t is that when you get ready to start a new
game, you'll have to make any number of decisions about what to keep and
what to throw away, and then you'll have to do a bunch of cutting and
pasting. If all of your modifications are in a different file, sorting
through them before starting work on the new game is much easier.

I haven't been consistent about this, so I'm now faced with the worst of
both worlds.

The one thing I do consistently is this: When hacking adv.t, I always put a
comment ahead of the hack. The comment always begins with the phrase "JA
hack." This allows me to search for and find all of my changes easily.

--JA


Quintin Stone

unread,
Aug 17, 2003, 3:15:04 PM8/17/03
to
On Sun, 17 Aug 2003, Jim Aikin wrote:

> The advantage of editing adv.t is that when you're doing a search to
> learn whether you have a burnVerb, and if so how exactly it's formatted,
> or whether 'pitch' can be used as a synonym for 'throw', you only have
> to search one file. If you've used the modify and replace keywords in a
> different file, searching adv.t can get real confusing, because you'll
> be staring at code that _appears_ to be functional, but in fact is never
> compiled!

This definitely true. For example, when working on my game, it was
discovered that one of the default messages wasn't checking to see if the
object needed a plural verb. I searched adv.t and my basic.t, and forgot
I was using Neil deMause's extend.t (which is where the problem was).
However, I've gotten into the habit of using UltraEdit's "Find in Files"
to avoid this in the future.

R. N. Dominick

unread,
Aug 17, 2003, 8:33:59 PM8/17/03
to
"Jim Aikin" <darn_those_spammers@fake_address.org> wrote in
news:sSE%a.1620$B52....@newssvr25.news.prodigy.com:

>> It's generally
>> recommended that you not edit adv.t directly.
> Having hacked adv.t rather extensively (while keeping a pristine copy
> around, of course), I have very mixed feelings about this.

I think this recommendation stems from two things, really.

1) Although it doesn't happen often now, there was a time when there were
regular updates to adv.t. Keeping your modifications to 'modify' and
'replace' meant it was easy to slip in the updated library with little
work. This is about to become a big reason for not modifying the library
directly with T3, when its released.

2) It's easier to pass your source code around and have it quickly
understood by other programmers if they don't have to search through adv.t
for your modifications, but can instead find them all in one place.

--
R. N. Dominick -- ur...@bookmice.net

Coffeehouse Software -- IF non-productivity in spades!
http://www.bookmice.net/coffeehouse/

Reply all
Reply to author
Forward
0 new messages