TADS Sack Object

4 views
Skip to first unread message

Andrew D. Pontious

unread,
Dec 14, 1996, 3:00:00 AM12/14/96
to

So far there was only one person who mentioned how my game "Small World"
had a 'sack object' (to use an Inform term). Am I upset? Certainly not,
such game mechanics are most helpful when they're below the radar screen.
(Actually, I'm happy anybody mentioned it at all.) But now I'm asking
people to notice so they can give me feedback.

First of all, a definition. A sack object is a specific object designated
by a text adventure game for putting your items into for you. For
instance, let's say you already have ten items, and in this game, you can
only hold ten. Then you pick up an eleventh, but you're holding your sack
(or backpack or trunk or whatever).

So the game says (First putting ___ [a random object] in the sack.) and
then goes on to treat the results of you picking up the eleventh object.
Inform has this hardwired into it; all you need to do is specific which
object in the game will serve the function. TADS, until now ;-) has not.

Are there other TADS programmers who would be interested in this feature?
It would actually take some doing to change the code in "Small World" to
a stand-alone module other programmers could use. First of all, there are
tons of game-specific exceptions coded in, because of the global gravity
effect, which I would have to take back out. (I could go into long,
boring detail about it, but I doubt anybody would care. Sniff.)

Secondly, the only way I could think of to implement the sack object was
to have a call to the "sack code" added to *every verb.* Yup, every
single one. It means rewriting a good chunk of ADV.t, and extracting a
good chunk of Small World in order to create a stand-alone module. I
could do it, but I want to know if there's much demand first.

Plus programmers should keep in mind that integrating my module into
their game would be a pain because for any verb, you'd have to keep in
mind my changes, which would be in a separate file you'd probably want to
paste into your own game file.

Even if there *is* demand, there are further questions. Inform's version
specificies only one object, but since I'm coding my version myself, I
don't need to be hemmed in by such arbitrary restrictions. Why not three?
Or ten?

Now, if there are more than one, should they all be equal (meaning if you
were holding two the game were just decide on its own which to use) or
should there be a hierarchy, or a user-defined way of choosing. For
example, new commands "stash" and "unstash." Whichever sack object has
been "stash"ed last is the foremost container for objects. When it's
full, the second-to-last "stash"ed container is used. And if you
"unstash" a container, it won't be used automatically at *all*, so if you
were carrying it and too many objects, the game would say, "You carrying
too many objects." and leave it at that. Of course, you could still put
things in such a container manually.

Is that too much? Would players get confused? Certainly it could be an
invisible feature, which your game wouldn't even have to mention. But if
people don't think it would be used much, I'll leave it out completely.

Finally, my sack object had an additional feature. It would *take out* an
object from the "sack" if it was required by a verb, and in addition, if
taking that object out would mean you were carrying too many objects, it
would put another random object *in* the sack again. This was especially
amusing for two-object nouns:

>i
You have a backpack (being worn), hiking boots, socks, and a satellite.
The backpack seems to contain a canteen, a magnifying glass, and
fire-retardant pants.

>x canteen with glass
(First putting the hiking boots in the backpack.)
(Next taking the magnifying glass out of the backpack.)
(Next putting the socks in the backpack.)
(Next taking the canteen out of the backpack.)
Looking at the canteen with the magnifying glass doesn't show you
anything significant.

I don't think Inform's sack object does this. Is it worthwhile to include
in a module? Actually, I'd be lying if I told you I'd take the feature
out, since it was such a pain to code and I'm proud of it, but I'm
interested in what people think. Also, it gets into a whole nother topic:
how ADV.t by itself doesn't give warnings about something being *in*
another object before allowing you to apply a verb to it (wearing
clothing is a notorious example).

Thanks!

Wasn't technology supposed to make our lives EASIER?

Neil K. Guy

unread,
Dec 14, 1996, 3:00:00 AM12/14/96
to

Andrew D. Pontious (byza...@tuna.net) wrote:

: So the game says (First putting ___ [a random object] in the sack.) and


: then goes on to treat the results of you picking up the eleventh object.
: Inform has this hardwired into it; all you need to do is specific which
: object in the game will serve the function. TADS, until now ;-) has not.
:
: Are there other TADS programmers who would be interested in this feature?

Well my $0.02 on the topic is that one can never have too much nifty
sample source code to look at and play with. Though I doubt you'll get
much feedback on it. I've got hardly any feedback on the handful of
examples I've put online, but I know a few people have looked at it and
used it, so that's fine by me.

One note, though: Dan Shiovitz has already written and posted such a
sample piece of code (sack.t) and Stephen Granade included a version of it
with his collection of TADS modules. This stuff is all available at:

ftp://ftp.gmd.de/if-archive/programming/tads/examples/

Your sack program sounds quite a bit more involved than his, though.

- Neil K.

--
the Vancouver CommunityNet * http://www.vcn.bc.ca/
(formerly the Vancouver Regional FreeNet)

Nulldogma

unread,
Dec 15, 1996, 3:00:00 AM12/15/96
to

I, for one, noticed the nice inventory management in Small World. Nice
work, Andrew -- it was the only thing that kept me from going completely
mad (goddam gravity...).

> Secondly, the only way I could think of to implement the sack object was
> to have a call to the "sack code" added to *every verb.* Yup, every
> single one. It means rewriting a good chunk of ADV.t, and extracting a
> good chunk of Small World in order to create a stand-alone module. I
> could do it, but I want to know if there's much demand first.

Yes, please!

> Plus programmers should keep in mind that integrating my module into
> their game would be a pain because for any verb, you'd have to keep in
> mind my changes, which would be in a separate file you'd probably want
to
> paste into your own game file.

Well, you really should do them as "modify" segments rather than changing
ADV.T directly. That way as long as you weren't messing further with the
verbs, you could just add it as a separate module.

Actually -- hmm. Couldn't you maybe insert it into roomAction somehow
instead? I see that that's called before the verb routines, so it might be
a place to handle this. (And god knows I've never found it useful for
anything else.)

> Even if there *is* demand, there are further questions. Inform's version
> specificies only one object, but since I'm coding my version myself, I
> don't need to be hemmed in by such arbitrary restrictions. Why not
three?
> Or ten?

Go for it. They should be prioritized in some way, of course, but if your
knapsack is full and there's still room in the laundry bag, by all means
that should work, too.

Neil
---------------------------------------------------------
Neil deMause ne...@echonyc.com
http://www.echonyc.com/~wham/neild.html
---------------------------------------------------------

Stephen Granade

unread,
Dec 15, 1996, 3:00:00 AM12/15/96
to

On 14 Dec 1996, Neil K. Guy wrote:
> One note, though: Dan Shiovitz has already written and posted such a
> sample piece of code (sack.t) and Stephen Granade included a version of it
> with his collection of TADS modules. This stuff is all available at:
>
> ftp://ftp.gmd.de/if-archive/programming/tads/examples/
>
> Your sack program sounds quite a bit more involved than his, though.

Yes and yes. My module is based on Dan's code. It allows for multiple
sack objects, but it only checks for weight limitations during the "take"
verb. What you're describing, Andrew, sounds quite a bit more complex.

Anyway, feel free to take a look & see if it's of any use to you. I
don't mind, and I suspect Dan doesn't either.

(BTW, Dan, did you ever get a chance to look over the sack.t module?)

Stephen

--
Stephen Granade | "It takes character to withstand the
sgra...@phy.duke.edu | rigors of indolence."
Duke University, Physics Dept | -- from _The Madness of King George_


Andrew D. Pontious

unread,
Dec 19, 1996, 3:00:00 AM12/19/96
to

In article <19961215045...@ladder01.news.aol.com> Nulldogma,

null...@aol.com writes:
>I, for one, noticed the nice inventory management in Small World. Nice
>work, Andrew -- it was the only thing that kept me from going completely
>mad (goddam gravity...).
>
>Well, you really should do them as "modify" segments rather than changing
>ADV.T directly. That way as long as you weren't messing further with the
>verbs, you could just add it as a separate module.
>
>Actually -- hmm. Couldn't you maybe insert it into roomAction somehow
>instead? I see that that's called before the verb routines, so it might be
>a place to handle this. (And god knows I've never found it useful for
>anything else.)

Yes, I would "modify" ADV.T, but the trouble with modify (which is
probably unavoidable) is that you have to replace a *whole* property,
say, the verDoTouch and doTouch properties of the item "rock". So that if
someone comes along later, uses your module without knowing it
intimately, and then tries to modify the doTouch property of "rock" after
only checking ADV.T, and not both ADV.T and your code, then s/he's
screwed and will have unintended side effects. This is especially
troublesome when you're using five different modules your wonderfully
helpful coding ancestors have put together, and three out of the five
modify the same verbs...it can be a real mess, and promises only to get
worse.

In fact, roomAction was the way I implemented that gravity feature you
hated so much. ;-) In fact, I'm sure there was a reason I didn't try to
put the sack object code there, but I'll check again and get back to you.

In article <Pine.SUN.3.91.96121...@nebula.phy.duke.edu>


Stephen Granade, sgra...@phy.duke.edu writes:
>On 14 Dec 1996, Neil K. Guy wrote:
>> One note, though: Dan Shiovitz has already written and posted such a
>> sample piece of code (sack.t) and Stephen Granade included a version of it
>> with his collection of TADS modules. This stuff is all available at:
>>
>> ftp://ftp.gmd.de/if-archive/programming/tads/examples/

I'm having trouble FTPing to the archive nowadays, can anyone attach the
code to an e-mail message? I'd appreciate. I'm really kicking myself for
not checking there in the first place.

Also, a technical note: Neil Guy's message never showed up on my
newsgroup account. I only found out about it when Stephen quoted it. Did
anyone else have that trouble?

>> Your sack program sounds quite a bit more involved than his, though.
>
>Yes and yes. My module is based on Dan's code. It allows for multiple
>sack objects, but it only checks for weight limitations during the "take"
>verb. What you're describing, Andrew, sounds quite a bit more complex.

The trouble is my code also took a crack at "possession" of objects. I.e.
my game tightened the restrictions on what you had to have, not just in
your possession, but actually in your hands before you could do something
with it. It's really the only way to make a workable model world, but it
would involve even more modifications to ADV.T before it would be usable.

Reply all
Reply to author
Forward
0 new messages