Which door do you mean, the bathroom door or the bedroom door?
Let's try this again. Which door...
I dislike this approach to disambiguation. I think the parser should keep a
low profile and never 'highjack' the story from the narrator. There are few
entities in the known universe that are capable of breaking mimesis in a
good way and a parser is not one of them.
What about this
Your gaze shifts hesitatingly from the bathroom door to the bedroom door.
You furrow your brow, scrub the back of your head and yet you are unable to
make up your mind as to which door to open.
Why not 'blame' ambiguity on the indecisiveness of the player character? The
player will surely get the hint and mimesis will remain unbroken. After all,
the only thing that can be gained from the 'traditional' approach is the
ommision of the verb in the next input line.
I don't know... It might work in some games, but I don't think it would
work as a general solution to the disambiguation problem. For example, the
author might not want to portray the PC as indecisive. Also, having the
computer generate 'interesting' text for each possible disambiguation
situation can be problematic.
IF players tend to quickly learn the standard parser behaviors, and ignore
their effects on mimesis. Disambiguation handling is an example of this, and
some players would probably complain if it's changed too drastically.
If the response to '>BOTH' is what's bothering you, you could always add
code to handle it...
> Which door do you mean, the bathroom door or the bedroom door?
> Let's try this again. Which door...
Knowing how current parsers are apt to handle this, you can look at
it two ways:
1) You deserve the silly response you should get for trying to answer
2) Someone with programming time to spare could catch this and have
it allow you to open both doors. Of course, if the window is open in
the bathroom and a gust of wind blows out your trusty latern, the
slavering grue that is hiding under the bed in the other room is
going to have you for dinner. Darn I hate when that happens. ;)
> I dislike this approach to disambiguation. I think the parser
> should keep a low profile and never 'highjack' the story from the
> narrator. There are few entities in the known universe that are
> capable of breaking mimesis in a good way and a parser is not one
> of them.
I think that is less mimesis breaking than messages about missing or
not-visible items which seem to be of the sort 'I can't see that
> What about this
> Your gaze shifts hesitatingly from the bathroom door to the
> bedroom door. You furrow your brow, scrub the back of your head
> and yet you are unable to make up your mind as to which door to
Great idea, but it'll only work for those two doors. You'd have to
have a routine that checks each door in a location for a custom
disambig message to consider this approach.
How about a location that has several doors? Three, four custom
messages? I'm playing around with a WIP that has long corridors, with
many doors. I wouldn't want to consider this idea in such a work.
It's hard enough now.
> Why not 'blame' ambiguity on the indecisiveness of the player
> character? The player will surely get the hint and mimesis will
> remain unbroken. After all, the only thing that can be gained
> from the 'traditional' approach is the ommision of the verb in
> the next input line.
This could probably be tweaked a little if parser messages weren't
first person oriented. Fixing that is a much bigger problem.
In years of working around at IF programming, I've come to understand
that there are some things that you should take time to worry about
and some you shouldn't. Players don't always think the same things
are as important as programmers do. That probably has something to do
with why compass direction is still used, and why message of this
sort are accepted with little second thought.
But this is all congecture and opinion, so I could be wrong. You may
be right, I might be crazy, but that's another story. *L*
Tom Raymond af956 AT osfnDOTorg
-----= Posted via Newsfeeds.Com, Uncensored Usenet News =-----
http://www.newsfeeds.com - The #1 Newsgroup Service in the World!
-----== Over 80,000 Newsgroups - 16 Different Servers! =-----
It will also very quickly become *very* tedious, unless you have a rather
special kind of game. To put it another way: I think you underestimate
the number of times a typical player causes this kind of disambiguation
For example, I tend to type things like "open door" all the time even
when I know there are more than one door. Sometimes this is pure
laziness, sometimes it's because I really want to try some command
on a set of objects. I actually find it easier to do this:
> read book
Which book do you mean, the red book, the green book or the blue book?
(snip contents of red book)
> read book
Which book do you mean, the red book, the green book or the blue book?
> read red book
> read green book
Why? Beacuse if I'm using an interpreter where the last command
can be realled by pressing a key, the first method saves a lot
>IF players tend to quickly learn the standard parser behaviors, and ignore
>their effects on mimesis. Disambiguation handling is an example of this, and
>some players would probably complain if it's changed too drastically.
I'd say that disambiguation handling is a bit like using compass
directions for moving about: theoretically, a big mimesis-breaker;
in practice, something that people quickly accept as just another
| >OPEN DOOR
| Which door do you mean, the bathroom door or the bedroom door?
| Let's try this again. Which door...
| I dislike this approach to disambiguation. I think the parser should keep a
| low profile and never 'highjack' the story from the narrator. There are few
| entities in the known universe that are capable of breaking mimesis in a
| good way and a parser is not one of them.
| What about this
| >OPEN DOOR
| Your gaze shifts hesitatingly from the bathroom door to the bedroom door.
| You furrow your brow, scrub the back of your head and yet you are unable to
| make up your mind as to which door to open.
That's interesting; I find the latter approach to be much more
mimesis-breaking. I know what door I wanted to open, but my request
was unclear. In the first case, the game catches my mistake before
the command reaches the game, and when I clarify my input, the story
proceeds. In the second case, the game treats my mistakenly ambiguous
input as if I earnestly desired to execute it despite its obvious
silliness, which not only requires me to read a paragraph to figure
out the real problem, but also treats me like a dumbass.
My opinion is generally that trying to put every single thing in the
context of the game world itself actually defeats mimesis, since there
will be places where the shoehorning is obvious. Another example is
>ASK FRED ABOUT DOOR
"Which door do you mean, the bathroom door or the bedroom door?"
which is a feature that has appeared in some games (I'm pretty sure).
I'd much rather have the computer catch this up front than have Fred
respond to me in-game like a Vulcan.
In Inform, this will result in: "You can't use multiple objects
with that verb."
>I dislike this approach to disambiguation. I think the parser
>should keep a low profile and never 'highjack' the story from
>the narrator. There are few entities in the known universe that
>are capable of breaking mimesis in a good way and a parser is
>not one of them.
I think that providing a simple and consistent communication link
between the player and the game is more important than mimesis,
in this case.
Unless it's an intentional artifice by the author, the parser
ought to be predictable and subservient to the player.
>What about this
>Your gaze shifts hesitatingly from the bathroom door to the
>bedroom door. You furrow your brow, scrub the back of your head
>and yet you are unable to make up your mind as to which door to
This would be a good thing to add if the player were playing
"Let's Make a Deal", but otherwise it's obtrusive and misleading,
and generating it puts a terrible burden on the author, who has
enough combinatorial explosion problems already.
I agree your proposal is better than the "Let's try again"
question, though. The parser should know if it can or cannot
comply with "open both doors".
>Why not 'blame' ambiguity on the indecisiveness of the player
>character? The player will surely get the hint and mimesis will
>remain unbroken. After all, the only thing that can be gained
>from the 'traditional' approach is the ommision of the verb in
>the next input line.
I don't believe mimesis can be achieved at all if the player is
constantly misunderstood, or badgered, or lied to by the parser
(except with authorial complicity, etc...). That's why, for
instance, I prefer the Infocom and TADS style of admitting that
it doesn't know every word the player types.
It should also admit when it doesn't understand or cannot
comply with what the player types, like when a player tries to:
"open both doors."
Even a pathetically weak parser can be good enough if it doesn't
pretend to be more powerful than it is, e.g., the original
Adventure two-word parser, or the "click or click-and-drag"
parsers of many graphic adventures. But a powerful parser that by
default misleads the player will just cause frustration, I think.
For example, consider a simple two-word parser with randomized
error messages for when it can't understand the input:
>UNLOCK DOOR WITH KEY
What a concept!
>STICK KEY IN DOOR AND TURN IT
You'll have to think of something else.
>SHOVE KEY THROUGH KEYHOLE AND WRENCH IT TO THE RIGHT
It doesn't work.
>CRAM GAME WHERE SUN DON'T SHINE
A futile attempt.
Neil Cerutti <cer...@trans-video.net>
What to the uninitiated is a mimesis-breaker is often the convention of the
inner circle. How mimetic are the rituals and symbolic gestures of
government, religion, the legal system? Man is a user of symbols, and
symbols transcend the reality of everyday experience.
Since when are the rituals of government or the legal system an art
form (religion is a more arguable case, I suppose)? Does it even make
sense to talk about mimesis here?
Forgive me for picking a nit that isn't central to your argument, but for
this *particular* example, the proper response from the parser is to open
both doors. (I say this not just because it's what tads does, but because
it's what the player plainly told the parser to do.)
mjr underscore at hotmail dot com
Interesting approach, although as a practical matter, I think such a lengthy
passage that really means "which one do you mean" would become tedious for
the player after a few repetitions. And I'm not sure it really does
maintain mimesis - why should the player's use of an ambiguous noun phrase
imply that the player character is indecisive? It's probably not the case
that the player is acting indecisively by using an ambiguous phase - in
virtually every such case, the player has a specific object in mind, and
isn't aware that the phrase is ambiguous.
Yeah, heh. And besides it strays too far off the thread!
>Which door do you mean, the bathroom door or the bedroom door?
>Let's try this again. Which door...
In PAWS this would open both doors automatically...
> Open Door
The bathroom door opens, revealing... [whatever description]
The bedroom door opens, revealing... [whatever description]
Or if you were using the active voice form:
You open the bathroom door, revealing... [whatever description]
You open the bedroom door, revealing... [whatever description]
Unexpected behavior for experienced TADS/Inform players, but oddly
appropriate here... :)
"The world is my home, it's just that some rooms are draftier than
others". -- Wolf
This is actually a different question, and a non-trivial one:
which verbs should accept multiple objects?
"Magnus Olsson" <m...@df.lth.se> wrote in message
This is something I've thought about quite a bit. My gut reaction is
that ALL verbs should accept multiple objects. (Inform, by default, does not
allow WEAR ALL or DISROBE ALL, which I find annoying.) The only situation I
can think of where this might not be good is when performing the action on a
certain noun generates a lot of text:
door: You can only do that to something animate.
table: You can only do that to something animate.
Rocco: You passionately embrace Rocco and your two bodies fuse as one in a
sensual kiss <snipped several paragraphs>.
chinchilla: Keep your mind on the game.
Although this would probably be common with EXAMINE, it could really
happen with any verb, since almost anything could serve as trigger for some
kind of major shift like that.
--OKB (Bren...@aol.com) -- no relation to okblacke
"Do not follow where the path may lead;
go, instead, where there is no path, and leave a trail."
...which is why I've always assumed EXAMINE isn't usually allowed....
"OKB -- not okblacke" <bren...@aol.comRemove> wrote in message
Yes, it can be. This reminds me of an old IF trick I've heard of: in some
games, EXAMINE ALL is disallowed, but you can still find all implemented
objects in a room, usually without side-effects, by typing SMELL ALL. :)
My gut feeling on this is to either have ALL work with every verb, or
disallow it entirely. I realize either method can cause problems, but they
seem better to me than setting up a ton of special cases for dealing with
one optional word.
An alternative may be to have 'hidden' objects that don't react to any
command until they're seen, but even that may be more trouble than it's
Many people feel as you do about this, but it is my opinion that an author
who worries about making command entry too convenient for the player is
worrying about the wrong things.
It might make more sense to have ALL only work with objects that are
"obvious" (not just mentioned in the room description). That way you
couldn't use "TAKE ALL EXCEPT <things you can obviously take>" to get a
list of things that are implemented but not obvious.
Of course, some verbs sensibly shouldn't allow multiple objects: openning
two doors at the same time is rather impractical, both because it might
break puzzles and because you probably can't reach or get the right
leverage. A message like "You'll have to do that one object at a
time." might be better, perhaps with a disambiguation-question-like
interface for ordering the actions:
] OPEN BOTH DOORS
You'll have to open one at a time. Which do you want to open first, the
bedroom door, the closet door, or the bathroom door?
You open the bathroom door. Which door do you want to open next, the
bedroom door or the closet door?
You open the closet door. Do you want to open the bedroom door?
You open the bedroom door. The monster under the bed wakes up in the
breeze from the bathroom window, charges out of the bedroom, and crashes
right into the open closet door. It crumples to the floor, dazed.
*This .sig unintentionally changed*
Perhaps a board-game equivalent could be, such as in the game Scrabble,
disallowing the use of words from another language other than the language
that the players of the game have agreed to play in. A rule like this,
while it makes it "harder" for the player (consider what letters you could
get rid of if you could use any language!), is a designed limitation.
Do you see this as a comparable example? Or am I full of bollocks? :)
"Mike Roberts" <mjr-S...@hotmail.com> wrote in message
I think there's a difference between the parser accepting an ALL and the
action actually working. What I dislike about much of Inform's standard
grammar is that the ALL request is disallowed in the initial parsing stage; to
change this behavior, you have to change the verb's grammar. (I have no idea
how TADS handles this.)
I think it would be better to separate the "can we parse an ALL" from the
"can we do this to ALL". So perhaps OPEN ALL DOORS would by default work, but
if some puzzle situation made this impractical you could specify this -- but
specify it in the door object(s), not in the verb definition.
Hmmm, Polish would be good for that. ("Kwqczfy? It's
a perfectly good word!")
I wonder if Polish people have Scrabble sets
with different letter scores?
Greg Ewing, Computer Science Dept, University of Canterbury,
Christchurch, New Zealand
To get my email address, please visit my web page:
> I wonder if Polish people have Scrabble sets
> with different letter scores?
Actually, they do. I recall reading a Locus report on Polish SF, where the
correspondent mentioned as a sidebar that he played Scrabble with some
writers in Warsaw -- the point that stuck with me is that Z is the most
common tile, and it's worth 1 point.
Paul O'Brian obr...@colorado.edu http://ucsu.colorado.edu/~obrian
FINALLY, an alternative to EXPENSIVE therapy! It's SPAG, the text
adventure magazine! Check it out at http://www.sparkynet.com/spag
Issue #26 has just arrived!
> x pool
What pool do you mean, the pool table, the pool pocket or the pool equipment?
when I only knew about the "pool table", then discovering other objects that I
was supposed to have found otherwise.
Actually this is something the standard disambiguation procedures (in Tads,
Inform, Hugo, whatever) "leads into", and so it's something the writers sh/could
worry about (if they want to have a good parser built into their games, that
A good solution, as someone already pointed out (I think), is to have an
attribute 'seen' or 'visible' given only to objects that are mentioned explictly
to the player (as part of any text), and use only these in the disambiguation.
Gabe McKean wrote:
> > ...
> Yes, it can be. This reminds me of an old IF trick I've heard of: in some
> games, EXAMINE ALL is disallowed, but you can still find all implemented
> objects in a room, usually without side-effects, by typing SMELL ALL. :)
> My gut feeling on this is to either have ALL work with every verb, or
> disallow it entirely. I realize either method can cause problems, but they
> seem better to me than setting up a ton of special cases for dealing with
> one optional word.
> An alternative may be to have 'hidden' objects that don't react to any
> command until they're seen, but even that may be more trouble than it's
Probably. I remember seeing that Scrabble publishes in a *lot* of
different languages when I stumbled across a Russian edition. (My college
class was taking a study break. Scrabble rules are interesting in
Russian, partly because there are some letters that only serve to make a
given consonant "hard" or "soft", and don't contribute to the word
What I'd like to see is a Scrabble game in High Elvish or some other
language made up for fantasy or sci-fi. (Klingon Scrabble? Tiles with
the Riven-ese alphabet and numbers?) The runes would certainly *look*
cool on a board, and be a heck of a conversation piece. :)
-- With Best Regards,
Matthew Funke (m...@hopper.unh.edu)
No, it isn't.
pa' jIHpu'; Quj vIta'pu'; yIvbeH vISuqpu'.
Colloquially translated: Klingon Scrabble works fine. Unfortunately,
the only photos I can find on the web of people playing it manage to
cut off the actual board itself.
Alan Anderson, professional programmer and amateur Klingonist
proud member of the Klingon Language Institute since 1995
qo'mey poSmoH Hol -- language opens worlds -- http://www.kli.org/
You're approaching interactive fiction rather differently than I am if you
think in terms of leveling the playing field, as it were, in the contest
between author and player. In my view, the notion that artificial
constraints are needed to keep the player from taking unfair advantage of
the poor author is absurd, because the contest, if it is a contest, is
heinously one-sided in favor of the author to start with. In my view, IF is
best approached not as a contest between author and player but as a
collaboration: the author's job is to help the player as much as possible
without actually doing all the work.
One might share my view of the inherently unlevel playing field and still
see "all" as being on a slippery slope to commands such as "solve puzzle"
and "win game," but it is sufficiently clear to me that "all" is an element
of the user interface, rather than of the simulation, that I think it's best
to allow it for all commands. To me, "all" is simply short-hand for listing
the visible objects (or the obviously suitable subset of the visible
objects) one by one, and in that sense it simply cannot give away anything
that should not already be apparent. Unlike "win game," it does not require
that the player character do something that the player only vaguely
specifies; "examine all" is quite specific and doesn't require that the PC
know anything more than the player. If we accept this, then the worst harm
that "all" can do to a puzzle's difficulty is to reduce the tedium of trying
a command on all visible objects individually; a player resorting to such
tactics has clearly already lost any sense of immersion in the game, in
which case speeding things up mechanically might at least offer the player
hope of getting back into the story.
I would claim that a puzzle whose difficulty is actually damaged by allowing
"all" with a verb is not a very good puzzle to start with, because it must
be deriving its difficulty either from the obscurity of the verb or
verb-object combination (which is to say it's a "guess the verb" puzzle), or
from the sheer number of objects available to try. If it's the former, it
should be redesigned so that the verb isn't hard to guess, which eliminates
the objection to "all." If it's the latter, there are well understood
approaches ("there must be thousands of files here; you'll have to pick one
by account number if you want to read it") that make the matter of "all"
"Mike Roberts" <mjr-und...@hotmail.com> wrote in message