annoying pronouns
John J Lee
I hope I didn't post this thing last term and forget about it...
Anyway:
--
> x desk
The desk contains a fascinating Widget.
> take it
You can't do that to the desk!
--
D'oh! Surely there's some way of stopping this.
John
Advice: the smallest current coin.
Ambrose Bierce, The Devil's Dictionary
Adam Cadre
John J Lee wrote:
>
> > x desk
>
> The desk contains a fascinating Widget.
>
> > take it
>
> You can't do that to the desk!
> --
> D'oh! Surely there's some way of stopping this.
You didn't specify which language you're using, but in Inform you
can fix this by fiddling around with itobj. You might include an
after-routine that would set itobj equal to the child of the desk
after a Search command, should it reveal that the desk has only one
child.
-----
Adam Cadre, Durham, NC
Tired of the endless reviews of 1996? Then take a look back at 1997!
1997: the Year in Review -- http://www.duke.edu/~adamc
Andrew Plotkin
John J Lee (jjl...@york.ac.uk) wrote:
> I hope I didn't post this thing last term and forget about it...
You didn't say what language you're using; I'm assuming Inform because I
know the answer. :)
> Anyway:
> --
> > x desk
> The desk contains a fascinating Widget.
> > take it
> You can't do that to the desk!
> --
> D'oh! Surely there's some way of stopping this.
Object desk
with description [;
itobj = widget;
"The desk contains a fascinating Widget.";
],
The problem is that if you want to do this, you really ought to do it
consistently. Which is a tremendous pain in the butt. If it was only in
this instance, the player would not be expecting it (since "it" usually
refers to the last item *he* referred to.) Then you'd get
> x desk
The desk contains a fascinating Widget.
> put Boring Widget on it
You can't put things on the fascinating Widget!
which is just as annoying.
A very crude solution would be to have the printing functions (CDefArt,
etc) set "itobj" to their arguments. This would work very badly.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Neil K. Guy
John J Lee (jjl...@york.ac.uk) wrote:
: > x desk
:
: The desk contains a fascinating Widget.
:
: > take it
:
: You can't do that to the desk!
: --
: D'oh! Surely there's some way of stopping this.
You didn't say what language you're using, and without that vital piece
of information it's rather difficult to answer your question in a useful
fashion. 'Round these here parts it's a custom to preface the subject of
your message with [TADS] or [Inform] or [Whatever] language you're using
so everyone knows.
Anyway, with TADS you use the setit() feature to specify an item or items
to be "it". (tag!) I'm sure Inform has a similar function, but I've no
idea what it is.
- Neil K. Guy
--
the Vancouver CommunityNet * http://www.vcn.bc.ca/
(formerly the Vancouver Regional FreeNet)
Nulldogma
> --
> > x desk
>
> The desk contains a fascinating Widget.
>
> > take it
>
> You can't do that to the desk!
> --
> D'oh! Surely there's some way of stopping this.
You don't indicate which language you're using, but in TADS, you would do
this:
desk:fixeditem
ldesc={"The desk contains a fascinating Widget."; setit(widget);}
;
Of course, what happens if the desk contains a widget, a doohickey, and a
thingamabob, I don't know. And then you need to consider that the player
may have *meant* to try to take the desk.
All reasons why I don't use setit(), and leave the parser to its own
devices.
Neil
---------------------------------------------------------
Neil deMause ne...@echonyc.com
http://www.echonyc.com/~wham/neild.html
---------------------------------------------------------
Erik Max Francis
John J Lee wrote:
> I hope I didn't post this thing last term and forget about it...
>
> Anyway:
> --
> > x desk
>
> The desk contains a fascinating Widget.
>
> > take it
>
> You can't do that to the desk!
> --
> D'oh! Surely there's some way of stopping this.
But you asked to TAKE THE DESK, not TAKE THE WIDGET. Even in normal
conversation this ambiguity would be resolved to DESK not WIDGET.
--
Erik Max Francis | m...@alcyone.com
Alcyone Systems | http://www.alcyone.com/max/
San Jose, California | 37 20 07 N 121 53 38 W
&tSftDotIotE | R^4: the 4th R is respect
"You must surely know if man made heaven | Then man made hell"
Dan Shiovitz
In article <19970107203...@ladder01.news.aol.com>,
Nulldogma <null...@aol.com> wrote:
>> --
>> > x desk
>>
>> The desk contains a fascinating Widget.
>>
>> > take it
>>
>> You can't do that to the desk!
>> --
>> D'oh! Surely there's some way of stopping this.
>Of course, what happens if the desk contains a widget, a doohickey, and a
>thingamabob, I don't know. And then you need to consider that the player
>may have *meant* to try to take the desk.
>
>All reasons why I don't use setit(), and leave the parser to its own
>devices.
One interesting thing to try (which TADS doesn't currently support (well ..
not without a lot of ugly hacking)) would be to set the it object to all
the last objects referred to, not just the last one. Then, when someone
uses "it" in a sentence, the parser would go down the list and use the
verify method to find the first appropriate one and return that. On the
other hand, if the person had used "them," it could return the entire
list.
This would hopefully make things like
> TAKE FISH FROM BOX. EAT IT.
and
> TAKE FISH FROM BOX. CLOSE IT.
both come out right.
I guess my idea for it/them isn't so great, though. Although
> TOUCH BLUE CRYSTAL TO GREEN CRYSTAL. PUT THEM IN BAG.
would give correct behavior, these wouldn't really:
> PUT FISH AND CACTUS ON DESK. TAKE THEM. (would try to take desk also)
> PUT FISH ON DESK. TAKE THEM. (ok.. this is weird input anyway)
> PUT FISH AND CACTUS IN BOX. TAKE IT. (probably the user means the box)
Ok.. umm.. how about when disambiguating "them", the parser first tries
to see if they had a list of objects in their command ("THE FISH AND THE
CAT"), and returns that. If not, it returns the "it" list. On the
other hand, when disambiguating "it", it returns the first singular object
it can find. Which, in turn, suggests that it might be best to handle it/them
with three slots (for noun, direct and indirect object), and each can
contain either an array of or a single object.
So this is doable, certainly. Is it worth it? Not sure, really. I don't
use "it" very often myself, and never use "them". But if they were
implemented this well, I might get into the habit of using them more.
>Neil
--
dan shiovitz scy...@u.washington.edu sh...@cs.washington.edu
slightly lost author/programmer in a world of more creative or more
sensible people ... remember to speak up for freedom because no one else
will do it for you: use it or lose it ... carpe diem -- be proactive.
my web site: http://weber.u.washington.edu/~scythe/home.html some ok stuff.
Nulldogma
> So this is doable, certainly. Is it worth it? Not sure, really. I
don't
> use "it" very often myself, and never use "them". But if they were
> implemented this well, I might get into the habit of using them more.
I'd say anything that makes life easier for the players is a good thing,
and totally worth it.
Of course, I'm not volunteering to figure out the code. But I'd use it if
you wrote it, Dan.
Aquarius
In article <Pine.SGI.3.95L.97010...@tower.york.ac.uk>, John J Lee spoo'd forth:
: I hope I didn't post this thing last term and forget about it...
: Anyway:
: --
: > x desk
: The desk contains a fascinating Widget.
: > take it
: You can't do that to the desk!
: --
: D'oh! Surely there's some way of stopping this.
doesn't setit(widgetItem) work? This is TADS, btw; I know absolutely
nothing about Inform. (Sorry, Mr Nelson - still haven't got round to
looking at it :)
Aquarius
--
"The grand plan that is Aquarius proceeds apace." - 'Ronin', Frank Miller.
----aqua...@cryogen.com | http://www.netforward.com/cryogen/?aquarius----
I would not bet against the existence of time machines. My opponent might
------ have seen the future and know the answer. - Stephen Hawking -------
Gareth Rees
Andrew Plotkin <erky...@netcom.com> wrote:
> itobj = widget;
`ResetVagueWords(widget);' is a better way of making pronouns refer to
the widget (it copes correctly if the widget is animate and/or female).
--
Gareth Rees
Julian Arnold
In article <Pine.SGI.3.95L.97010...@tower.york.ac.uk>,
John J Lee <URL:mailto:jjl...@york.ac.uk> wrote:
>
>
> I hope I didn't post this thing last term and forget about it...
>
> Anyway:
> --
> > x desk
>
> The desk contains a fascinating Widget.
>
> > take it
>
> You can't do that to the desk!
> --
> D'oh! Surely there's some way of stopping this.
My language of choice is Hugo. :)
You achieve this with the AssignPronoun routine:
object desk "desk"
{
long_desc {
"The desk contains a fascinating Widget."
AssignPronoun(widget)
}
...
}
This is open to the same problems as Andrew Plotkin pointed out in his Inform
answer.
Jools
--
"For small erections may be finished by their first architects; grand
ones, true ones, ever leave the copestone to posterity. God keep me
from ever completing anything." -- Herman Melville, "Moby Dick"
Adam Dawes
Hi John!
JJL> --
>> x desk
JJL> The desk contains a fascinating Widget.
>> take it
JJL> You can't do that to the desk!
JJL> --
JJL> D'oh! Surely there's some way of stopping this.
This is sometimes frustrating, but how is the program to know which "it" you
are talking about? How about this:
> x tin
In the tin is a biscuit
> take it
..which item have you asked to take? I certainly don't know, and neither would
the program, it's too ambiguous.
I suppose it could default to a referenced object if the primary object is
static/scenery..?
.\dam. [Team AMIGA] //\ Ad...@darkside.demon.co.uk \//
> Homepage at http://www.geocities.com/TimesSquare/1225/
Brendan Lane
Erik Max Francis <m...@alcyone.com> wrote:
>John J Lee wrote:
>> Anyway:
>> --
>> > x desk
>>
>> The desk contains a fascinating Widget.
>>
>> > take it
>>
>> D'oh! Surely there's some way of stopping this.
>
>conversation this ambiguity would be resolved to DESK not WIDGET.
Hmmmm...It appears to me that there are two different interpretations
of the IF here. John seems to view the IF session as a conversation
between player and computer, whereas Erik seems to be seeing it as a
series of commands carried out by the computer. If the game really is
just a series of commands, then
----
> x desk
The desk contains a fascinating Widget.
> take it
You can't do that to the desk!
----
is certainly correct. However, if the game is more of a conversation between
player and parser, then the exchange
----
> x desk
The desk contains a fascinating Widget.
> take it
Taken.
----
is correct, as the last thing referred to _in_the_conversation_ is the Widget.
I suppose it's all in how you view the game. Though, in any case, this:
----
> x desk. take it.
The desk contains a fascinating Widget.
You can't do that to the desk!
----
should be the proper exchange in either case. So, is this last possible? Can
we distinguish between two commands issued on two lines and two commands
issued at the same time? In the first case, the last thing referred to is the
Widget. In the latter, we haven't been told about the Widget yet, so we must
be talking about the desk. Hmmm...
Brendan Lane.
--
Words are indeed the most powerful invention | laneb @ cpsc.ucalgary.ca |
of all; even the slow, stupid, and | that's |
simple-minded can use them to great effect. | The University of Calgary|
- Brendan Lane | 'The Barbarian West' |
DaveK
Erik Max Francis wrote:
>
> John J Lee wrote:
>
> > > x desk
> >
> > The desk contains a fascinating Widget.
> >
> > > take it
> >
> > You can't do that to the desk!
> > --
> > D'oh! Surely there's some way of stopping this.
>
> But you asked to TAKE THE DESK, not TAKE THE WIDGET. Even in normal
> conversation this ambiguity would be resolved to DESK not WIDGET.
... in normal conversation......
A: The local cinema is showing a great new film.
B: Let's go and watch it then.
A: Why? It's a pretty dull-looking building that just sits there doing
nothing?
... nahh, that's not how _my_ normal conversations resolve their
ambiguity...
... errm well actually I do answer questions like that sometimes...
... but only when I'm being facetious....
[BTW:] Greetings all, I'm new to this group; My name is Dave, I'm a
long-time
I-F fan, and I generally have the correct^H^H^H^H^H^H^H^H^H^H^H an
opinion on
any subject you care to name.. so I expect you'll see me popping up now
and
again. Oh, and I've just recently downloaded Inform and various of the
interpreters, and would like to thank Graham Nelson and all the others
who
have worked hard on ports. Much respects, people. It's good stuff!
cya,
DaveK.
Joe Mason
"annoying pronouns", declared John J from the Vogon ship:
JJ>> x desk
JJ>The desk contains a fascinating Widget.
JJ>> take it
JJ>You can't do that to the desk!
JJ>--
JJ>D'oh! Surely there's some way of stopping this.
In _In The End_ I occasionally set the pronouns manually (ie. when Annie
first appears I have the line "herobj = Annie" so that you can refer to
her as "her" immediately). But I didn't do it systematically. Perhaps
it could be done in the libraries, but I'm not sure where to put it
exactly.
Joe
Avrom Faderman
The fact is, binding pronouns properly is really really hard to
automate. I'd actually guess it's simply beyond the state of the art
in natural language processing in general; in fact, IIRC, as of 4
years ago at least, there was not even a feeling in the _theoretical_
linguistics community that a good account of how it worked would come
out any time soon.
Some illustrations of just how hard the problem is, although some
others have already been given elsewhere in this thread:
In article <32D6B4...@soundcraft.co.uk.trim.these.last.five.words>,
DaveK <Da...@soundcraft.co.uk.trim.these.last.five.words> wrote:
[snip]
>... in normal conversation......
>
>A: The local cinema is showing a great new film.
>
>B: Let's go and watch it then.
And points out that "it" is bound to "film," not "cinema."
Now, note 1: This isn't just because "film" came after "cinema."
A: There's a great new film playing at the local cinema.
B: Let's go and watch it then.
Someone earlier in this thread suggested that the _appropriateness_ of
applying the verb to the various possible antecedents was what was
important--they used this to explain why
Put chocolate in box. Close it.
Put chocolate in box. Eat it.
Had different antecedents for "it"--one eats chocolates but closes
boxes.
But appropriateness can be disturbingly contextual. We might think
that "it" in both of the previous cases refers to the movie rather
than the building because, generally, one watches movies, not
buildings. But consider:
Detective A: I here the drug deal's going down outside the theater
where they're showing that new film.
Detective B: Let's watch it then.
It's not simply a matter of what sorts of things generally get watched
and what sorts of things don't. It's a matter that depends seriously
on the context of use; what the goals of the individuals
participating (in this case; other individuals' goals might be
relevant in other cases) would make it reasonable to want to watch.
Unless an IF game can figure this sort of thing out about its player,
I think any expectation that it will deal with pronouns in a diverse
set of cases realistically is one that is unmeetable. I think that a
convention of the sort we have--where a pronoun is bound to the last
agreeing noun used by the player--is a reasonable convention to use.
It will cause an occasional compromise of fluency of the parser, but
at least it's one that's easily predictable and avoidable by the
player. Complex attempts to bind pronouns, unless they actually
succeed, will occasionally lead to the parser's acting in apparently
random ways.
Just my belief, of course. Wouldn't want to be one of those people
being maligned over on r.g.i-f.
-Avrom
Jason B Dyer
DaveK (Da...@soundcraft.co.uk.trim.these.last.five.words) wrote:
: > But you asked to TAKE THE DESK, not TAKE THE WIDGET. Even in normal
: > conversation this ambiguity would be resolved to DESK not WIDGET.
: ... in normal conversation......
: A: The local cinema is showing a great new film.
: B: Let's go and watch it then.
: A: Why? It's a pretty dull-looking building that just sits there doing
: nothing?
A: This package has the new fishbowl in it, sir.
B: Great, put it on the shelf.
A: But I haven't opened the package yet! You're supposed to do that.
English is a tricky language, yes?
Jason Dyer
jd...@u.arizona.edu
Andrew Plotkin
Jason B Dyer (jd...@mustique.u.arizona.edu) wrote:
> DaveK (Da...@soundcraft.co.uk.trim.these.last.five.words) wrote:
> : > But you asked to TAKE THE DESK, not TAKE THE WIDGET. Even in normal
> : > conversation this ambiguity would be resolved to DESK not WIDGET.
> : ... in normal conversation......
> : A: The local cinema is showing a great new film.
> : B: Let's go and watch it then.
> : A: Why? It's a pretty dull-looking building that just sits there doing
> : nothing?
> A: This package has the new fishbowl in it, sir.
> B: Great, put it on the shelf.
> A: But I haven't opened the package yet! You're supposed to do that.
So, what does normal conversation have to do with IF anyway?
On a different note, there *are* times when it's good to set the "it"
manually.
* When one object transforms into another
* When you trade one object for another ("You hand the coin to the
vendor; he places the banana on the counter.")
* When an object is explicitly offered to you ("A genie appears and holds
out a glowing wand.")
Erik Max Francis
Brendan Lane wrote:
> Hmmmm...It appears to me that there are two different interpretations
> of the IF here. John seems to view the IF session as a conversation
> between player and computer, whereas Erik seems to be seeing it as a
> series of commands carried out by the computer.
No, I'm not seeing it that way; that's what "Take it" means in plain
English. Even in this context there's no way that a _human_ could be sure
what the command referred to. After all, "Examine the desk. Take it" is
the same as "Examine the desk, and then take it." This means, in plain
English, tell me something about the desk, and then pick the desk up.
Context-sensitive pronouns are a terribly bad idea for a number of reasons.
For instance,
-----
> EXAMINE THE BOOKSHELF
The bookshelf is old and dusty. Contained on it are volumes by Vonnegut,
Clarke, Asimov, Niven, and a strange notebook wrapped in rubber bands.
> TAKE IT
What do you mean, the bookshelf, the volume by Vonnegut, the volume by
Clarke, the volume by Asimov, the volume by Niven, or the strange notebook?
-----
There's no way a human could understand what this would mean, let alone a
computer. Take an even more mundane example:
-----
> LOOK
On the floor is a paper bag.
> EXAMINE THE PAPER BAG
The paper bag contains a beer can (empty).
> TAKE IT
Taken.
-----
Okay, now what did it take, the paper bag or the beer can?
In plain English, the pronoun _it_ means "the last thing I referred to
directly." If you say, in English, "The desk contained a widget, but it
wasn't made of wood," do I mean the desk was red or the widget? I mean the
desk, obviously.
In addition, the contraction case I was talking about earlier, you could
combine them in one sentence:
> LOOK
> EXAMINE THE PAPER BAG. TAKE IT
The paper bag conatins a beer can (empty).
Taken.
-----
If _it_ refers to the last signficant thing mentioned in a description
(i.e., it's context-sensitive) then you've got a real problem; commands can
change meaning without anything happening, simply by substitution of
pronouns.
This is unacceptable -- pronouns should refer to the last thing that the
player referred to, not the last thing that was described.
London David
In article <5b77ig$k...@news.ccit.arizona.edu> jd...@mustique.u.arizona.edu
>DaveK (Da...@soundcraft.co.uk.trim.these.last.five.words) wrote:
>: > But you asked to TAKE THE DESK, not TAKE THE WIDGET. Even in normal
>: > conversation this ambiguity would be resolved to DESK not WIDGET.
>
>: ... in normal conversation......
>: A: The local cinema is showing a great new film.
>: B: Let's go and watch it then.
>: A: Why? It's a pretty dull-looking building that just sits there doing
>: nothing?
>
>A: This package has the new fishbowl in it, sir.
>
>B: Great, put it on the shelf.
>
>A: But I haven't opened the package yet! You're supposed to do that.
>
Yeah, and this is the basis of one of the running gags in the Airplane!
and Police Squad series:
A: Quick, take me to the hospital!
B: The hospital? What is it?
A: It's a big building with doctors and patients, but that's not important
right now.
David London
Nulldogma
> Detective A: I here the drug deal's going down outside the theater
> where they're showing that new film.
> Detective B: Let's watch it then.
Or, of course (famously):
"We need to get this man to a hospital!"
> WHAT IS IT?
"It's a big building with doctors in it, but that's not important right
now..."
Chuan-Tze Teo
Avrom Faderman wrote:
> Unless an IF game can figure this sort of thing out about its player,
> I think any expectation that it will deal with pronouns in a diverse
> set of cases realistically is one that is unmeetable. I think that a
> convention of the sort we have--where a pronoun is bound to the last
> agreeing noun used by the player--is a reasonable convention to use.
> It will cause an occasional compromise of fluency of the parser, but
> at least it's one that's easily predictable and avoidable by the
> player. Complex attempts to bind pronouns, unless they actually
> succeed, will occasionally lead to the parser's acting in apparently
> random ways.
On the other hand, I think it feels much more fluid if after examining a
table and finding a piece of paper on it, I can 'read it' and not have
the parser tell me "You can't read a table" or something of that sort. I
think the only realistic solution to this problem is for each object to
be considered and hacked on an individual basis... (very silly transcript
follows)
(start of game)
Boring Room
You are in a boring room. There is a table here. There is a policeman
here.
[itobj is set to the table as it's the only sensible object]
[and 'him' is set to the policeman]
>X HIM
He is a policeman. He is carrying a gun.
[itobj set to gun]
>X IT
It's a gun.
>ASK HIM ABOUT TABLE
The policeman offers no reply.
>X TABLE
It's a table.
There is a piece of paper on it.
[itobj is set to the paper, but make sure this is done only once;
otherwise we get problems if we want to do X TABLE. PUSH IT later on]
>READ IT
"The table is fragile. This note will self-destruct in five seconds."
The piece of paper disappears in a puff of green smoke.
[itobj is set to the table, since the paper is no longer accessible; if
it could be picked up, then it would be better to leave it]
>KICK IT
You destroy the table. Unfortunately, the policeman spots you! You are
summarily shot on the spot for vandalism.
*** You have died ***
On a serious note, I think allowing this sort of use of "it" in clear-cut
cases does add to a game. I always find the desk example which started
this thread slightly annoying when I run into it in games.
- Chuan
Russ Bryan
In article <32D80C...@hermes.cam.ac.uk>, Chuan-Tze Teo
<ct...@hermes.cam.ac.uk> wrote:
> The policeman offers no reply.
>
> >X TABLE
>
> It's a table.
>
> There is a piece of paper on it.
>
> [itobj is set to the paper, but make sure this is done only once;
> otherwise we get problems if we want to do X TABLE. PUSH IT later on]
>
> >READ IT
>
> "The table is fragile. This note will self-destruct in five seconds."
>
> The piece of paper disappears in a puff of green smoke.
>
> [itobj is set to the table, since the paper is no longer accessible; if
> it could be picked up, then it would be better to leave it]
>
> >KICK IT
>
> You destroy the table. Unfortunately, the policeman spots you! You are
> summarily shot on the spot for vandalism.
It just won't happen. I've played the game before, so I don't want to read
the piece of paper; I just want to push the table and get it over with.
There are two desks in the room, or a desk and a chair, and how do you know
that I don't want to push the chair instead? What if there is a piece of
paper, a gun, and a bowl of oatmeal on the desk?
I see what you're saying, but I don't think it's correct. Andrew Plotkin's
recommendations (morphing an item, exchanging an item, or being handed an
item) cover most occasions where "it" can be considered necessary. They
are situations where EVERYONE will agree on what "it" refers to. Look over
your examples and change them so they aren't quite so neatly designed for
your thesis, and I think you'll see what I mean.
ã Russ
Jason L Tibbitts III
>>>>> "EMF" == Erik Max Francis <m...@alcyone.com> writes:
EMF> After all, "Examine the desk. Take it" is the same as "Examine the
EMF> desk, and then take it."
Does it? The intervening text might shift focus completely away from the
desk.
I don't see why it wouldn't be an acceptable solution to attempt to
disambiguate as much as possible, then ask the user to choose among the
ambiguous objects. When presented with a scene describing a tall building
and a letter on the floor, there is little point in forcing the user to
inform the game that 'it' refers neither to the floor nor to the building.
It's possible, though, that this reduces to the 'get all' question.
--
Jason L. Tibbitts III - ti...@uh.edu - 713/743-8684 - 221SR1
System Manager: University of Houston High Performance Computing Center
1994 PC800 "Kuroneko" DoD# 1723
aul...@koala.scott.net
>On a different note, there *are* times when it's good to set the "it"
>manually.
>
>* When one object transforms into another
>* When you trade one object for another ("You hand the coin to the
>vendor; he places the banana on the counter.")
>* When an object is explicitly offered to you ("A genie appears and holds
>out a glowing wand.")
I like these suggestions, but there is one thing that concerns me.
This is fine:
------
>RUB LAMP
A genie appears and holds out a glowing wand.
>TAKE IT
The wand glows brighter as you take it.
(Although, if you want to drop the lamp after rubbing it, DROP IT will
fail. Fair trade? I guess so.)
------
This is not:
------
>DROP DYNAMITE
Dropped.
>LIGHT MATCH
Done.
A genie appears and holds out a glowing wand.
>LIGHT FUSE WITH IT
You don't have the wand.
The match burns down to your fingertips and goes out.
>SCREAM
Aaaarrrrgggghhhh!
(Actually, this example is a little dishonest, because time wouldn't
elapse after the failed command.)
------
The point is, I don't want a set plan derailed by some random outside
event that just happens to occur while I'm in the middle of doing
something.
In other words, don't change what "it" refers to except in direct
response to something I have done, and then only when it's bleedingly
obvious.
Infocom did this at least once, as in the following paraphrase of
Spellbreaker.
-------
>DROP MAGIC CARPET
Done.
In the distance, you see a giant Roc flying toward you.
>SIT ON IT
You can't reach the Roc from here.
--------
I think Infocom was getting pretty happy with the antecedent shifting
at this point in their history. This is an example where they seemed to
take it too far. I don't like daemon-spawned events messing with my
pronouns.
That's all,
Joe -- as always, IMHO, YMMV, etc. I wouldn't want to appear pre-pubescent
and arrogant and whatever other hooey *some people* might think
otherwise. Oh yeah, I almost forgot the most important part -- =)
John J Lee
On Sat, 11 Jan 1997, Chuan-Tze Teo wrote:
[...]
> table and finding a piece of paper on it, I can 'read it' and not have
> the parser tell me "You can't read a table" or something of that sort. I
> think the only realistic solution to this problem is for each object to
> be considered and hacked on an individual basis... (very silly transcript
> follows)
Yeah, my original post probably wasn't very clear:
I was just putting in a plea for authors to remember this, not asking how
to implement it, and I was only referring to one really specific case:
> take the fascinating newly-revealed intruiging thingy "it" from the
fixed-in-place, utterly immovable and uninteresting object.
But that's fixed in place!
I seem to run into this one almost every time I play a game.
Still, it might be an idea to make all kinds of exceptions of the kind
Chuan-Tze lists. Personally, I'm all for as many exceptions as can be
squeezed in, almost anywhere in a game. Most of the time it's clear to a
human what the player wants, so you can stick in an exception.
But you're not carrying the stick!
Chuan-Tze Teo
>The point is, I don't want a set plan derailed by some random outside
>event that just happens to occur while I'm in the middle of doing
>something.
>In other words, don't change what "it" refers to except in direct
>response to something I have done, and then only when it's bleedingly
>obvious.
IMO "it" is there for two main purposes- 1) immediately repeated
actions with the same object (i.e. GET ITEM. USE IT) and 2) making the
player's input more like natural English conversation. I don't see
that adherence to "existing convention" is a good thing in itself. In
fact I would definitely be more annoyed in your Spellbreaker example
if "X IT" threw up a description of the carpet. I almost expect
important daemon-generated events (something materialises in
front of you) to change the meaning of "it" as I would if someone had
brought up a new topic in a conversation.
The main problem with the style I am advocating is player-issued
"chain commands" such as the reasonably common X DESK. SEARCH
IT. LOOK UNDER IT. If the parser splits this into three commands and
translates them one after the other, there may be disconcerting results
even in clear-cut cases such as those Andrew Plotkin listed a while
back. If "it" is first translated into "desk" before execution, this
particular problem is prevented.
(Hmm. Which style does the Inform parser use?)
- Chuan
Erik Max Francis
Jason L Tibbitts III wrote:
> EMF> After all, "Examine the desk. Take it" is the same as "Examine the
> EMF> desk, and then take it."
>
> Does it? The intervening text might shift focus completely away from the
> desk.
My point was that in most interaction fiction parsers, you can queue up
multiple orders in one line by using end-of-sentence periods.
So
> EXAMINE THE DESK. TAKE IT
does the same thing as
> EXAMINE THE DESK
...
> TAKE IT
Now if the description of what's on the desk substitutes something (say, a
widget) for that pronoun _it_, then you have a problem, because the meaning
of the pronoun has changed _after_ you gave the order to TAKE IT but before
that order was executed. That's not reasonable, because it means that
queueing up orders is useless, since you don't know when contexts are going
to change between the queued orders.
> It's possible, though, that this reduces to the 'get all' question.
Right. Yes, there are possible things that you could do to remedy the
situation to make it seem more natural for some people (but not for others,
since the idea of substituting pronouns is a very subjective thing). But
then you run into problems with context switches, and you'd have to take
them into account, etc.
The bottom line is that although in some very limited circumstances it
might be clear what's going on, but in generaly it is an intractible
problem and in my opinion is makes things far messier.
--
Erik Max Francis | m...@alcyone.com
Alcyone Systems | http://www.alcyone.com/max/
San Jose, California | 37 20 07 N 121 53 38 W
&tSftDotIotE | R^4: the 4th R is respect
"You must surely know if man made heaven | Then made made hell"
Linards Ticmanis
There was a discussion here about the following case:
__
> search drawer and then look under it
In the drawer, you find a large assortment of pencils ranging in
hardness from coal dust in a wooden tube to something rather appropriate
to poke holes into vandal-proof steel classroom desks. Clearly the
person who worked here until recently must have been into professional
drawing (or maybe just in search of new chewing experiences, from the
way most of the pencil's back ends look).
There's nothing under the assortment of pencils (besides a few wet spots
on the wood)
__
Thus missing the secret testament donating the artist's works to the
local "Museum of Distemporary Art" that was glued under the drawer to
hide it from his greedy son-on-law.
My solution here would be to have two "it" variables, one that is being
set and another one that is being referred to. Only when a prompt is
issued would these two be put back into sync again. Then "it" could be
set fairly generally whenever an object of some importance is mentioned
(e.g. anything that isn't just SCENERY).
Generally disambiguation should be improved: one would OPEN only stuff
that is OPENABLE but not OPEN, for example, so just typing OPEN should
select such an object if there is one.
--
Linards Ticmanis
<A HREF="mailto:tic...@reze-1.rz.rwth-aachen.de">
tic...@reze-1.rz.rwth-aachen.de</A>
<BRIBE> me. I'll leave.
aul...@koala.scott.net
In article <ctt20.327...@hermes.cam.ac.uk>,
Chuan-Tze Teo <ct...@hermes.cam.ac.uk> wrote:
>IMO "it" is there for two main purposes- 1) immediately repeated
>actions with the same object (i.e. GET ITEM. USE IT) and 2) making the
>player's input more like natural English conversation.
>I don't see
>that adherence to "existing convention" is a good thing in itself.
Not sure what you mean by this. Was I advocating this? I didn't THINK
I was, but... (I'm not even aware what the existing convention is, if
there is one.)
>In
>fact I would definitely be more annoyed in your Spellbreaker example
>if "X IT" threw up a description of the carpet.
But this is a direct contradiction of what you said in point 1) above.
Now you're saying that DROP CARPET then X IT should _not_ give a
description of the carpet.
>I almost expect
>important daemon-generated events (something materialises in
>front of you) to change the meaning of "it" as I would if someone had
>brought up a new topic in a conversation.
I see your point, but my Spellbreaker example was about something that
appears IN THE DISTANCE, and might possibly be ignored as simple
atmosphere. It's as if Nine Points did something like this:
------
Darkness
It is pitch dark, and you can't see a thing.
>TURN ON LAMP
You fumble over the lamp's surface; it takes a few moments before you
feel the switch. The lantern starts humming as it lights up.
Treasure Vault
A thick layer of dust covers everything in this room. There are many
old boxes and older bags. Your uncle's bedroom lies to the west.
Your uncle's treasure chest sits here, tightly closed.
A scratching sound in the rafters unnerves you.
>DROP IT
You're not holding the scratching sound.
------
The genie example I gave, where it interrupts what you're doing is a
what-if scenario. What if I were already poised to type LIGHT FUSE
WITH IT when the genie appeared (like the Wizard of Frobozz or the
Jester) and I decided to go ahead with what I was doing and worry about
the genie on my next turn? Or if I just typed all the commands of a
sequence quickly, then read the results of all of them afterward?
>The main problem with the style I am advocating is player-issued
>"chain commands" such as the reasonably common X DESK. SEARCH
>IT. LOOK UNDER IT.
Are you suggesting that a game should behave differently if a person
separates commands with periods instead of carriage returns?
That's a bold suggestion, but not one I can entirely disagree with.
>If the parser splits this into three commands and
>translates them one after the other, there may be disconcerting results
>even in clear-cut cases such as those Andrew Plotkin listed a while
>back. If "it" is first translated into "desk" before execution, this
>particular problem is prevented.
I would hope that if an author thinks that an event is significant enough
to shift the pronouns around, then it is significant enough to stop a
chain of commands. (i.e. DROP CARPET. SIT ON IT would never even attempt
SIT ON IT.)
>(Hmm. Which style does the Inform parser use?)
Umm... Graham?
That is all,
Joe
aul...@koala.scott.net
Erik Max Francis <m...@alcyone.com> wrote:
>In plain English, the pronoun _it_ means "the last thing I referred to
>directly." If you say, in English, "The desk contained a widget, but it
>wasn't made of wood," do I mean the desk was red or the widget? I mean the
>desk, obviously.
While I think I agree with you for the most part on the broad issue, I'm
not so sure about this paragraph (confusion about woodenness vs. redness
aside). In plain English, _it_ does not necessarily refer to the last
thing any one person mentioned, but more or less the most obvious point
of conversation. Consider your statement as a response to these two
statements:
"I'm looking for a wooden widget."
"I'm looking for a wooden object that contains a widget."
It's not so obvious you mean the desk, even if your statement is said
by itself and not as a response to these statements.
It is due to this ephemeral nature of the pronoun _it_ that I have said
that, since would be impossible in many common situations to tell what
the player means, that a game should show considerable reserve in shifting
the antecedent from the last object referred to, if it ever does at all.
All in all, I think it was probably a mistake to introduce the word to
the environment at all. It adds many more problems than it solves, and
these problems will not be solved until the computer can interpret the
inflection of voice input, or it can read the player's mind.
That is all,
Joe
Dave Gatewood
aul...@koala.scott.net wrote:
> The point is, I don't want a set plan derailed by some random outside
> event that just happens to occur while I'm in the middle of doing
> something.
I agree with this viewpoint wholeheartedly. In fact I'd raise it to
another level. I would prefer that the game NEVER change the pronoun.
At least this way I always know what the pronoun is. Every other method
presented here is ad hoc - "okay, for this situation we'll reset the it
object, but for that one we won't." This would be more annoying than
the existing situation, because I don't know what the rules are. Even
simple, seemingly innocuous rules will spawn a host of simple, seemingly
innocuous counterexamples. The only way to keep it simple is to leave
the player in control of the pronouns.
I've noticed that (I believe for the first time) the latest Inform
library resets the it object when the player enters a room
(specifically, to the youngest child of the room). Example:
[Begin transcript.]
>GET POT OF GOLD
Taken.
>E
Clearing
Your lamp is here, glowing dimly.
On the ground is a pile of leaves.
>COUNT IT
69,105.
[End of transcript.]
A harmless enough feature, sometimes. But the assumption that the room
description is really part of the conversation is rarely correct after
the first 2 or 3 times through a room. I always play in verbose mode -
but obviously I don't re-read the room description every time I pass
through the Attic. So to change the pronoun based on something I
*didn't* read is really confusing.
Not infrequently I find myself doing something like this:
[Begin transcript.]
>GET ROD
Taken.
>STRIKE IT. POINT IT AT GROUND.
The ground trembles a bit, but nothing happens. Perhaps the ground is
too stable here.
>N
Another Room
There is a delicate Ming vase here.
>STRIKE IT. POINT IT AT GROUND.
In a fit of sudden rage, you smash the vase to bits.
I don't see that here.
[End of transcript.]
Okay, it's another dumb example, but it arises in one form or another in
a lot of i-f games. If I find a water balloon, the first thing I'm
gonna do is wander around from room to room typing "THROW IT AT
[OBJECT]" until I find the right target.
Dave
Nulldogma
So how hard would it be to modify existing languages to require
disambiguation of "it" in these circumstances? Or, in TADSspeak, to allow
itobj to point to a list rather than a specific object?
Dave Gatewood
aul...@koala.scott.net wrote:
>
> In article <ctt20.327...@hermes.cam.ac.uk>,
> Chuan-Tze Teo <ct...@hermes.cam.ac.uk> wrote:
>
> >The main problem with the style I am advocating is player-issued
> >"chain commands" such as the reasonably common X DESK. SEARCH
> >IT. LOOK UNDER IT.
>
> Are you suggesting that a game should behave differently if a person
> separates commands with periods instead of carriage returns?
> That's a bold suggestion, but not one I can entirely disagree with.
Too bold for me. Treating chained commands differently would just add
even more confusion. Personally, I never use chain commands. Instead,
if I have a string of actions, I just quickly type each command, hit
enter, type the next one, enter, boom boom boom without stopping to
catch my breath (just like I think most of us do when entering N, N, E,
N, NE, D). I've "essentially" just entered a chain of commands, as if I
had entered them on one line - but I'll get different treatment than if
I had done it with periods.
It's these everpresent ambiguities and special cases which make me think
the whole noble attempt should be discarded.
Dave
Andrew Plotkin
Nulldogma (null...@aol.com) wrote:
> So how hard would it be to modify existing languages to require
> disambiguation of "it" in these circumstances? Or, in TADSspeak, to allow
> itobj to point to a list rather than a specific object?
You know, all I ever wanted was to be able to type "it" instead of "large
purple snorkelwhacker" five times in a row...
If I have to go through a disambiguation prompt every time, I'm going to
start crying.
(This was more relevant before GUI cut-and-paste interfaces, but *still*!)
I'm kind of dumbfounded by the claim that adding "it" to the environment
was a mistake... Whatever problems it adds, the problem it solves is a
honking big one. And the current solution is very easy to get used to,
*because* it's so simple-minded and consistent.
Nulldogma
Andrew Plotkin wrote:
> Nulldogma (null...@aol.com) wrote:
> > So how hard would it be to modify existing languages to require
> > disambiguation of "it" in these circumstances? Or, in TADSspeak, to
allow
> > itobj to point to a list rather than a specific object?
>
> You know, all I ever wanted was to be able to type "it" instead of
"large
> purple snorkelwhacker" five times in a row...
>
> If I have to go through a disambiguation prompt every time, I'm going to
> start crying.
Well, we can't have that.
But I wasn't suggesting that we force players to go through a
disambiguation prompt every time. Just that we allow programmers to allow
for disambiguation in, well, ambiguous cases (like all that stuff about
desks and widgets).
If people are going to be screwing around with their itobj's, I'd rather
they screw with them in a way that allows me (the player) to say what I
mean, rather than throw genies in where I want carpets.
If that's possible.
Jason Melancon
On Tue, 14 Jan 1997 11:22:48 -0800, Erik Max Francis <m...@alcyone.com>
wrote:
> My point was that in most interaction fiction parsers, you can queue up
> multiple orders in one line by using end-of-sentence periods.
> > EXAMINE THE DESK. TAKE IT
>
> does the same thing as
>
> > EXAMINE THE DESK
>
> ...
>
> > TAKE IT
>
> Now if the description of what's on the desk substitutes something (say, a
> widget) for that pronoun _it_, then you have a problem, because the meaning
> of the pronoun has changed _after_ you gave the order to TAKE IT but before
> that order was executed.
> The bottom line is that although in some very limited circumstances it
> might be clear what's going on, but in generaly it is an intractible
> problem and in my opinion is makes things far messier.
How about this idea, just out of the blue:
In conversation, if someone brings up a new concept or something, we
say, for example, "What's that?" something else with "that," not
"it." Do we need a new word here as well?
If people want to use a pronoun for something like
the-last-noun-in-the-conversation-of-the-game, why not use "that"? Of
course, it would only really fit in certain cases, where only one new
object is mentioned, like the widget on the desk, or when the last
thing mentioned is very important, obviously more so than the rest of
the text. We'd still need to use discretion programming it, but it
gets around a couple dilemmas. Useful enough to add a new construct?
I'm not a linguist, so I don't know if this "it/that" distinction is
very translatable.
> --
> Erik Max Francis | m...@alcyone.com
> Alcyone Systems | http://www.alcyone.com/max/
> San Jose, California | 37 20 07 N 121 53 38 W
> &tSftDotIotE | R^4: the 4th R is respect
> "You must surely know if man made heaven | Then made made hell"
Jason Melancon
Andrew Plotkin
Nulldogma (null...@aol.com) wrote:
> Andrew Plotkin wrote:
> > Nulldogma (null...@aol.com) wrote:
> > > So how hard would it be to modify existing languages to require
> > > disambiguation of "it" in these circumstances? Or, in TADSspeak, to
> allow
> > > itobj to point to a list rather than a specific object?
> >
> > You know, all I ever wanted was to be able to type "it" instead of
> "large
> > purple snorkelwhacker" five times in a row...
> >
> > If I have to go through a disambiguation prompt every time, I'm going to
> > start crying.
> Well, we can't have that.
> But I wasn't suggesting that we force players to go through a
> disambiguation prompt every time. Just that we allow programmers to allow
> for disambiguation in, well, ambiguous cases (like all that stuff about
> desks and widgets).
It *would* be every time, inevitably, in some reasonable game situations.
I could make up an example here to demonstrate, but I'll spare you. Right
now, there are no ambiguous cases (except in some very technical
situations, which haven't even come up yet, which are better regarded as
bugs than "it" behaviors.) If the semantics of "it" change, so that
suddenly there are ambiguous cases, do you see where this gets annoying?
From elsewhere:
> In conversation, if someone brings up a new concept or something, we say,
> for example, "What's that?" something else with "that," not "it." Do we
> need a new word here as well?
However, that (no pun intended) is a very nice idea. "that" is the last
thing the game mentioned; "it" is the last thing you mentioned. It's
harder to get "that" right, but old-fashioned players (like me) have no
expectations for it, so it's an all-around win.
Anyone want to try to implement it?, Er, that?
Matthew Amster-Burton
erky...@netcom.com (Andrew Plotkin) wrote:
>You know, all I ever wanted was to be able to type "it" instead of "large
>purple snorkelwhacker" five times in a row...
Wait, I honestly want to type "snorkelwhacker" many, many times. More
to the point, I want to *say* "snorkelwhacker." There, now I feel
better.
We now return you to your regularly scheduled pronominal discussion.
Matthew
Erik Max Francis
aul...@koala.scott.net wrote:
> Are you suggesting that a game should behave differently if a person
> separates commands with periods instead of carriage returns?
> That's a bold suggestion, but not one I can entirely disagree with.
It is unacceptable for the meaning of a pronoun to change in a chained
command. If you're going to have the pronoun modification, then you're
going to have to disable it during chained commands. Which makes yet
another complication to the idea.
> I would hope that if an author thinks that an event is significant enough
> to shift the pronouns around, then it is significant enough to stop a
> chain of commands. (i.e. DROP CARPET. SIT ON IT would never even attempt
> SIT ON IT.)
The easier solution is to not use pronoun context changing at all. There
are good reasons not to bother: How many people are genuinely _confused_
when IT refers to the last thing they themselves referenced? Furthermore,
there are many ambiguous cases where you cannot know what the player means,
and moreover, there are many conditions where a human mind would very
clearly see the correct answer but without powerful natural language
processing it would be impossible for the computer to know. And if it's
programmed directly in when pronoun switches take place, it then becomes
totally unreliable to use pronouns, because you never know when they're
going to switch on you. It has to be automatic for it to work as expected,
and it's not feasible to make it automatic.
By contrast, how many people are genuinely confused or taken aback when
TAKE IT refers to the table and not something that just appeared in the
room?
--
Erik Max Francis, &tSftDotIotE / email: m...@alcyone.com
Alcyone Systems / web: http://www.alcyone.com/max/
San Jose, California, United States / icbm: 37 20 07 N 121 53 38 W
\
"Gods are born and die, / but the atom endures."
/ (Alexander Chase)
Nulldogma
Andrew Plotkin wrote:
> It *would* be every time, inevitably, in some reasonable game
situations.
> I could make up an example here to demonstrate, but I'll spare you.
Right
> now, there are no ambiguous cases (except in some very technical
> situations, which haven't even come up yet, which are better regarded as
> bugs than "it" behaviors.) If the semantics of "it" change, so that
> suddenly there are ambiguous cases, do you see where this gets annoying?
No.
If you're going to mess around with "it" at all, I'd rather mess around
with it to disambiguate, rather than to switch "it" entirely to a
different object.
I know that you, as a programmer, don't want to mess with "it" ever.
That's fine, and I probably agree with you. (Having it refer to the last
item mentioned by the player is a damn fine standard, and it leads the
player blame themselves if they get it wrong, which is a good thing.) I
was just wondering if it was *possible* to have it point to a list, not a
single item, without hacking the current libraries to shreds.
I'm still wondering.
>
> From elsewhere:
>
> > In conversation, if someone brings up a new concept or something, we
say,
> > for example, "What's that?" something else with "that," not "it." Do
we
> > need a new word here as well?
>
> However, that (no pun intended) is a very nice idea. "that" is the last
> thing the game mentioned; "it" is the last thing you mentioned. It's
> harder to get "that" right, but old-fashioned players (like me) have no
> expectations for it, so it's an all-around win.
Except that this bears no particular resemblance to standard English
usage, and so nobody's going to know how to use it unless you tell them
first.
Dan Shiovitz
In article <19970118044...@ladder01.news.aol.com>,
Nulldogma <null...@aol.com> wrote:
[..]
>I know that you, as a programmer, don't want to mess with "it" ever.
>That's fine, and I probably agree with you. (Having it refer to the last
>item mentioned by the player is a damn fine standard, and it leads the
>player blame themselves if they get it wrong, which is a good thing.) I
>was just wondering if it was *possible* to have it point to a list, not a
>single item, without hacking the current libraries to shreds.
>
>I'm still wondering.
One of the things I'm doing in my spare time is messing with the TADS
source to do more or less this. Some (most, hopefully) of the
disambiguation problems can be cut out by using the ver methods, also.
Personally, there's about four cases when I ever want to use pronouns:
> X FOO. TAKE IT.
> PUT FOO IN BOX. CLOSE IT.
> GET FOO AND BAR. PUT THEM IN SACK.
Ok, three. All of these can be handled nicely by storing it as a list
and doing ver-disambiguation on it.
>Neil
--
dan shiovitz scy...@u.washington.edu sh...@cs.washington.edu
slightly lost author/programmer in a world of more creative or more
sensible people ... remember to speak up for freedom because no one else
will do it for you: use it or lose it ... carpe diem -- be proactive.
my web site: http://weber.u.washington.edu/~scythe/home.html some ok stuff.
Erik Max Francis
aul...@koala.scott.net wrote:
> It is due to this ephemeral nature of the pronoun _it_ that I have said
> that, since would be impossible in many common situations to tell what
> the player means, that a game should show considerable reserve in
> shifting
> the antecedent from the last object referred to, if it ever does at all.
That is my point as well. Since in the general case you can't do it
reliably, and in the cases where it is "obvious" (and it isn't obvious to
everyone) what _it_ should now refer to you'd have to program it in
manually, the effect is basically rendering the pronoun _it_ unreliable.
Erik Max Francis
Nulldogma wrote:
> So how hard would it be to modify existing languages to require
> disambiguation of "it" in these circumstances? Or, in TADSspeak, to allow
> itobj to point to a list rather than a specific object?
By that, do you suggest that _it_ should refer to a list of objects? For
example:
> EXAMINE COUNTER
On the counter sits a stapler, a spatula, a coffee maker, a roll of
paper towels, a rice cooker, and a dirty dish.
> TAKE IT
Do you mean the counter, the stapler, the spatula, the coffee maker,
the roll of paper towels, the rice cooker, or the dirty dish?
The whole point of having the pronoun _it_ is to have a quick shorthand to
refer to something unambiguous for convenience. If _it_ simply refers to a
list of _anything_ you might be referring to, then it completely loses its
meaning, since the statement now becomes
> TAKE IT
Do you mean the counter, the stapler, the spatula, the coffee maker,
the roll of paper towels, the rice cooker, or the dirty dish?
> THE STAPLER
Rather than just
> TAKE THE STAPLER
As long as it's made clear that _it_ refers to the last direct object _the
player referred to_, there's no ambiguity.
Nulldogma
Dan Shiovitz wrote:
> One of the things I'm doing in my spare time is messing
> with the TADS source to do more or less this.
Source, or ADV.T?
Nulldogma
But in your example, "it" wouldn't refer to the stapler, anyway, but to
the counter. Let's try another example:
> EXAMINE CARTON
In the carton you see a quantity of milk.
> TAKE IT
Which "it" does the player mean here? Could be either. Leaving "it" as
referring to the carton (the default behavior) is all fine and good, and
actually it's what I prefer in general. But what's the matter with
disambiguating here? It's certainly better than setting "it" to mean the
milk, which is what some people are advocating.
Yeah, sure, this would mean when you said "take it" in an ambiguous
situation, the game would ask you to type some more. But the tradeoff
would be that you wouldn't have players doing:
> X GIANT SCORPION
The giant space scorpion, attuned to your psychic energies, holds out
its claws to offer
you the object of your dreams: a magic glowing sceptre of eternal
bliss.
[player, not confident in how to spell "sceptre," types:]
> TAKE IT
The giant space scorpion rears back at your attempts to capture it,
and quickly stings
you to death with its enormous stinger.
Is this a worthwhile tradeoff? Probably not, and if anyone comes up with a
way to disambiguate "it," there's a good chance I won't use it. But I'd
still like to know if such a thing is *possible*.
John J Lee
On Thu, 16 Jan 1997, Dave Gatewood wrote:
> aul...@koala.scott.net wrote:
> >
> > In article <ctt20.327...@hermes.cam.ac.uk>,
> > Chuan-Tze Teo <ct...@hermes.cam.ac.uk> wrote:
> >
> > >The main problem with the style I am advocating is player-issued
> > >"chain commands" such as the reasonably common X DESK. SEARCH
> > >IT. LOOK UNDER IT.
> >
> > Are you suggesting that a game should behave differently if a person
> > separates commands with periods instead of carriage returns?
> > That's a bold suggestion, but not one I can entirely disagree with.
This list of commands business is a good point - I don't tend to use them
as I always mess them up.
OK. You could:
a) Stop executing the string of commands when something happens.
b) Do this in particular circumstances when you think appropriate (this
in general depends on the rest of the commands, though)
c) 'precompile' a list of commands so you replace 'it' with the standard
(whatever the player last mentioned), and only make these exceptions for
single commands.
d) Say 'player beware'
a) is a bit restrictive, but the modification of this to b) might be
complicated and so practically incomplete, but it might be useful
sometimes. c) is inelegant, and you might want to ban 'it' from
walkthroughs, but this doesn't matter a bit.
I reckon d) is the best answer in most cases - after all, this happens all
the time anyway. Strings of commands almost always go wrong, cf plans in
real life.
I'm not sure about c), but I don't think so.
> Too bold for me. Treating chained commands differently would just add
> even more confusion. Personally, I never use chain commands. Instead,
> if I have a string of actions, I just quickly type each command, hit
> enter, type the next one, enter, boom boom boom without stopping to
> catch my breath (just like I think most of us do when entering N, N, E,
> N, NE, D).
Well what do you expect if you do this? If you walk about with your head
down, you walk into lamp-posts. Unless you know exactly where you are
going, that is, in which case there would be no problem here either!
> I've "essentially" just entered a chain of commands, as if I
> had entered them on one line - but I'll get different treatment than if
> I had done it with periods.
>
> It's these everpresent ambiguities and special cases which make me think
> the whole noble attempt should be discarded.
Oh for heavens sake. That would be giving in!
Remember the original example - leaving *that* as it was would surely be
worse than whatever changing it would cause. People have given some
rather contrived examples of what could go wrong, but the fact is they
would not happen in the rather limited circumstances where you would
actually use it.
Erik Max Francis
Andrew Plotkin wrote:
> I'm kind of dumbfounded by the claim that adding "it" to the environment
> was a mistake... Whatever problems it adds, the problem it solves is a
> honking big one. And the current solution is very easy to get used to,
> *because* it's so simple-minded and consistent.
I totally agree. The use of _it_ is totally unambiguous _unless_ you start
doing all kinds of weird things to make it seem more natural, and it's
guaranteed that you'll never please anybody. In many cases, _it_ will
evaluate to more than one possible reference, in which case the use of it
has been made utterly pointless.
Erik Max Francis
Jason Melancon wrote:
> How about this idea, just out of the blue:
>
> In conversation, if someone brings up a new concept or something, we
> say, for example, "What's that?" something else with "that," not
> "it." Do we need a new word here as well?
It's a good idea (making up a new word, that is), but does this sample
script make sense?
> EXAMINE DESK
On top of the wooden desk sits a stapler.
> GET THAT
[the stapler]
Taken.
It certainly works, but does it sound right? It doesn't sound quite right
to me. The demonstrative pronouns are usually used to indicate something
of the same type that was referred to, but a different instance of it:
"The apple you gave me tasted awful, but _that_ one is fine."
Still, in an interactive fiction context, where what the user types doesn't
always represent a real English phrase (like NORTH), for our purposes I'm
sure it would suit just fine.
Andrew Plotkin
Nulldogma (null...@aol.com) wrote:
> Andrew Plotkin wrote:
> > It *would* be every time, inevitably, in some reasonable game
> situations.
> > I could make up an example here to demonstrate, but I'll spare you.
> Right
> > now, there are no ambiguous cases (except in some very technical
> > situations, which haven't even come up yet, which are better regarded as
> > bugs than "it" behaviors.) If the semantics of "it" change, so that
> > suddenly there are ambiguous cases, do you see where this gets annoying?
> No.
> If you're going to mess around with "it" at all, I'd rather mess around
> with it to disambiguate, rather than to switch "it" entirely to a
> different object.
Er, I am arguing that we should not mess around with "it" at all. Sorry
about the unclarity.
> I know that you, as a programmer, don't want to mess with "it" ever.
I'm arguing this as a player, not as a programmer.
> > From elsewhere:
> >
> > > In conversation, if someone brings up a new concept or something, we
> say,
> > > for example, "What's that?" something else with "that," not "it." Do
> we
> > > need a new word here as well?
> >
> > However, that (no pun intended) is a very nice idea. "that" is the last
> > thing the game mentioned; "it" is the last thing you mentioned. It's
> > harder to get "that" right, but old-fashioned players (like me) have no
> > expectations for it, so it's an all-around win.
> Except that this bears no particular resemblance to standard English
> usage, and so nobody's going to know how to use it unless you tell them
> first.
None of text adventure English bears any particular resemblance to
standard English, remember? It all has to be explained. The current usage
of "it" has to be explained -- that's how this whole discussion got
started! This usage of "that" would have to be explained, but I'm willing
to make that sacrifice, as it were. It's a *simple* explanation, at least.
Just because we haven't changed the command syntax since the invention of
"oops", doesn't mean I'm completely stuck in the mud about it... I just
want my miracles to be backwards-compatibile.
I actually considered some sample exchanges, and I can think in the
"that" modality quite well.
Box Room
You see two boxes (one rosewood and one mahogany), a compass, a silver key,
and an iron key.
> take magnet
Taken.
> examine it
It's an old compass. The needle points to the iron key.
> take that
[The iron key] Taken.
> unlock rosewood box with it
Inside the rosewood box you see a plover's egg the size of an emerald, a
diamond-shaped pear, and an antique fruitcake.
> take that
Which do you mean, the plover's egg the size of an emerald, the
diamond-shaped pear, or the antique fruitcake?
> egg
Taken.
> eat it
Yum, raw egg.
> north
Round Room
You see a partridge and a pear tree here.
> smell that
Which do you mean, the partridge or the pear tree?
Of course, if "that" refers to a list of objects which must be
disambiguated, "those" should refer to the whole list (ie, "take those"
is like "take egg, pear, cake".) This is an easy extension once the
"that" stuff is coded, oy argh...
Note that, with this many different pronouns around, the very brief
library messages like "Taken." and "Done." are really *too* brief. They
should display the name of the object if "it" or "that" was used in the
command. (Unless the user was asked to disambiguate, in which case it's
redundant. Got all that?)
To create the "that" list, I would first add code to the DefArt() and
related functions -- that takes care of most of it -- and of course an
AddToDemonstrativeList() call which the game programmer could call at any
time to add an object.
There might have to be special case code for "look", since that spews out
so many objects. Maybe only include objects listed in the "plain" list,
after the room description itself and all describe properties are run...
well, it would take experimentation.
Also, never set "that" to refer to an object which is already "it". The
output of "examine compass" might call CDefArt(self), but we don't want
it to become "that", because it's only mentioned because of the player's
command.
Unlike "it", this proposal for "that" does require some attention from the
game programmer to get it right in any given game.
Oh, let me say that it goes without saying that "pronouns" should list
the "that" list as well as the standard pronouns.
Drone
Here's an example that will settle the question of disambiguation once
and for all:
You are lost in the substratum. There is a pile of its sitting beside a
pile of thats.
>X IT
Which it do you mean the it it or the that it?
>X IT IT
Which it it do you mean, the it it it or the that it it?
>THAT
That it it is sitting on top of the that it.
>X IT
Which it do you mean, the that it it, the that it, or the pile of its?
>QUIT!
This game is over, would you like to RESTART it, RESTORE it, or QUIT it.
>QUIT IT!
Which it do you mean, the RESTART it, the RESTORE it, or the QUIT it?
(Isn't scope wonderful?)
>QUIT IT!
I can't help it. I have a highly evolved disambiguation routine for your
convenience.
>FORGET IT.
You mean the help it?
>AAAAAAAAH!
It is over. Your score is that. It has been a production of Abbott &
Costello Pronoun Hell, Inc. To exit program, type it.
Drone.
--
"Esse Est Percipi."
foxg...@globalserve.net
Erik Max Francis
Nulldogma wrote:
> I
> was just wondering if it was *possible* to have it point to a list, not a
> single item, without hacking the current libraries to shreds.
>
> I'm still wondering.
But having _it_ refer to a list of items rather than a single one defeats
the whole purposes. The player is using _it_ as an unambiguous reference
to one object for easy typing. If _it_ ends up bringing a disambiguation
question ("What do you mean, the desk or the widget?") then it's completely
lost its entire purpose.
Erik Max Francis
John J Lee wrote:
> a) Stop executing the string of commands when something happens.
> b) Do this in particular circumstances when you think appropriate (this
> in general depends on the rest of the commands, though)
> c) 'precompile' a list of commands so you replace 'it' with the standard
> (whatever the player last mentioned), and only make these exceptions for
> single commands.
> d) Say 'player beware'
e. Not do the annoying, ambiguous, unreliable _it_ substitution in the
first place.
Andrew Plotkin
> > How about this idea, just out of the blue:
> >
> > In conversation, if someone brings up a new concept or something, we
> > say, for example, "What's that?" something else with "that," not
> > "it." Do we need a new word here as well?
> It's a good idea (making up a new word, that is), but does this sample
> script make sense?
> > EXAMINE DESK
> On top of the wooden desk sits a stapler.
> > GET THAT
> [the stapler]
> Taken.
> It certainly works, but does it sound right? It doesn't sound quite right
> to me.
It took my the duration of typing in my previous "that" post to get used
to it. :) I'm happy with it.
> The demonstrative pronouns are usually used to indicate something
> of the same type that was referred to, but a different instance of it:
> "The apple you gave me tasted awful, but _that_ one is fine."
I think there is an equally common English usage, which notionally
involves pointing, which is the usage I want to buy into. "Give me
*that*. <pointing at screwdriver>"
One thing I should explain is that I just finished re-reading a wacky
little math/logic book called _The Liar_, which is about the liar's
paradox ("This sentence is false.") And the authors analyze it by using a
very restricted English syntax, just to make life easier. The words are
"Max", "Claire", "has", "doesn't have", "the three of clubs" (and the
other 51 card names), "is", "isn't", "true", "this sentence", and "that
sentence <point at another sentence>".
So I've gone through about a week of reading "This sentence is false."
"That sentence <the previous one> is true." "This sentence is false and
that sentence <the previous one> is true." I'm heavily set in the idea of
"that" as a formal parameter which is set by demonstrative conventions,
namely, pointing -- or taking the last object mentioned by the computer.
> Still, in an interactive fiction context, where what the user types doesn't
> always represent a real English phrase (like NORTH), for our purposes I'm
> sure it would suit just fine.
Yep.
aul...@koala.scott.net
Andrew Plotkin <erky...@netcom.com> wrote:
>You know, all I ever wanted was to be able to type "it" instead of "large
>purple snorkelwhacker" five times in a row...
And I would look at you funny if you ever typed all that even once. =)
(say, that noun sounds familiar...)
>I'm kind of dumbfounded by the claim that adding "it" to the environment
>was a mistake...
Well, you're right. It was kind of dumb of me to say that. Let me change
it a little to say that I think it was a mistake to ever allow the meaning
of "it" to be anything besides the last thing *I* referred to. That DOES
create more problems than it solves.
>And the current solution is very easy to get used to,
>*because* it's so simple-minded and consistent.
What is it that you are saying is the current solution? I haven't
noticed anything consistent, but that may just be me. If it were
established that the game should never change the meaning behind
the scenes, then that would be simple-minded and consistent, as you
say, and I would endorse it fully. Forgive me if I missed somewhere
that this is the standard practice now.
On the subject of endorsements, I really like the suggestion of using
"that" as opposed to "it" for objects that the game mentions. If no one
has implemented this in umpteen months months when my project gets off
the ground, I'll give it a go. Congratulations to the one who suggested
it for thinking of solutions rather than problems.
That is all,
Joe
aul...@koala.scott.net
Dave Gatewood <gate...@mail.athensnet.com> wrote:
>I've noticed that (I believe for the first time) the latest Inform
>library resets the it object when the player enters a room
I'm going to have to go out on a limb and say I don't like that idea.
I doubt that will surprise anyone who has been reading this thread,
but I thought I'd make it official.
I'd be interested to hear from anyone who likes this feature.
Now, let's see... how would I feel if it reset the "that" object?
Hmmm.....
That is all,
Joe
Kenneth Albanowski
In article <32E021D4...@alcyone.com>,
>command. If you're going to have the pronoun modification, then you're
>going to have to disable it during chained commands. Which makes yet
>another complication to the idea.
>The easier solution is to not use pronoun context changing at all.
Here's a dumb idea, then: clear the pronoun context whenever something
happens to make the pronoun in question ambiguous. (Note handwaving in the
vicinity of "something"). The net result would be:
> SEARCH DESK
You search the desk and find, oddly enough, a drawer.
> SIT ON IT
I'm sorry, but I don't know what you are referring to. Please clarify.
> SIT ON THE DESK
It's cold.
Exactly how the programmer should know when to reset itobj, as opposed to
setting it to something different, I'm really not sure. It seems that nearly
every command that produces an object (via some mechanism) should make the
itobj ambiguous, and only commands that refer to an already exstant object
(get, put, examine, etc.) without producing or revealing a new object should
let itobj (or whatever the local equivalent is) be set.
--
Kenneth Albanowski (kja...@kjahds.com)
Jason Melancon
> > Jason Melancon wrote:
>
> > > How about this idea, just out of the blue:
> > >
> > > In conversation, if someone brings up a new concept or something, we
> > > say, for example, "What's that?" something else with "that," not
> > > "it." Do we need a new word here as well?
I think you all are right that it doesn't quite sound exactly right at
first. Let me put the idea in its original context, which I should
have done to begin with in my somewhat inarticulate post above.
The idea came thinking about the _Airplane_ joke that Nulldogma
recited. The joke doesn't quite hit home for me, because it seems a
little forced; usually I'd say, "What's that?" rather than, "What is
it?" if I wanted to trigger "It's a building whatever whatever, but
that's not important right now."
I think you'll hear the sense in the idea if you imagine the game as a
session of D&D, and you're discussing the next move with another
player. Consider this stereotypical moment.
Players: We'll push the button on the wall.
DM: A trapdoor opens below you, and you fall ten feet to a steeply
sloped stone floor, rolling you violently north. You continue north
through the dusty brick hallway, and come to a room filled with
cupboards and spiderwebs, and there's a small table that's about to
split down the middle from rot, with a flask of frothing black
liquid.
Players: Well, what should we do? Do we fool with that? [unsaid: or
continue on our way to the treasure room?]
In other words, about the same sense Andrew took it in. "That" is as
opposed to the "this" of continuing on your way or doing something
else.
If you think this makes any sense, fine. If not, fine. I'm not
really saying it's a good idea, I just thought you might find it
resolves your problem neatly, real English aside.
Erik Max Francis
Kenneth Albanowski wrote:
> Here's a dumb idea, then: clear the pronoun context whenever something
> happens to make the pronoun in question ambiguous. (Note handwaving in the
> vicinity of "something").
Two problems. First, chained commands no longer work. Using SEARCH DESK.
SIT ON IT won't work, and that is, in my opinion, unacceptable.
Second, you get to a stage where if you do this you're forgetting what the
_it_ pronoun was introduced for. It's supposed to save typing. If it
doesn't work half the time because of a possible ambiguity and the computer
doesn't want to take the chance of guessing (because likely it'll get it
wrong), then the use of _it_ has become useless.
> Exactly how the programmer should know when to reset itobj, as opposed to
> setting it to something different, I'm really not sure. It seems that
> nearly
> every command that produces an object (via some mechanism) should make the
> itobj ambiguous, and only commands that refer to an already exstant object
> (get, put, examine, etc.) without producing or revealing a new object
> should
> let itobj (or whatever the local equivalent is) be set.
Better yet: Leave it the way it is. Don't change _it_. _It_ refers to the
last object you mentioned. Even dimwit players can figure this out, I would
wager.
Den of Iniquity
On Fri, 17 Jan 1997, Andrew Plotkin wrote:
>> In conversation, if someone brings up a new concept or something, we say,
>> for example, "What's that?" something else with "that," not "it." Do we
>> need a new word here as well?
>
>However, that (no pun intended) is a very nice idea. "that" is the last
>thing the game mentioned; "it" is the last thing you mentioned. It's
>harder to get "that" right, but old-fashioned players (like me) have no
>expectations for it, so it's an all-around win.
While we're at it, why not 'former' and 'latter':
- There is a table, here, supporting a large purple snorkelwhacker
-
-> NAME THE LATTER IT
-
- OK, the large purple snorkelwhacker is now called 'it'.
Or, for more disambiguation fun than you thought possible:
- You can see a latter and a former here.
--
Den
drone
Jason Melancon wrote:
>
> The idea came thinking about the _Airplane_ joke that Nulldogma
> recited. The joke doesn't quite hit home for me, because it seems a
> little forced; usually I'd say, "What's that?" rather than, "What is
> it?" if I wanted to trigger "It's a building whatever whatever, but
> that's not important right now."
>
Aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaah!
<runs screaming, parody-defeated, from the pronoun pickers' thread>
Drone.
--
"esse est percipi"
foxg...@globalserve.net
Mary K. Kuhner
In article <5c3c15$l...@prometheus.acsu.buffalo.edu> go...@cs.buffalo.edu (Phil Goetz) writes:
>But, that's not what was said. What was said was:
>A: Examine desk.
>B: The desk supports a widget.
>A: Take it.
>IMHO, "it" clearly and unambiguously refers to the widget.
But the changes needed to make this ambiguous are *very* subtle.
A: Examine purse.
B: The purse contains $25.
A: Take it.
Already, because purses are more normally taken than desks, I think
this is fairly murky.
A: Examine bucket.
B: The bucket contains water.
A: Take it.
I'm pretty sure "it" is the bucket here, because if I take the water
without its container I'll get soggy. Care to program the difference
between desk, purse and bucket in this context?
Add me to the faction that says the current system, which is
predictable, is better than a more complex one.
Mary Kuhner mkku...@genetics.washington.edu
Phil Goetz
In article <32D74F9E...@alcyone.com>,>Brendan Lane wrote:
>
>> Hmmmm...It appears to me that there are two different interpretations
>> of the IF here. John seems to view the IF session as a conversation
>> between player and computer, whereas Erik seems to be seeing it as a
>> series of commands carried out by the computer.
>
>No, I'm not seeing it that way; that's what "Take it" means in plain
>English. Even in this context there's no way that a _human_ could be sure
>what the command referred to. After all, "Examine the desk. Take it" is
>the same as "Examine the desk, and then take it." This means, in plain
>English, tell me something about the desk, and then pick the desk up.
But, that's not what was said. What was said was:
A: Examine desk.
B: The desk supports a widget.
A: Take it.
IMHO, "it" clearly and unambiguously refers to the widget.
I think you are suffering from parser-lock, a familiar syndrome among
linguists and AI researchers, in which you begin to parse sentences
the way your grammar or parser does instead of like a normal human. :)
And, yes, you are seeing it as a series of commands; you're not
considering the computer's response as part of the conversation.
The rest of the examples Erik gave are more difficult.
But I'm not convinced we should give up on treating pronouns like
we do in conversation.
Phil
Michael Graham
In article <erkyrathE...@netcom.com>, Andrew Plotkin
<erky...@netcom.com> writes
[Good suggestions on implementation of "that" snipped]
>Unlike "it", this proposal for "that" does require some attention from the
>game programmer to get it right in any given game.
There should also be a mechanism (say via an attribute or a fake action)
that gives the programmer the ability to prevent certain objects from
being added to the "that" list (say for strange objects (read:
"kludges") that aren't meant to be manipulated by the player but may
appear in room descriptions or lists). Or at least a function to remove
certain objects from the current "that" list.
--
Michael Graham mailto:mgr...@cega.demon.co.uk
Cega Ltd. Web Design Consultants http://www.cega.co.uk
London (Stratford), UK
Tel/Fax: +44-(0)181-221-2417
cody sandifer
hey all. Once again, I need to ask a simple novice-type question.
Here's the situation.
The player kills a monkey in his cage. (Yay! The puzzle is solved!)
I program this as:
monkey:fixeditem
.
.
.
verDoKill(actor) ={}
doKill(actor) =
{
"You deprive the monkey of its basic right to life.";
monkey.moveInto(nil);
monkey_body.moveInto(cage);
}
.
.
;
The old monkey is out. The new (and improved?) dead monkey is in.
The problem:
The initial "kill monkey" works, of course.
However, now the player types "search it" and gets no response. Why?
Because the initial object doesn't exist anymore. There must be an easy
way to fix this. Can I just add a simple line like itobj = monkey_body in
the doKill(actor) action? Any suggestions? Sorry if this has been
answered already -- I haven't been paying attention.
cody
Nulldogma
> Can I just add a simple line like itobj = monkey_body in
> the doKill(actor) action?
Actually, it's setit(monkey_body), but you've got the right idea.
Mark J Musante
cody sandifer (sand...@crmse.sdsu.edu) wrote:
> The initial "kill monkey" works, of course.
>
> However, now the player types "search it" and gets no response. Why?
-=-
> monkey:fixeditem
> .
> .
> .
> verDoKill(actor) ={}
> doKill(actor) =
> {
> "You deprive the monkey of its basic right to life.";
> monkey.moveInto(nil);
> monkey_body.moveInto(cage);
Insert here: setit( monkey_body );
> }
> .
> .
> ;
- Mark
John Wood
2...@news.gte.net> <32E13B9F...@alcyone.com> <erkyrathE...@netcom.com> <32e2d254...@news.gte.net>
Message-ID: <182246...@elvw.demon.co.uk>
Date: Thursday, Jan 23, 1997 08.29.18
Organization: None
Reply-To: jo...@elvw.demon.co.uk
X-Newsreader: Newswin Alpha 0.7
Lines: 21
hra...@gte.net (Jason Melancon) writes:
>
> Players: Well, what should we do? Do we fool with that? [unsaid: or
> continue on our way to the treasure room?]
>
> In other words, about the same sense Andrew took it in. "That" is as
> opposed to the "this" of continuing on your way or doing something
> else.
Reminds me of an impromptu on-stage conversation while performing
with a college band:
"Why don't you do this, while I do that?"
"I've got a better idea. Why don't *you* do this, while Martin
does that?"
It all disambiguated perfectly at the time... ;-)
John
Trevor Barrie
Erik Max Francis <m...@alcyone.com> wrote:
>In plain English, the pronoun _it_ means "the last thing I referred to
>directly."
That's simply and clearly not true...
>If you say, in English, "The desk contained a widget, but it wasn't made
>of wood," do I mean the desk was red or the widget? I mean the desk,
>obviously.
...although, based on this, it occurs to me you know this and intended this
paragraph as a joke.:) Anyway, consider the following examples:
"The drawer, contained a pencil but it was otherwise empty."
"Look in the knapsack, will you?"
"There's a sandwich in there."
"Is it peanut butter?"
In both of these cases, I think it's clear what "it" means; in neither case
is it "the last thing to which I referred directly". At best, it means "The
last thing mentioned in this conversation which make sense in this context",
and there's no reason why it can't mean the same in IF. TADS already has
means for determining whether a given object makes sense with a certain verb
which it uses in disambiguation (and I assume other languages do something
similar). What would be so terrible about keeping a list of things recently
mentioned (most recent first) and matching "it" to the first list member
which fits the context? This would mean that after...
>open fridge
You see a mango.
..."eat it" would translate to "eat mango", while "close it" would translate
to "close mango". Just what I, as a player, would expect.
Nulldogma
Trevor Barrie wrote:
> >open fridge
>
> You see a mango.
>
> ..."eat it" would translate to "eat mango", while "close it" would
translate
> to "close mango". Just what I, as a player, would expect.
I really really *really* hope that you meant "close fridge." Or else I'm
starting to worry about you...
John J Lee
The storm in the widget continues...
Episode 10, in which I get annoyed
On 21 Jan 1997, Mary K. Kuhner wrote:
> In article <5c3c15$l...@prometheus.acsu.buffalo.edu> go...@cs.buffalo.edu (Phil Goetz) writes:
>
> >But, that's not what was said. What was said was:
>
> >A: Examine desk.
> >B: The desk supports a widget.
> >A: Take it.
>
> >IMHO, "it" clearly and unambiguously refers to the widget.
At last, someone who agrees with me...
[...]
> But the changes needed to make this ambiguous are *very* subtle.
>
> A: Examine purse.
> B: The purse contains $25.
> A: Take it.
>
> Already, because purses are more normally taken than desks, I think
> this is fairly murky.
Eek. OK, I'll say it again. The ***ONLY*** circumstance I was talking
about was the ***ONLY*** circumstance in which the use of 'it' has ever
annoyed me in the slightest. All the other circumstances which people
have carefully and subtly thought up are all crafty and fascinating, but
personally I (and no-one else on this group I have noticed) would not
want to change the object to which 'it' refers in any of these
circumstances.
The one and ***ONLY*** circumstance in question is:
> Take the sparkly, newly revealed, easily pocketable, highly useful
widget from the dull brown, old, huge and immovable, useless piece of
scenery referred to as the desk.
But that's fixed in place!
[...]
> A: Examine bucket.
> B: The bucket contains water.
> A: Take it.
>
> I'm pretty sure "it" is the bucket here, because if I take the water
> without its container I'll get soggy. Care to program the difference
> between desk, purse and bucket in this context?
Err... yes -just leave 'it' pointing to what it usually does in the case
of the bucket, and ***ONLY*** change it for the desk/widget. Bingo.
[...]
> Add me to the faction that says the current system, which is
> predictable, is better than a more complex one.
Not exactly a hugely complex system, though, *really*.
Do you all *really* find it so complicated to keep track of, a change like
this in one circumstance?
Several good points have been made, though - the use of lists of commands,
and the 'that' idea.
Personally, I would say that if you give a list of commands, you are
saying 'OK, I know what I'm doing, I've done this a hundred times before
and I know what this does. I don't have to think about what I'm doing so
I can apply all my mental powers to realising that a *widget* appears at
this point, so I obviously can't use 'it' here to refer to the desk. That
would be silly of me!' Even if it does give a different response than for
the same list separated by returns. You can always undo, for heavens
sake. If you *do* use lists of commands without knowing what you're
doing, you are risking the fact that it's easy to mess something up like
this. This happens very often with these lists in other circumstances not
involving 'it', anyway.
The 'that' idea is a good one, though perhaps not all that useful
because of all the disambiguation that would be involved most of the
time (I would have thought), unless you decided to leave out the exception
for 'it' I suggested.
I can understand why people would prefer to leave things as they are,
though. It is consistent, but also bloody annoying. This is not a
programming language, it's a game.
Mary K. Kuhner
John J Lee <jjl...@york.ac.uk> writes:
>The storm in the widget continues...
>Episode 10, in which I get annoyed
>The one and ***ONLY*** circumstance in question is:
>> Take the sparkly, newly revealed, easily pocketable, highly useful
>widget from the dull brown, old, huge and immovable, useless piece of
>scenery referred to as the desk.
>But that's fixed in place!
I'm willing to allow this as a form of disambiguation *if* the
container is not movable, and can be easily guessed to be not
movable. But it's still going to take some doublethink on my
part as a player, because I'll have to remember that if the widget is in
a movable, boring object (say, the strongbox) the same syntax will
get a different result. I screw up with the current convention
too, but I think I'll get used to that. I'm not sure I'd ever
get used to having two rules, one for movable and the other for
immovable containers--I might just stop using "it" in such contexts.
Mary Kuhner mkku...@genetics.washington.edu
Nulldogma
> >The one and ***ONLY*** circumstance in question is:
>
> >> Take the sparkly, newly revealed, easily pocketable, highly useful
> >widget from the dull brown, old, huge and immovable, useless piece of
> >scenery referred to as the desk.
>
> >But that's fixed in place!
>
> I'm willing to allow this as a form of disambiguation *if* the
> container is not movable, and can be easily guessed to be not
> movable. But it's still going to take some doublethink on my
> part as a player, because I'll have to remember that if the widget is in
> a movable, boring object (say, the strongbox) the same syntax will
> get a different result.
Also, this only works for "take."
> EXAMINE DESK
On the desk you see a widget.
> TAKE IT
(the widget)
Taken.
(but...)
> EXAMINE DESK
On the desk you see a widget.
> WRITE NAME ON IT
You write your name on the desk.
...So you'd need to have two different "it" objects for different verbs.
Messy, and confusing.
Cable Hicks
In article <19970124223...@ladder01.news.aol.com>, null...@aol.com (Nulldogma) wrote:
>Trevor Barrie wrote:
>> >open fridge
>>
>> You see a mango.
>>
>> ..."eat it" would translate to "eat mango", while "close it" would
>translate
>> to "close mango". Just what I, as a player, would expect.
>
>I really really *really* hope that you meant "close fridge." Or else I'm
>starting to worry about you...
>
>Neil
Actually, I think Stationfall would translate that
as eat mango, although most games I've played
would see 'it' as a fridge. So, I wouldn't worry
too much.
Kenneth Albanowski
In article <32E39EBD...@alcyone.com>,
>
>> Here's a dumb idea, then: clear the pronoun context whenever something
>> happens to make the pronoun in question ambiguous. (Note handwaving in the
>> vicinity of "something").
>
>Two problems. First, chained commands no longer work. Using SEARCH DESK.
>SIT ON IT won't work, and that is, in my opinion, unacceptable.
Hmm. We've really got two different "it"s here, my it and your (or rather
the game's) it. Hence:
>SEARCH DESK
You find a cheerfull drawing of a iguana tucked in a side panel.
>SIT ON IT
[Assuming you mean the desk, the last thing you referred to]
Cold.
>FOLD THAT
[Assuming you mean the drawing, the last thing I referred to]
You crease the paper, giving the iguana a squint.
"That" (as suggested by other folk) is the closest word I can think of, but
it doesn't quite ring right. It seems better then nothing, though. Assigning
thatobj to the last thing referred to by the game, and perhaps leaving
themobj for another day seems to have promise. When thatobj should be set to
itobj is other interesting question.
Of course, we could always just take the easy way out and invent a new set
of pronouns to disambiguate the situation. Perhaps. Or we could just ignore
the whole mess and leave it in its current, cheerfully and ambiguously
non-conversational state. Yes, I think I like the sound of that. Er, it.
Them. Whatever.
Hmm... "SIT ON WHATEVER"... Nah.
--
Kenneth Albanowski (kja...@kjahds.com)
Trevor Barrie
null...@aol.com (Nulldogma) wrote:
>Trevor Barrie wrote:
>> >open fridge
>>
>> You see a mango.
>>
>> ..."eat it" would translate to "eat mango", while "close it" would
>> translate to "close mango". Just what I, as a player, would expect.
>
>I really really *really* hope that you meant "close fridge."
Yeah, me too. I'm pretty sure that is what I meant, in fact.
>Or else I'm starting to worry about you...
Obviously, learning LISP must have driven me mad.
Kenneth Fair
>Erik Max Francis <m...@alcyone.com> wrote:
>
>>In plain English, the pronoun _it_ means "the last thing I referred to
>>directly."
>>If you say, in English, "The desk contained a widget, but it wasn't made
>>of wood," do I mean the desk was red or the widget? I mean the desk,
>>obviously.
What if you say, "The desk contains a pencil. It is made of wood."
Are you talking about the desk, or the pencil? That would depend on
the context and inflection of the sentence, wouldn't it?
--
KEN FAIR - U. Chicago Law | <http://student-www.uchicago.edu/users/kjfair>
Of Counsel, U. of Ediacara | Power Mac! | CABAL(tm) | I'm w/in McQ - R U?
When you go for a job interview, I think a good thing to ask is if
they ever press charges.
Phil Goetz
In article <32E39EBD...@alcyone.com>,
>SIT ON IT won't work, and that is, in my opinion, unacceptable.
IMHO:
When a player uses the syntax SEARCH DESK. SIT ON IT.
where a player enters two commands on one line,
he is breaking mimesis himself. He's saying, mentally,
"I am not doing things in another world, I am creating a batch file."
It's opposed to the illusion of interaction and dialogue I'm trying
to create, and I see no reason to worry about accomodating that.
(`That' being, uh, never mind.)
Phil Go...@cs.buffalo.edu
Phil Goetz
In article <sandifer-210...@sci-dial-2-mac1.sdsu.edu>,
cody sandifer <sand...@crmse.sdsu.edu> wrote:
>The problem:
>
>The initial "kill monkey" works, of course.
>
>However, now the player types "search it" and gets no response. Why?
>the doKill(actor) action? Any suggestions?
The "right" solution would be to use one monkey object, and give it
the property DEAD, and have the game then treat it differently.
Can TADS do this?
In an earlier game of mine, I made "dead" a synonym for "broken"
that applied to animate objects. Any dead (broken) actor could not
execute its actions, which included speaking or responding to conversation.
If someone typed "kill monkey with crowbar", it was handled with exactly
the same code as "smash vase with crowbar", and automatically added
the adjective "dead" to "monkey" (or "broken" to "vase").
If the player was dead, the game ended. That worked OK.
It bugs me that TADS and Inform don't seem to respect objects.
Like, in Inform, having a separate location called "the_dark" instead of
being able to say that the current location is dark.
Like the hassle in Inform of moving the player to a different location,
so that you have to use a separate function to do it.
Programmers should not have to think about this stuff. There should be
exactly one 'move object' command that you use in all circumstances.
I've seen a bug on this newsgroup resulting from people using "move player"
instead of the official MovePlayerTo or whatever.
Programming would be much easier if the compiler's ontology mapped directly
onto the story's ontology.
Phil Go...@cs.buffalo.edu
Phil Goetz
In article <Pine.SGI.3.95L.97012...@tower.york.ac.uk>,
John J Lee <jjl...@york.ac.uk> wrote:
>> But the changes needed to make this ambiguous are *very* subtle.
>>
>> A: Examine purse.
>> B: The purse contains $25.
>> A: Take it.
>>
>> Already, because purses are more normally taken than desks, I think
>> this is fairly murky.
>
>Eek. OK, I'll say it again. The ***ONLY*** circumstance I was talking
>about was the ***ONLY*** circumstance in which the use of 'it' has ever
>annoyed me in the slightest. All the other circumstances which people
>have carefully and subtly thought up are all crafty and fascinating, but
>personally I (and no-one else on this group I have noticed) would not
>want to change the object to which 'it' refers in any of these
>circumstances.
>
>The one and ***ONLY*** circumstance in question is:
>
>> Take the sparkly, newly revealed, easily pocketable, highly useful
>widget from the dull brown, old, huge and immovable, useless piece of
>scenery referred to as the desk.
Is there a way to distinguish these different circumstances?
Phil
Dan Shiovitz
In article <5d07dv$q...@prometheus.acsu.buffalo.edu>,
Phil Goetz <go...@cs.buffalo.edu> wrote:
>In article <sandifer-210...@sci-dial-2-mac1.sdsu.edu>,
>cody sandifer <sand...@crmse.sdsu.edu> wrote:
>>The problem:
>>
>>The initial "kill monkey" works, of course.
>>
>>However, now the player types "search it" and gets no response. Why?
>>Because the initial object doesn't exist anymore. There must be an easy
>>way to fix this. Can I just add a simple line like itobj = monkey_body in
>>the doKill(actor) action? Any suggestions?
>
>
>The "right" solution would be to use one monkey object, and give it
>the property DEAD, and have the game then treat it differently.
>Can TADS do this?
Not precisely. It's possible to write a class that inherits from
"actor" (and indirectly from "thing") where you could just say
monkey.isdead := true and it would always behave correctly to being
asked questions or picked up or whatever, depending on its state.
However, there's currently no class that exists to do that. One way
to compensate would be if TADS allowed dynamic class additional and
removal, but it doesn't. So the easiest thing to do in the current
setting is to make a liveMonkey actor object, and a deadMonkey thing
object.
[..]
>Phil Go...@cs.buffalo.edu
--
dan shiovitz scy...@u.washington.edu sh...@cs.washington.edu
slightly lost author/programmer in a world of more creative or more
sensible people ... remember to speak up for freedom because no one else
will do it for you: use it or lose it ... carpe diem -- be proactive.
my web site: http://weber.u.washington.edu/~scythe/home.html some ok stuff.
Magnus Olsson
In article <5d07dv$q...@prometheus.acsu.buffalo.edu>,
Phil Goetz <go...@cs.buffalo.edu> wrote:
>In article <sandifer-210...@sci-dial-2-mac1.sdsu.edu>,
>cody sandifer <sand...@crmse.sdsu.edu> wrote:
>>The problem:
>>
>>The initial "kill monkey" works, of course.
>>
>>However, now the player types "search it" and gets no response. Why?
>>Because the initial object doesn't exist anymore. There must be an easy
>>way to fix this. Can I just add a simple line like itobj = monkey_body in
>>the doKill(actor) action? Any suggestions?
>
>
>The "right" solution would be to use one monkey object, and give it
>the property DEAD, and have the game then treat it differently.
>Can TADS do this?
Of course. But you sound rather dogmatic when talking about the
"right" solution - let's be pragmatic instead! My own experience is
that what is right - changing the behaviour of an object or replacing
it with another object - is that it varies with the situation. In the
case of an object's behaviour changing radically - such as an animate
object suddenly becoming inanimate - it is often much simpler to
replace it with another object. And to answer the original question,
TADS has a "setit" function to make "it" refer to the new object.
>It bugs me that TADS and Inform don't seem to respect objects.
The Inform library simply isn't object oriented to a very high degree
(see my earlier posts about "Inform Library Criticism"), and the
standard TADS library suffers from similar problems but to a smaller
extent.
>Like, in Inform, having a separate location called "the_dark" instead of
>being able to say that the current location is dark.
This is actually a major inconvenience in that it leads to a lot of extra
testing. I find that my code is full of things like
if (location == thedark)
move foo to real_location;
else
move foo to location;
Perhaps Graham would like to comment on the historical reasons for
this? I suspect that it has something to do with Infocom's doing it
this way...
>Like the hassle in Inform of moving the player to a different location,
>so that you have to use a separate function to do it.
It's rather hard to see how you could avoid the "hassle" - there's
simply a lot more to do when moving hte player than when moving an
object (since scope and point-of-view change). But the interface is
non-orthogonal for no good reason; it would be easy to encapsulate it
and use the same interface for both cases, like TADS does:
foo.moveTo(location) (or whatever, don't have the docs handy) does
different things depending on whether foo is the player or something
else. Or, to follow the non-OO tradition of the Inform library,
moveTo(foo, location).
>I've seen a bug on this newsgroup resulting from people using "move player"
>instead of the official MovePlayerTo or whatever.
This seems to be a very common problem, yes.
>Programming would be much easier if the compiler's ontology mapped directly
>onto the story's ontology.
Surely you mean the _library's_ ontology, not the compiler's? And is
"ontology" really the right word to use here?
--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
Graham Nelson
In article <5d47sc$h...@bartlet.df.lth.se>, Magnus Olsson
<URL:mailto:m...@bartlet.df.lth.se> wrote:
> >Like, in Inform, having a separate location called "the_dark" instead of
> >being able to say that the current location is dark.
>
> This is actually a major inconvenience in that it leads to a lot of extra
> testing. I find that my code is full of things like
>
> if (location == thedark)
> move foo to real_location;
> else
> move foo to location;
>
> Perhaps Graham would like to comment on the historical reasons for
> this? I suspect that it has something to do with Infocom's doing it
> this way...
I wouldn't do it this way again, no. It arises from a Z-machine
issue: in V3 the location name on the status bar is always drawn
from the variable Infocom used as "location". Stupidly, I did too,
rather than making it merely copy either the location or darkness.
And then again... there is an argument for "darkness" as a location
in its own right. In many games, darkness behaves conceptually
much more like an area with its own characteristics than like
a slight modification to real, physical areas. Most events in
adventure games are perceived by means of sight, so that being
in darkness cuts the player off from almost every aspect of the
physical place. Similarly, all dark places tend to behave alike:
monsters lurk and so on.
What really _is_ pointless is the failure of "real_location" to
simply always hold the physical location! (At present it tends
only to be meaningful when the player is in darkness.) I will
attend to this in some future library release.
--
Graham Nelson | gra...@gnelson.demon.co.uk | Oxford, United Kingdom
Magnus Olsson
Topic drift is an amazing thing, isn't it: a sub-thread in the
discussion about the semantics of pronouns led to a "simple question
on pronouns in TADS" which mutated into a discussion of the OO-ness of
the Inform library which in turn led to the current question. Usenet
is fantastic...
Anyway:
In article <ant0320381cbM+4%@gnelson.demon.co.uk>,
Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
>And then again... there is an argument for "darkness" as a location
>in its own right. In many games, darkness behaves conceptually
>much more like an area with its own characteristics than like
>a slight modification to real, physical areas. Most events in
>adventure games are perceived by means of sight, so that being
>in darkness cuts the player off from almost every aspect of the
>physical place. Similarly, all dark places tend to behave alike:
>monsters lurk and so on.
I must respectfully disagree. In the real world, darkness affects
our perception (and a few properties of material objects), but it
does not move us to a parallel universe.
IMHO, Inform's treatment of darkness looks like a hack that is
convenient as long as you don't want to modify the behaviour of
darkness (such as making everything but sight-related activites work
as usual), in which case it seems more like a liability than an asset.
>What really _is_ pointless is the failure of "real_location" to
>simply always hold the physical location! (At present it tends
>only to be meaningful when the player is in darkness.) I will
>attend to this in some future library release.
That would save programmers quite a lot of trouble, I think.
Andrew Plotkin
Magnus Olsson (m...@bartlet.df.lth.se) wrote:
> In article <ant0320381cbM+4%@gnelson.demon.co.uk>,
> Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
> >And then again... there is an argument for "darkness" as a location
> >in its own right. In many games, darkness behaves conceptually
> >much more like an area with its own characteristics than like
> >a slight modification to real, physical areas. Most events in
> >adventure games are perceived by means of sight, so that being
> >in darkness cuts the player off from almost every aspect of the
> >physical place. Similarly, all dark places tend to behave alike:
> >monsters lurk and so on.
> I must respectfully disagree. In the real world, darkness affects
> our perception (and a few properties of material objects), but it
> does not move us to a parallel universe.
> IMHO, Inform's treatment of darkness looks like a hack that is
> convenient as long as you don't want to modify the behaviour of
> darkness (such as making everything but sight-related activites work
> as usual), in which case it seems more like a liability than an asset.
It does get one thing right, however: all darkness looks the same to the
player, even to the point of only printing the "room description" the
first time you enter *any* dark room. And things like the "places"
command don't list places that you've been with no light.
Of course, I'd rather those things were hacked in and everything *else*
were handled more simply.
One thing which is very hard under the current system is to make
different dark areas distinct -- I obviously did a lot of this _So Far_,
and I really don't want to think about the code I wrote. Not just for the
sounds, but to get realistic commands like "feel floor" to behave
differently depending on the area.
> >What really _is_ pointless is the failure of "real_location" to
> >simply always hold the physical location! (At present it tends
> >only to be meaningful when the player is in darkness.) I will
> >attend to this in some future library release.
> That would save programmers quite a lot of trouble, I think.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Kathleen Fischer
Graham Nelson wrote:
> Most events in
> adventure games are perceived by means of sight, so that being
> in darkness cuts the player off from almost every aspect of the
> physical place.
What an interesting thought... write a game from the point of view of
somebody who is visually impaired. Everything would be done by touch,
taste, sound and smell. Sounds like a nice competition game (not that I
have time!)
Of course, given the way Inform handles Darkness, I guess that really
wouldn't be possible, would it (she says from the point of view of
complete ignorance)?
Kathleen
--
*******************************************************************
* Kathleen M. Fischer
* kfis...@greenhouse.llnl.gov
** "Don't stop to stomp ants while the elephants are stampeding" **
Stephen Granade
On Tue, 4 Feb 1997, Kathleen Fischer wrote:
> Graham Nelson wrote:
> > Most events in
> > adventure games are perceived by means of sight, so that being
> > in darkness cuts the player off from almost every aspect of the
> > physical place.
>
> What an interesting thought... write a game from the point of view of
> somebody who is visually impaired. Everything would be done by touch,
> taste, sound and smell. Sounds like a nice competition game (not that I
> have time!)
I believe at one point Mr Wilson was planning such a game, though I
haven't heard him speak of any game other than Avalon for quite a while.
Is this true, GKW, or is my memory faulty?
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 Plotkin
Kathleen Fischer (kfis...@greenhouse.llnl.gov) wrote:
> Graham Nelson wrote:
> > Most events in
> > adventure games are perceived by means of sight, so that being
> > in darkness cuts the player off from almost every aspect of the
> > physical place.
> What an interesting thought... write a game from the point of view of
> somebody who is visually impaired. Everything would be done by touch,
> taste, sound and smell. Sounds like a nice competition game (not that I
> have time!)
"Aayela" was one angle on this, of course. Although the last time this
topic came up, I noted that we've had games where you're *temporarily*
blind or endarkened, but never a game where you've been blind since birth.
There'd be a difference, I think.
> Of course, given the way Inform handles Darkness, I guess that really
> wouldn't be possible, would it (she says from the point of view of
> complete ignorance)?
Anything's *possible*.
Matthew Amster-Burton
Stephen Granade <sgra...@phy.duke.edu> wrote:
>I believe at one point Mr Wilson was planning such a game, though I
>haven't heard him speak of any game other than Avalon for quite a while.
>Is this true, GKW, or is my memory faulty?
I remember--it was going to be called Sight Unseen and the idea
sounded really good. I think I remember him saying that he's dropped
the idea of doing any further games, though. Uh, now I'll let him
speak for himself.
Matthew
Adam J. Thornton
In article <32F76F...@greenhouse.llnl.gov>,
Kathleen Fischer <kfis...@greenhouse.llnl.gov> wrote:
>What an interesting thought... write a game from the point of view of
>somebody who is visually impaired. Everything would be done by touch,
>taste, sound and smell. Sounds like a nice competition game (not that I
>have time!)
GKW was, once upon a time, talking about doing exactly this in a future
game, to be worked on after Avalon's release.
Adam
--
"I'd buy me a used car lot, and | ad...@princeton.edu | As B/4 | Save the choad!
I'd never sell any of 'em, just | "Skippy, you little fool, you are off on an-
drive me a different car every day | other of your senseless and retrograde
depending on how I feel.":Tom Waits| little journeys.": Thomas Pynchon | 64,928
Dan Shiovitz
In article <erkyrathE...@netcom.com>,
Andrew Plotkin <erky...@netcom.com> wrote:
[..]
>"Aayela" was one angle on this, of course. Although the last time this
>topic came up, I noted that we've had games where you're *temporarily*
>blind or endarkened, but never a game where you've been blind since birth.
>There'd be a difference, I think.
Living Room
You are in the living room. The radio is on. You can smell
something from the south; Fred must be making breakfast.
> WAVE CANE
You can feel a chair or a table to your left, and a doorway to the
south.
> FEEL TABLE
There seems to be a television set on the table. You can feel a cable
box on top of the television.
(etc)
Personally, I think it would be a serious hassle to write this sort of
game using the standard room-based IF engine. You'd really need
something like what's suggested here occasionally, a system where
everything is on a grid and has more exact relative positions.
>--Z
Helen
Stephen Granade <sgra...@phy.duke.edu> writes:
>
> On Tue, 4 Feb 1997, Kathleen Fischer wrote:
> > Graham Nelson wrote:
> > > Most events in
> > > adventure games are perceived by means of sight, so that being
> > > in darkness cuts the player off from almost every aspect of the
> > > physical place.
> >
> > What an interesting thought... write a game from the point of view of
> > somebody who is visually impaired. Everything would be done by touch,
> > taste, sound and smell. Sounds like a nice competition game (not that I
> > have time!)
>
> I believe at one point Mr Wilson was planning such a game, though I
> haven't heard him speak of any game other than Avalon for quite a while.
> Is this true, GKW, or is my memory faulty?
>
> 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_
>
What about writing a game from the point of view of an animal ?
you can use different senses (like, sense of smell for the dog will be
the most important; bats have infra-sound location capabilities, etc)
and generally it will be fun (I would be thrilled to play, for example,
a cat !)
Helen
Den of Iniquity
On Tue, 4 Feb 1997, Kathleen Fischer wrote:
>What an interesting thought... write a game from the point of view of
>somebody who is visually impaired. Everything would be done by touch,
>taste, sound and smell. [...]
>Of course, given the way Inform handles Darkness, I guess that really
>wouldn't be possible, would it (she says from the point of view of
>complete ignorance)?
Actually, if the _whole_ game is to be played in darkness or
semi-darkness, blindness or semi-sightedness, it would be very easy to
handle, simply by tailoring all descriptions to emphasise the other senses
and ensuring that the player is never plunged into darkness (which would
spoil the whole effect). A few adjustments to scope rules (assume the
player can find 'things' by memory or scrabbling around)... Or am I
missing something obvious?
--
Den
Carl Muckenhoupt
Kathleen Fischer <kfis...@greenhouse.llnl.gov> writes:
>Of course, given the way Inform handles Darkness, I guess that really
>wouldn't be possible, would it (she says from the point of view of
>complete ignorance)?
Sure it's possible. Just don't use darkness. Treat all rooms as
lit, but describe them non-visually. I suppose you'd make a lot
of objects hidden until the player notices them, and remove the verb
"look", and alter "examine" to reflect that it now involves touching
the object rather than looking at it. But the technical difficulties
are minor. The real challenge would be in making a convincing
job of the design and the prose.
--
Carl Muckenhoupt | Text Adventures are not dead!
b...@tiac.net | Read rec.[arts|games].int-fiction to see
http://www.tiac.net/users/baf | what you're missing!
Gareth Rees
Magnus Olsson <m...@bartlet.df.lth.se> wrote:
> I find that my code is full of things like
>
> if (location == thedark)
> move foo to real_location;
> else
> move foo to location;
For exactly this reason you should try to avoid using `location' or
`real_location' in your code. It is almost always better to write
move foo to parent(player);
in these circumstances. In some cases, one might want to write
move foo to container(player);
where the `container' function is given by something like
[ container o;
do {
o = parent(o);
} until (o == NULL || parent(o) == NULL ||
(o hasnt supporter && o hasnt open));
return o;
];
--
Gareth Rees
Magnus Olsson
In article <yxs3evahv...@stint.cl.cam.ac.uk>,
Gareth Rees <gd...@cl.cam.ac.uk> wrote:
>Magnus Olsson <m...@bartlet.df.lth.se> wrote:
>> I find that my code is full of things like
>>
>> if (location == thedark)
>> move foo to real_location;
>> else
>> move foo to location;
>
>For exactly this reason you should try to avoid using `location' or
>`real_location' in your code. It is almost always better to write
>
> move foo to parent(player);
>
>in these circumstances.
Of course, this depends on what I'm trying to do. Should a thing I drop,
for example, end up on the floor or on the chair I'm sitting on?
Using location/real_location is IMHO the best way of actually getting
at the room teh player is in, and not some intervening container.
But, of course, I don't perform the test above all the time; instead
I've given the player a method that returns location or real_location
depending on the lighting:
move foo to player.real_loc();
>In some cases, one might want to write
>
> move foo to container(player);
>
>where the `container' function is given by something like
>
> [ container o;
> do {
> o = parent(o);
> } until (o == NULL || parent(o) == NULL ||
> (o hasnt supporter && o hasnt open));
> return o;
> ];
Isn't NULL = 0xffff (I suppose you mean "nothing")?
This function, along with
[ contains outer inner;
o = inner;
do {
if (o in outer)
rtrue;
o = parent(o);
} until (o == 0);
rfalse;
];
should IMHO be a part of the standard Library; they're simply so useful.
(contains(box, gnat) is true if and only if there is a chain of containers-
within-containers where the outermost is the box and the gnat is inside the
innermost one; contains(player, penny) is true if and only if the player
is carrying the penny or something that contains the penny, and so on).
Gerry Kevin Wilson
In article <Pine.SUN.3.91.970204...@bigbang.phy.duke.edu>,
Stephen Granade <sgra...@phy.duke.edu> wrote:
>
>I believe at one point Mr Wilson was planning such a game, though I
>haven't heard him speak of any game other than Avalon for quite a while.
>Is this true, GKW, or is my memory faulty?
I was going to, at one point. Sight Unseen. I doubt very much I'll be
doing another full length game after I finish Avalon though. Well, full
length text adventure, anyways. I'll just point out here that Magnus'
Aayela game has already explored this a little bit.
I imagine that it would be an interesting game, though, provided it was
done accurately. Sightless folks are far from helpless, and an I-F game
with a blind protagonist should reflect this.
Anyways, that's my two cents on the topic.
--
"Stress? WHO ME???!!! Never."
Lucian Paul Smith
Carl Muckenhoupt (b...@max.tiac.net) wrote:
: Kathleen Fischer <kfis...@greenhouse.llnl.gov> writes:
: >Of course, given the way Inform handles Darkness, I guess that really
: >wouldn't be possible, would it (she says from the point of view of
: >complete ignorance)?
: Sure it's possible. Just don't use darkness. Treat all rooms as
: lit, but describe them non-visually. I suppose you'd make a lot
: of objects hidden until the player notices them, and remove the verb
: "look", and alter "examine" to reflect that it now involves touching
: the object rather than looking at it. But the technical difficulties
: are minor. The real challenge would be in making a convincing
: job of the design and the prose.
One of These Days (TM) I plan on writing such a game. I've moved from
the purely theoretical phase to the background research phase by having a
few e-mail conversations with a blind computer user from this group, and
subscribing to a few blind list-serves. One thing that she mentioned was
to _not_ remove the 'look' verb--'look' essentially means 'perceive', but
is easier and less awkward to use.
For example, I took as final and clinching proof that the phrase, "See
Ya" no longer means what it used to mean when she signed off with it once
(and she lives in another country to boot!) However, she said that the
phrase is just as valid for the blind community as for the rest of us.
The sentiment is there, even if the specific semantics are not.
However, your last sentence is exactly correct, and will be by far the
largest hurdle to overcome if I ever get past the research phase.
-Lucian "Lucian" Smith
David Glasser
In article <Pine.SGI.3.95L.97020...@ebor.york.ac.uk>, Den
of Iniquity <dms...@york.ac.uk> wrote:
> On Tue, 4 Feb 1997, Kathleen Fischer wrote:
>
> >What an interesting thought... write a game from the point of view of
> >somebody who is visually impaired. Everything would be done by touch,
> >taste, sound and smell. [...]
> >Of course, given the way Inform handles Darkness, I guess that really
> >wouldn't be possible, would it (she says from the point of view of
> >complete ignorance)?
>
> Actually, if the _whole_ game is to be played in darkness or
> semi-darkness, blindness or semi-sightedness, it would be very easy to
> handle, simply by tailoring all descriptions to emphasise the other senses
> and ensuring that the player is never plunged into darkness (which would
> spoil the whole effect). A few adjustments to scope rules (assume the
> player can find 'things' by memory or scrabbling around)... Or am I
> missing something obvious?
>
> --
> Den
Note that in a part of Fear (a competition game), you're in darkness and
have to feel everything..
David
dsgl...@hotmail.com
http://www.geocities.com/SoHo/6028/
-
Magnus Olsson wrote:
[snip]
> [ contains outer inner;
>
> o = inner;
> do {
> if (o in outer)
> rtrue;
> o = parent(o);
> } until (o == 0);
> rfalse;
> ];
I've made a routine thad does this very same thing in a game I'm working
on at the moment, though I call it 'ancestorof()'.
--
Nicholas Daley
<mailto:dal...@ihug.co.nz>
Everyone agreed it was a splendid funeral, but no one enjoyed it more
than the deceased himself.
--Pt1 C11 Red Dwarf Grant Naylor