NPCs carrying things in Inform

5 views
Skip to first unread message

Gareth Rees

unread,
Oct 24, 1994, 2:22:57 PM10/24/94
to
I've finally gotten around to bringing my adventure-in-progress up to
date with respect to the current version of Inform (the game started out
as an example to test Inform version 1, so this has involved a lot of
work!).

Now, Inform takes the view that creatures may carry things, but that
their contents are not in context and are not visible to the player. I
disagree, and want a creature's burden to be in context, and to be
listed when the creature is examined. For example, if a policeman is
carrying a whistle, I want this response:

> examine police constable
His lot seems to be a happy one. He is carrying a whistle.

> take whistle
The policeman is having none of that.

I can bring the contents of creatures into context by making the
creature transparent (!), but Inform doesn't support the form of
description illustrated above.

Obviously I can write a before routine that catches the Examine action
and produces the output I want, but this is such a natural thing to want
to do that it should surely be considered for the next version of the
libraries.

--
Gareth Rees

Mathematical Institute, (0865) 2-73525

unread,
Oct 25, 1994, 7:42:20 AM10/25/94
to
In article <38gu21$d...@lyra.csx.cam.ac.uk>, gd...@cl.cam.ac.uk (Gareth Rees) writes:
> I've finally gotten around to bringing my adventure-in-progress up to
> date with respect to the current version of Inform (the game started out
> as an example to test Inform version 1, so this has involved a lot of
> work!).
>

I sympathise mightily. "Curses" is about 50% Inform 1 which makes it
murderously hard to read the source code these days!

> Now, Inform takes the view that creatures may carry things, but that
> their contents are not in context and are not visible to the player. I
> disagree, and want a creature's burden to be in context, and to be
> listed when the creature is examined. For example, if a policeman is
> carrying a whistle, I want this response:
>
> > examine police constable
> His lot seems to be a happy one. He is carrying a whistle.
>
> > take whistle
> The policeman is having none of that.
>
> I can bring the contents of creatures into context by making the
> creature transparent (!), but Inform doesn't support the form of
> description illustrated above.
>
> Obviously I can write a before routine that catches the Examine action
> and produces the output I want, but this is such a natural thing to want
> to do that it should surely be considered for the next version of the
> libraries.
>
> --
> Gareth Rees

Inform takes the view that somebody else's possessions are visible
(i.e. in context) if and only if that person has "transparent" set.
By default this isn't set, but honestly that's the only sense in
which Inform is dogmatic on this point.

The policeman should indeed be given "transparent" (an odd word, some
may indeed think - it just means "contents visible" and also has some
implications for light-and-darkness). Rather than catch the Examine
action, I'd code something like

description
[; print "His lot seems to be an happy one";
if (child(self)==0) ".";
print ". He is carrying ";
WriteListFrom(child(self), ENGLISH_BIT);
".";
],

Now this looks, on the face of it, easy to generalise - i.e., to put
into the Inform library, and it isn't a bad idea. Except that: you
won't always want such a list of possessions to appear out in the open,
and you might want it in your own customised text (e.g. "With a whistle
and a merry smile, he..."). Moreover, how is the library to know that
"He"/"She"/"It" would be appropriate? These are not insurmountable
problems by any means but on the whole the piece of code above is not
so painful that generalisation is worth it.

So think I, anyway. Any views from the Informing public?

Graham Nelson
Oxford, UK

Jon Drukman

unread,
Oct 25, 1994, 2:08:11 PM10/25/94
to
Mathematical Institute, (0865) 2-73525 (nel...@vax.oxford.ac.uk) wrote:
: Now this looks, on the face of it, easy to generalise - i.e., to put

: into the Inform library, and it isn't a bad idea. Except that: you
: won't always want such a list of possessions to appear out in the open,
: and you might want it in your own customised text (e.g. "With a whistle
: and a merry smile, he..."). Moreover, how is the library to know that
: "He"/"She"/"It" would be appropriate? These are not insurmountable
: problems by any means but on the whole the piece of code above is not
: so painful that generalisation is worth it.

: So think I, anyway. Any views from the Informing public?

Yes, I have had cause to do this a few times in my current game, but I
never thought of it as an insurmountable burden. Sure, there could be
yet MORE flags and properties to determine whether or not a creature
should print its inventory and what string to preface it with, but as
Graham says, it isn't unduly troublesome.

Besides, I can barely keep the existing properties & attributes
straight in my mind... I don't want any more! :)

/jon

Chris Goedde

unread,
Oct 30, 1994, 4:14:42 PM10/30/94
to
Graham Nelson (nel...@vax.oxford.ac.uk) wrote:

>
>Inform takes the view that somebody else's possessions are visible
>(i.e. in context) if and only if that person has "transparent" set.
>By default this isn't set, but honestly that's the only sense in
>which Inform is dogmatic on this point.
>
>The policeman should indeed be given "transparent" (an odd word, some
>may indeed think - it just means "contents visible" and also has some
>implications for light-and-darkness). Rather than catch the Examine
>action, I'd code something like

Here's a related question. How would one implement a nontransparent
container (lets say a chest) with an external padlock? Suppose I want
this padlock to be an object so that the player can remove it once
it's unlocked. The lock should also move when the chest moves, of
course. How can the lock be made visible without the contents of the
chest being made visible?

Cheers,
chris
goe...@nwu.edu

S.P.Harvey

unread,
Oct 30, 1994, 4:51:44 PM10/30/94
to
Chris Goedde (goe...@jeeves.esam.nwu.edu) wrote:
: Here's a related question. How would one implement a nontransparent

: container (lets say a chest) with an external padlock? Suppose I want
: this padlock to be an object so that the player can remove it once
: it's unlocked. The lock should also move when the chest moves, of
: course. How can the lock be made visible without the contents of the
: chest being made visible?

Chris:

It's a matter of rapidly switching attributes and shuffling objects in
the blink of an eye. This happens to be one of my favorite techniques in
IF programming. It reminds me of sleight-of-hand, a skill at which I
used to be moderately adept.

Here's a theoretical list of the steps involved:

1) Chest is supporter, not container.
2) Lock is "on" chest.
3) "Before" routine of lock prevents taking of lock.
4) Lock has "locked".
5) When lock is removed...
A) Take away "Supporter" attribute of chest
B) Give Chest "Container" and "Closed"
C) Move "treasure" objects to inside of Chest

I'd have to write and test-compile the actual code to see if moving the
chest moves the lock as well. I would imagine it would. Alternately,
make it a big, heavy chest that can't be carried. You could make it
"pushable", simply move the lock along with it.

For simplicity's sake, you could make it impossible to replace the lock
once it's removed. Otherwise, you need to keep track of which objects
are in the chest so you can remove them and make the chest a supporter
once again.

If anyone writes the actual code to this problem, post it and let me know
if it works.

Scott

--
----------------------| S.P. Harvey |--------------------------
"If my answers frighten you, Vincent,
you should cease asking scary questions."
- Jules, "Pulp Fiction"
----------------------| sha...@interaccess.com |--------------------------

Greg Ewing

unread,
Oct 30, 1994, 9:50:29 PM10/30/94
to

In article <3914hg$g...@nntp.interaccess.com>, sha...@interaccess.com ( S.P.Harvey) writes:
|>
|> It's a matter of rapidly switching attributes and shuffling objects in

Two more ideas:

(1) Cheat: include "lock" as one of the words which the
user can use to refer to the chest, so that UNLOCK LOCK
is actually the same as UNLOCK CHEST. Disadvantage:
EXAMINE LOCK is also the same as EXAMINE CHEST.

(2) Give the chest an "interior" object which holds
the actual contents. Trap relevant verbs dealing with
the chest's contents and redirect them to its interior
instead. (Whether this could be done in a completely
transparent way I'm not sure - some library code
might assume that an object's contents are first-level
children).

Seems to me there's room for some library code to handle
objects like this which have both a "part hierarchy"
which is part of the structure of the object, and a
place where arbitrary objects can be put.
A microwave oven with a set of buttons comes to mind
as another example.

|> ----------------------| S.P. Harvey |--------------------------
|> ----------------------| sha...@interaccess.com |--------------------------

Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury, | A citizen of NewZealandCorp, a |
Christchurch, New Zealand | wholly-owned subsidiary of Japan Inc.|
gr...@cosc.canterbury.ac.nz +--------------------------------------+

Gareth Rees

unread,
Oct 31, 1994, 8:56:26 AM10/31/94
to
Chris Goedde (goe...@jeeves.esam.nwu.edu) wrote:
> Here's a related question. How would one implement a nontransparent
> container (lets say a chest) with an external padlock? Suppose I want
> this padlock to be an object so that the player can remove it once
> it's unlocked. The lock should also move when the chest moves, of
> course. How can the lock be made visible without the contents of the
> chest being made visible?

S.P.Harvey (sha...@interaccess.com) replied:


> It's a matter of rapidly switching attributes and shuffling objects in
> the blink of an eye.

I implemented this, and it works. I've put the code on my Inform
Programming Page; see

http://www.cl.cam.ac.uk/users/gdr11/inform/padlock.html

If you can't read this, ask me, and I'll post the code here.

There's one thing I would like to add to this example, but I'm not sure
how to. Currently, if you have the padlock in your hand, and you have
the key, you can type "lock padlock with key" to lock it. But padlocks
being what they are, you don't need the key to lock them, so "lock
padlock" ought to work as well.

BUT, "lock padlock" gets caught by the parser, which asks what the user
wants to lock the padlock with.

I suppose could extend the "lock" verb with

"lock" * scope=PadlockScope -> MyLock

and write a scope routine that just puts the padlock in scope. Hmm,
I will try it; if I succeed I'll update the code at the Web site.

--
Gareth "answers his own questions while he types" Rees

Gareth Rees

unread,
Oct 31, 1994, 11:35:16 AM10/31/94
to
Chris Goedde (goe...@jeeves.esam.nwu.edu) wrote:
> Here's a related question. How would one implement a nontransparent
> container (lets say a chest) with an external padlock?

S.P.Harvey (sha...@interaccess.com) replied:


> It's a matter of rapidly switching attributes and shuffling objects in
> the blink of an eye.

I quipped:


> I implemented this, and it works. I've put the code on my Inform
> Programming Page; see
>
> http://www.cl.cam.ac.uk/users/gdr11/inform/padlock.html
>

> There's one thing I would like to add to this example, but I'm not sure
> how to. Currently, if you have the padlock in your hand, and you have
> the key, you can type "lock padlock with key" to lock it. But padlocks
> being what they are, you don't need the key to lock them, so "lock
> padlock" ought to work as well.

No sooner said than done. I used this solution:

[ PadlockTest; if (noun == Padlock) rtrue; else rfalse; ];
[ PadlockLockSub;
if (noun ~= Padlock) "error!";
if (Padlock has locked) "It's already locked.";
give Padlock locked;
"You snap the padlock shut.";
];
Extend "lock" first * noun=PadlockTest -> PadlockLock;

but I'm sure other ideas would have worked just as well.

--
Gareth Rees

Jon Drukman

unread,
Oct 31, 1994, 1:51:46 PM10/31/94
to
Greg Ewing (gr...@cosc.canterbury.ac.nz) wrote:
: (1) Cheat: include "lock" as one of the words which the

: user can use to refer to the chest, so that UNLOCK LOCK
: is actually the same as UNLOCK CHEST. Disadvantage:
: EXAMINE LOCK is also the same as EXAMINE CHEST.

You can use the parse_name routine to distinguish what the user
actually typed.

/jon

Chris Goedde

unread,
Oct 31, 1994, 2:56:05 PM10/31/94
to
Mark Phillips (m...@bnr.co.uk) wrote:
>> Here's a related question. How would one implement a nontransparent
>> container (lets say a chest) with an external padlock? Suppose I want
>> this padlock to be an object so that the player can remove it once
>> it's unlocked. The lock should also move when the chest moves, of
>> course. How can the lock be made visible without the contents of the
>> chest being made visible?
>

> How about making the chest a container which is not transparent and
> is locked. Make the lock another object which can not be picked up
> (fixed?). When the lock is unclocked cause it to unlock the chest
> (possibly via a "fake" action) and remove fixed from the
> lock. Havn't tried this, but it is how the manual makes me think it
> should be done.

This should work if the container is also fixed. It helps to give the
lock the "concealed" attribute when it's attached to the container.

I do think it would be nice if the library were extended so that
containers could have external and internal contents in a simple way.

chris
goe...@nwu.edu


Mark Phillips

unread,
Oct 31, 1994, 9:20:15 AM10/31/94
to
> Here's a related question. How would one implement a nontransparent
> container (lets say a chest) with an external padlock? Suppose I want
> this padlock to be an object so that the player can remove it once
> it's unlocked. The lock should also move when the chest moves, of
> course. How can the lock be made visible without the contents of the
> chest being made visible?

How about making the chest a container which is not transparent and is
locked.

Make the lock another object which can not be picked up (fixed?).

When the lock is unclocked cause it to unlock the chest (possibly via a "fake"
action) and remove fixed from the lock.

Havn't tried this, but it is how the manual makes me think it should be done.

Would this work?

Mark Phillips

Mathematical Institute, (0865) 2-73525

unread,
Nov 1, 1994, 8:02:55 AM11/1/94
to
In article <393i4l$4...@news.acns.nwu.edu>, goe...@jeeves.esam.nwu.edu (Chris Goedde) writes:
> Mark Phillips (m...@bnr.co.uk) wrote:
>>> Here's a related question. How would one implement a nontransparent
>>> container (lets say a chest) with an external padlock? Suppose I want
>>> this padlock to be an object so that the player can remove it once
>>> it's unlocked. The lock should also move when the chest moves, of
>>> course. How can the lock be made visible without the contents of the
>>> chest being made visible?
>>
>
...many viable solutions have been proposed already, so I won't add to
them! Take a look at Gareth Rees' implementation.

>
> I do think it would be nice if the library were extended so that
> containers could have external and internal contents in a simple way.
>

I'm inclined to agree with this. The tricky part, as usual, is working
out a specification general and flexible enough not to make difficult
examples impossible. I think something might be done by allowing an
object to have an "interior object" whose possessions would be its
internal possessions. The original object would then be free to be a
supporter, and have things on top, or indeed transparent and carry
buttons and dials with it.

It may seem rather elaborate to have an extra object signifying the
inside, but I can't see how else to get this feature in full generality.
The designer might want all kinds of odd things - a Narnian wardrobe
which could have things put in it or on top of it, and also entered
as a "door".

Opinions, anyone?

Graham Nelson
Oxford, UK

Mark Hughes

unread,
Nov 3, 1994, 4:39:31 AM11/3/94
to
Graham Nelson <nel...@vax.oxford.ac.uk> spake:

>It may seem rather elaborate to have an extra object signifying the
>inside, but I can't see how else to get this feature in full generality.
>The designer might want all kinds of odd things - a Narnian wardrobe
>which could have things put in it or on top of it, and also entered
>as a "door".
>
>Opinions, anyone?

Perhaps multiple container/supporter support? That way, you could have things
in the wardrobe, things on top of the wardrobe, things attached to the wardrobe
(pound a nail into it and hang a shirt from it), etc. And various supporters
could have different flags, then - some hidden, some not.

Just a thought...

-Mark Hughes

David Baggett

unread,
Nov 3, 1994, 10:33:23 PM11/3/94
to
In article <1994Nov1.130255.27088@oxvaxd>,

Mathematical Institute, (0865) 2-73525 <nel...@vax.oxford.ac.uk> wrote:

>The designer might want all kinds of odd things - a Narnian wardrobe
>which could have things put in it or on top of it, and also entered
>as a "door".

After trying many ad-hoc work-arounds to get things like this to work, I
finally bit the bullet and formally separated the notions "in", "on",
"under", and "behind" in WorldClass, and gave each game object its own
"locationtype" field. That way I can keep all the "contents" in a single
list, but have the class library keep track of which things are in their
containers, which things are on their containers, etc. And this is a very
natural syntax -- you write, for example,

cheezkee: Item
location = table
locationtype = 'on' // on the table
...
;

or

Me: Player
location = bed
locationtype = 'on'
position = 'sitting' // player starts out sitting on the bed
;

and WorldClass takes it from there.

The issues that everyone has raised with respect to, for example, listing
contents ("out in the open") or not are actually quite subtle, and tedious
to deal with properly. There are many different notions here, and it's
important to distinguish between them all for maximum flexibility. After
several years of ad hoc hacking, I've finally found a set of primitives
that seems sufficient. (At least, I haven't found any relationships I'd
want to define that I couldn't easily specify with these primitives.)

At the risk of belaboring the issue (I think it is a fairly important one),
I'll detail what I did in WorldClass in this regard. If you don't care,
hit 'n' now -- there's only technical stuff in the rest of the message.

WorldClass has the following "listing" concepts:

- Containers can specify whether they want their contents listed
in room descriptions for each of the containment types and
senses. This gives us the following long list of methods:
(these are the defaults in the basic Thing class)

incontentslisted(obj) = { return true; }
incontentslistedsmell(obj) = { return true; }
incontentslistedsound(obj) = { return true; }
incontentslistedtouch(obj) = { return true; }

oncontentslisted(obj) = { return true; }
oncontentslistedsmell(obj) = { return true; }
oncontentslistedsound(obj) = { return true; }
oncontentslistedtouch(obj) = { return true; }

undercontentslisted(obj) = { return true; }
undercontentslistedsmell(obj) = { return true; }
undercontentslistedsound(obj) = { return true; }
undercontentslistedtouch(obj) = { return true; }

behindcontentslisted(obj) = { return true; }
behindcontentslistedsmell(obj) = { return true; }
behindcontentslistedsound(obj) = { return true; }
behindcontentslistedtouch(obj) = { return true; }

The "obj" parameter lets the container base its decision on any
given property of the object in question.

- Each object specifies whether or not it wants *itself* to be
listed in room descriptions. Again, we have a different
method for each sense:

islistable(actor) = { return nil; }
islistablesmell(actor) = { return nil; }
islistablesound(actor) = { return nil; }
islistabletouch(actor) = { return nil; }

And notice that an object may condition its "listability"
on who's doing the sensing.

- Finally, an object may specify that it is not "noticeable".
Objects that aren't noticeable are *never* listed, either in
room descriptions, or, for example, in "look in X" descriptions.

In particular, I have a class called Part -- a Part is a
component of another object, like the trigger on a gun. Such
things are not separate objects for any reason but to allow
separate examination. In other words, a trigger is not a
separate entitity in the player's mind, but must still be
referenceable individually, as in "examine trigger" or "pull
trigger".

Of course, whether or not the actor who's sensing can sense the object also
affects whether or not the object gets listed. (This is another can of
worms!)

To prevent an actor's contents from being listed in a room description,
you'd simply set

incontentslisted(obj) = { return nil; }

in the actor. (Things actors carry are considered to be "in" the actors.)

To prevent a particular object from getting listed when in an actor's
possession, you'd do something like:

whistle: Item
islistable(actor) = {
if (self.isin(Bobby)) // don't list me if the cop's got me
return nil;
else
return true;
}
;

Likewise, you might want the whistle to have a chain. In this case, you'd
write

chain: Part
partof = whistle

// isnoticeable returns nil by default; no need to override
;

Graham's Narnian wardrobe is also easy:

wardrobe: Surface, Container, Door
...
;

will exploit multiple inheritance to get what we want "automagically".

This is probably more than anyone wanted to know. Note also that this is
not an attempt to start a TADS/WorldClass/Inform relgious war (please, no).

But I wanted to make it clear that ad hoc hacks will only go so far -- I
eventually got so tired of writing tons of specialized code for every
"Narnian wardrobe" case that I made a general facility for these kinds of
things, and have been much happier since. :)

The point is that anyone who's interested in generalizing the notion of
containment in their own code should look at the WorldClass source -- it is
tedious to (re)invent this wheel.

Dave Baggett
__
d...@ai.mit.edu MIT AI Lab He who has the highest Kibo # when he dies wins.
ADVENTIONS: We make Kuul text adventures! Email for a catalog of releases.

Reply all
Reply to author
Forward
0 new messages