[Inform] Containers of things

9 views
Skip to first unread message

andre...@hotmail.com

unread,
Nov 18, 2000, 7:03:41 PM11/18/00
to
What is the best way to implement things like the following: in a cereal
box there is cereal; in the jam jar there is jam; in the pop can there
is pop, etc?

--
Andrew MacKinnon
andre...@hotmail.com
http://www.geocities.com/andrew_mackinnon_2000/


Sent via Deja.com http://www.deja.com/
Before you buy.

Paul E. Bell

unread,
Nov 19, 2000, 3:00:00 AM11/19/00
to
andre...@hotmail.com wrote:
>
> What is the best way to implement things like the following: in a cereal
> box there is cereal; in the jam jar there is jam; in the pop can there
> is pop, etc?

Not sure how much I can help, but, perhaps a few questions will help
others to help.

1) I take it, you want to do something with the contents of these
containers?

2) If so, how much do you want to do? That is, do you need liquids to
act like liquids (if the pop is open, and you tip it over, on the table,
does it need to run across the table, and make a pool on the floor, or
soak into the carpet; while, if you do the same for the jam, it just
kind of oozes out on the table, and the cereal scatters all over, while
peanut butter just sits there)?

3) If these are actual containers, and you want to remove their
contents, you will need a way of keeping track of how much of the
contents is left, and a way of limiting where those contents can be
applied. That is, you may make peanut butter and jelly sandwiches, but,
you would not want to allow peanut butter and jelly to be spread on your
hammer (perhaps a "That's silly, you don't really want to do that!"
message would result).

This is more complex than just filling/emptying containers, as, you
probably don't want to use the whole thing at once.

Anyway, just some questions to get the ball rolling.
--
Paul E. Bell | Email and AIM: wd0...@millcomm.com | ifMUD: Helios
IRC: PKodon, DrWho4, and Helios | webpage: members.nbci.com/wd0gcp/
Member: W.A.R.N., Skywarn, ARES, Phoenix Developer Consortium, ...
_____ Pen Name/Arts & Crafts signature:
| | _ \ _ _ |/ _ _(
| | (_X (_/`/\ (_) (_` |\(_) (_) (_|_) (/`
)

andre...@hotmail.com

unread,
Nov 19, 2000, 3:00:00 AM11/19/00
to
In article <3A17C2DB...@millcomm.com>,
"Paul E. Bell" <wd0...@millcomm.com> wrote:

> andre...@hotmail.com wrote:
> >
> > What is the best way to implement things like the following: in a
> > cereal box there is cereal; in the jam jar there is jam; in the pop
> > can there is pop, etc?
>
> Not sure how much I can help, but, perhaps a few questions will help
> others to help.
>
> 1) I take it, you want to do something with the contents of these
> containers?
>
> 2) If so, how much do you want to do? That is, do you need liquids to
> act like liquids (if the pop is open, and you tip it over, on the
> table, does it need to run across the table, and make a pool on the
> floor, or soak into the carpet; while, if you do the same for the jam,
> it just kind of oozes out on the table, and the cereal scatters all
> over, while peanut butter just sits there)?
>
> 3) If these are actual containers, and you want to remove their
> contents, you will need a way of keeping track of how much of the
> contents is left, and a way of limiting where those contents can be
> applied. That is, you may make peanut butter and jelly sandwiches,
> but, you would not want to allow peanut butter and jelly to be spread
> on your hammer (perhaps a "That's silly, you don't really want to do
> that!" message would result).
>
> This is more complex than just filling/emptying containers, as, you
> probably don't want to use the whole thing at once.

I'm thinking of the infamous issue of dealing with a container (e.g.
cereal) and the actual cereal. The cereal box should be referrable to as
"cereal" and so should be the actual cereal in the box. It becomes more
complex when you have items such as "crackers" where you don't refer to
the box as "cracker", only the food. You do, however, refer to the box
as "crackers" or "cracker box" and you refer to the food as "cracker" or
"crackers". I'm currently involved in with the infamous parser issue.
(Look at all these in every kitchen)

Paul O'Brian

unread,
Nov 20, 2000, 3:00:00 AM11/20/00
to
On Sun, 19 Nov 2000 andre...@hotmail.com wrote:

> I'm thinking of the infamous issue of dealing with a container (e.g.
> cereal) and the actual cereal. The cereal box should be referrable to as
> "cereal" and so should be the actual cereal in the box.

If I can call the cereal box "cereal", how could the game ever distinguish
between it and the actual cereal? Even a person couldn't make that
distinction without more information. I'd say the best solution is to
require the box be referred to as "box".

--
Paul O'Brian obr...@colorado.edu http://ucsu.colorado.edu/~obrian
SPAG #23 will be devoted to the 2000 IF competition, and is actively
seeking reviews! Submit your comp reviews to me by December 5. Thanks!


Andrew Plotkin

unread,
Nov 20, 2000, 3:00:00 AM11/20/00
to
Paul O'Brian <obr...@ucsu.colorado.edu> wrote:
> On Sun, 19 Nov 2000 andre...@hotmail.com wrote:

>> I'm thinking of the infamous issue of dealing with a container (e.g.
>> cereal) and the actual cereal. The cereal box should be referrable to as
>> "cereal" and so should be the actual cereal in the box.

> If I can call the cereal box "cereal", how could the game ever distinguish
> between it and the actual cereal? Even a person couldn't make that
> distinction without more information. I'd say the best solution is to
> require the box be referred to as "box".

I dealt with this a lot in "Shade" (kitchen, kitchen sink, water from
the kitchen sink...) See the parse_name code that I posted recently.
You can make it work.

In this case, I'd try having the cereal box respond to "box" and
"cereal box", and also to "cereal" *only when* the cereal itself is
not in scope.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."

Joe Mason

unread,
Nov 20, 2000, 3:00:00 AM11/20/00
to

Alternatively, you may want to have it pick an object based on the command.
"GET CEREAL" obviously refers to the box, while "EAT CEREAL" obviously refers
to what's in it.

Joe

Paul E. Bell

unread,
Nov 20, 2000, 3:00:00 AM11/20/00
to

I don't know. If the box is closed, so I can't see the cereal, then,
"cereal" could refer to the box. However, I see the possiblity of a
bowl, with cereal in it, spilt cereal on the table, and on the floor,
and the open, but tipped over box of cereal, with a handful still in it.

>get cereal

Could refer to picking up a bunch of the cereal in my hands, whatever I
can carry (I would probably present a message to the effect that this is
not a good idea, I should put it in somethng), and, might ask which
cereal I want to pick up (the cereal on the table, the floor, in the
bowel, etc.).

PKodon/Helios

Neil Cerutti

unread,
Nov 20, 2000, 3:00:00 AM11/20/00
to
On erky...@eblong.com posted:

>In this case, I'd try having the cereal box respond to "box" and
>"cereal box", and also to "cereal" *only when* the cereal itself is
>not in scope.

That has a large performance hit if you test for it using the InScope
routine. You should avoid calling it in parse_name routines, if you
can.

Perhaps

if (cereal in location ||
IndirectlyContains(player, cereal))

will be enough. It depends on your game. You can easily throw out the
most common case of the cereal being in the box and the box being open.

--
Neil Cerutti <cer...@together.net>

lysseus

unread,
Nov 20, 2000, 3:00:00 AM11/20/00
to

"Joe Mason" <jcm...@uwaterloo.ca> wrote in message
news:slrn91j12r....@xenocide.slack...

> In article <97474618...@rexx.com>, Andrew Plotkin wrote:
> >Paul O'Brian <obr...@ucsu.colorado.edu> wrote:
> >> On Sun, 19 Nov 2000 andre...@hotmail.com wrote:
> >
> >>> I'm thinking of the infamous issue of dealing with a container (e.g.
> >>> cereal) and the actual cereal. The cereal box should be referrable to
as
> >>> "cereal" and so should be the actual cereal in the box.
> >
> >> If I can call the cereal box "cereal", how could the game ever
distinguish
> >> between it and the actual cereal? Even a person couldn't make that
> >> distinction without more information. I'd say the best solution is to
> >> require the box be referred to as "box".
> >
> >I dealt with this a lot in "Shade" (kitchen, kitchen sink, water from
> >the kitchen sink...) See the parse_name code that I posted recently.
> >You can make it work.
> >
> >In this case, I'd try having the cereal box respond to "box" and
> >"cereal box", and also to "cereal" *only when* the cereal itself is
> >not in scope.
>
> Alternatively, you may want to have it pick an object based on the
command.
> "GET CEREAL" obviously refers to the box, while "EAT CEREAL" obviously
refers
> to what's in it.

This is similar to the approach used by TADS Composite.t library extension,
in which components are first identified by the parser based on their
vocabulary and which makes its determination of which component is
appropriate to use based on its ability to _complete_ the action; the parent
object superceding in ambiguous cases.

Composite class was designed for situations where complex object behaviours
were desirable, such as those exhibited by desks, washing machines, etc. The
most common case being an object that has surface and container sub-objects.
In these cases you want commands such as <<put the axe on the desk>> to
choose the surface component, while <<kick the desk>>, which produces
default responses for parent and component objects defaults to the parent
object.

Parent objects *not* possessing the action verification methods required by
the parser fail early in the disambiguation process leaving only the
component objects in the parser disambiguation list that meet both
vocabulary, accessibility, and verification criteria. Sharing the parent
vocabulary as additional adjectives for component objects allows for player
commands such as <<open the wooden drawer of the desk>> or even <<search the
metal drawer of the metal desk>> in cases where there are both wooden and
metal desks, each possessing wooden and metal drawers.

The situation is further complicated by pronoun usage, such as encountered
by the command sequence <<x oven. put loaf in it>> In cases where pronouns
are used TADS relies are objects parsed from the previous command, which is
wholly unsatifactory. Composite.t forces the command <<put loaf in it>> to
be re-parsed by substituting 'it' with the original player command words
'oven'.

I mention this because both TADS and Inform should, in theory, be capable of
achieving this kind of object behaviour, and it provides an interesting
model world situation.

--Kevin

Andrew Plotkin

unread,
Nov 21, 2000, 12:57:49 AM11/21/00
to
Neil Cerutti <cer...@horpner.together.net> wrote:
> On erky...@eblong.com posted:

>>In this case, I'd try having the cereal box respond to "box" and
>>"cereal box", and also to "cereal" *only when* the cereal itself is
>>not in scope.

> That has a large performance hit if you test for it using the InScope


> routine. You should avoid calling it in parse_name routines, if you
> can.

Right you are.

> Perhaps

> if (cereal in location ||
> IndirectlyContains(player, cereal))

> will be enough. It depends on your game. You can easily throw out the
> most common case of the cereal being in the box and the box being open.

Conveniently, when I was messing around with this stuff in Shade, I
could omit the location test. One-room game, you know. :)

Reply all
Reply to author
Forward
0 new messages