Probabilistic command interpreters, etc.

70 views
Skip to first unread message

Neil Toronto

unread,
Dec 2, 2004, 1:05:42 AM12/2/04
to
I do machine learning research at BYU. I've been interested in IF for
a long time (since I played "Dog Star Adventure" on my C64), and more
recently in applying machine learning techniques to it. Somehow I
hadn't heard of raif until a couple of days ago, when Slashdot linked
to it. Go figure.

I've been through the FAQs and looked up a few of the most popular IF
engines. Many have very sophisticated command interpreters, which is
nice. (I still remember trying to find *exact* sequences of words in
the older stuff...ick.) What I haven't seen yet is a *probabilistic*
command interpreter, and I'm interested in making one.

(IF presents some unique challenges to probabilistic reasoning, which
is why I'm interested in it.)

I'm posting because I want to make *absolutely sure* nobody's done
this yet. If they have, I want to see what they did, and what became
of it. I also want to know how useful people around here think it
would be.

Here's how it would work: rather than naming objects and supplying
handlers for certain verbs (which is how I assume IF engines generally
work - please correct me if I'm wrong), the IF author would create
example commands and classify them.

"take the broom" -> action: take
"take the broom" -> direct object: broom
"take the broom" -> implement: none
"unscrew the bolt" -> action: unscrew
"unscrew the bolt" -> direct object: bolt
"unscrew the bolt" -> implement: screwdriver
"unscrew the bolt with a penny" -> action: unscrew
"unscrew the bolt with a penny" -> direct object: bolt
"unscrew the bolt with a penny" -> implement: penny

The IF engine would use these examples to infer what the user means:
that you did ____ to ____ with ____, and fill in the blanks. At first
blush, this doesn't seem too useful. Here are the gains, though:

1. You can supply it with the crappiest syntax ever, and it can figure
out what you mean, like a human can. "book give woman" doesn't make
too much sense to a normal parser, but *you* know what I mean, and it
could figure it out, too.

2. It could be trained in-game. Say you type in something you think it
ought to understand. It doesn't. Once you figure out what it wants,
you can tell it to equate that with what you typed in the first place,
and it would add it to its list of examples.

3. It could draw correlations. Contrived example: if one type of
object is referred to as a "wrench" and another as a "spanner," it
would be able to tell from context that the words are synonymous and
allow you to use them interchangeably with each object.

4. The IF author can classify things any way he pleases. Add a new
one: "quietly," and classify all the examples. Thereafter, it would
classify everything the player does as either "quietly" or "not
quietly."

5. Automatic disambiguation. If you're not very specific in what you
type, it would pick the most likely thing. If you need to do the
unlikely thing, you could be more specific.

The big drawback is CPU requirements. The algorithms are nasty,
frankly, so this would work primarily for things about as powerful as
PCs. It's actually only recently that PCs became powerful enough to do
this kind of stuff.

Another direction I'm thinking of researching is in modeling complex
human behavior in game characters. Is the guard suspicious of you?
That's quite difficult to program. However, given a few examples of
circumstances in which he is and a few in which he isn't,
probabilistic algorithms (and other machine learning algorithms) can
figure out how to determine that for every circumstance. The IF author
would just supply those circumstances as examples rather than trying
to write a function that does it.

A function that determines suspicion using six yes/no inputs
potentially has to consider 64 cases. Add real inputs (monetary
values, time of day, etc.), and it gets much, much worse. A machine
learning algorithm could figure it out with as few as 10 or 15
examples.

Anyway, thanks for letting me type your eyes out. If anybody has
information on these two topics (probabilistic command interpreters
and modeling complex human behavior in game characters), please let me
know or point me to it.

Cheers!

Graham Holden

unread,
Dec 2, 2004, 10:32:15 AM12/2/04
to
On Thu, 02 Dec 2004 14:07:46 GMT, Anson Turner <platyp...@yahoo.com>
wrote:
>programming, understood English better than I do, and featured Actual
>Lifelike NPCs(tm).

You mean "Genuine People Personality" (tm), surely?

Regards,
Graham Holden (g-holden AT dircon DOT co DOT uk)
--
There are 10 types of people in the world;
those that understand binary and those that don't.

Aleks Jakulin

unread,
Dec 2, 2004, 11:18:27 AM12/2/04
to
Neil Toronto:

> I'm posting because I want to make *absolutely sure* nobody's done
> this yet. If they have, I want to see what they did, and what became
> of it. I also want to know how useful people around here think it
> would be.

Great to see another machine learning person around!

Nobody has done this. Of course, you should educate yourself about the
state of the art by looking at the sources of games the authors kindly
released. Inform and TADS libraries seem to be the state of the art
currently, as much as parsers go. This is important: you shouldn't
reinvent the wheel. Second, make sure that your tools will be useful
for the authors. Always keep the authors in mind, becuase it's them
who will make your thing live or die. Third, focus: don't do character
AI, just focus on intelligent parsing combined with some
model-of-the-world system.

Of course, most people don't know what can be done. Indeed, what
you're suggesting is already done in many cases, but by torturous
manual programming. I'm not sure you care about my opinion, but I'm
cheering :) It's a fabulous graduate research topic.

--
mag. Aleks Jakulin
http://www.ailab.si/aleks/
Artificial Intelligence Laboratory,
Faculty of Computer and Information Science,
University of Ljubljana, Slovenia.

Michael Coyne

unread,
Dec 2, 2004, 11:27:05 AM12/2/04
to
On Thu, 02 Dec 2004 15:32:15 +0000, Graham Holden said to the parser:

> You mean "Genuine People Personality" (tm), surely?

Sounds ghastly.


Michael

Message has been deleted

Neil Toronto

unread,
Dec 2, 2004, 2:17:25 PM12/2/04
to
Anson Turner wrote:
>
> Look, Neil... I knew about this group for a good four or FIVE days
> before deciding I could create an IF system that required no
> programming, understood English better than I do, and featured Actual
> Lifelike NPCs(tm). And that's true of most reading this. Maybe you
> should aim for something a little easier first. Like rope.
>
> Anson.

Ick. Rope.

Did you mean modeling in a game world, or to hang myself with? :)

Look, Anson. Most people haven't heard of machine learning and haven't
got a clue what it's capable of. My final project in an
undergraduate-level machine learning course was able to predict a
guilty/not-guilty verdict in assault cases with 95% accuracy. Have you
flown Delta? Did you know the planes are capable of landing themselves,
and that they do it better than the pilots do? Machine learning. (They
have the pilots land most of the time so they don't get rusty.) The best
spam filters - the probabilistic ones - get over 98% accuracy rates.
That's machine learning, too.

Sorry if I'm snippy - but, you know, eye for an eye, and all that.
Here's hoping we both end up blind and toothless. :D The *only* thing I
wanted to know was whether or not a probabilistic command interpreter
has been done, so I could avoid a bunch of extra work if it had.

Sounds like it hasn't, so off I go...

(By the way, just to clear something up: I don't have any delusions
about creating an IF system that requires no programming.)

Emily (emshort - Emily Short, right?) suggested working it into an
existing game. That's a great idea. I was looking at TADS yesterday, and
it looks very, very nice. (I'm also impressed with an author that feels
no compunctions about rewriting everything when he needs to.) I'll get a
proof of concept working first with a simple world model before I try
wedging a new command interpreter into a system that was built around
another one.

Neil Toronto

unread,
Dec 2, 2004, 2:30:38 PM12/2/04
to
ems...@mindspring.com wrote:

> neil.t...@gmail.com (Neil Toronto) wrote in message news:<6c8b4b4e.04120...@posting.google.com>...
>
> It would also be nice to have a standard base of examples the author
> could start from, since most games implement TAKE, for instance.
>

Yep. That's on the slate. :)

>>Another direction I'm thinking of researching is in modeling complex
>>human behavior in game characters. Is the guard suspicious of you?
>>That's quite difficult to program. However, given a few examples of
>>circumstances in which he is and a few in which he isn't,
>>probabilistic algorithms (and other machine learning algorithms) can
>>figure out how to determine that for every circumstance. The IF author
>>would just supply those circumstances as examples rather than trying
>>to write a function that does it.
>
>

> This seems a lot fuzzier and more open-ended, given that the
> circumstances of the player's interactions with NPCs are often not
> very well defined in the world model. That's not to say that what you
> describe is impossible, but I think this *would* require some
> replacement of, or substantial addition to, existing types of world
> model.

Possibly. What I'm thinking of isn't so much a replacement for any
existing NPC stuff, but a very small augmentation. It wouldn't dictate
anything the NPC does, but allow the author to create fuzzy functions.
Something like this, for example (definitely in pseudocode), goes in the
guard code:

if is_suspicious(time_of_day, saw_you_with_certain_item,
hasnt_seen_you_doing_thus_and_such,
heard_you_doing_something_suspicious, etc., etc.) then do your normal
suspicious stuff...

...and the single "if" would replace the normal batch of nested "if"
statements that determines whether the guard is suspicious of you. You
might declare a fuzzy function like this:

fuzzy is_suspicious(time_of_day, saw_you_with_certain_item,
hasnt_seen_you_doing_thus_and_such,
heard_you_doing_something_suspicious, etc., etc.): boolean
[example] -> true
[example] -> true
[example] -> false
[example] -> true
[example] -> false

This is something that could be more easily stuffed into an existing
system, though it would greatly benefit from actions being classified as
quietly, discreetly, etc.

The biggest problem I can see with this is the possibility of having a
runaway book. For example, it might be impossible to ensure that the
game can be won, and nearly impossible to determine why, if you use it
too much. Heh.

ems...@mindspring.com

unread,
Dec 2, 2004, 12:26:33 PM12/2/04
to
neil.t...@gmail.com (Neil Toronto) wrote in message news:<6c8b4b4e.04120...@posting.google.com>...
> Here's how it would work: rather than naming objects and supplying
> handlers for certain verbs (which is how I assume IF engines generally
> work - please correct me if I'm wrong), the IF author would create
> example commands and classify them.

To the best of my knowledge, this hasn't been done before in a
released tool (which doesn't mean that no one has tried it at home).
Sounds interesting -- the more so if it could in some way be made to
work with an existing IF language rather than reinventing the world
model, etc., from scratch.

It would also be nice to have a standard base of examples the author
could start from, since most games implement TAKE, for instance.

> Another direction I'm thinking of researching is in modeling complex


> human behavior in game characters. Is the guard suspicious of you?
> That's quite difficult to program. However, given a few examples of
> circumstances in which he is and a few in which he isn't,
> probabilistic algorithms (and other machine learning algorithms) can
> figure out how to determine that for every circumstance. The IF author
> would just supply those circumstances as examples rather than trying
> to write a function that does it.

This seems a lot fuzzier and more open-ended, given that the

Neil B Toronto

unread,
Dec 2, 2004, 4:16:53 PM12/2/04
to
Sorry, replying to my own post for a stupid detail.

Neil B Toronto wrote:
> Third, the classification accuracy is 100% on the training data. That
> means if a user types in what the IF author supplied as an example for
> an action or object, the input will be classified as the action or
> object. Generally, probabilistic algorithms won't do that.

Generally, probabilistic algorithms won't *guarantee* that.

Michael Roy

unread,
Dec 3, 2004, 1:40:46 AM12/3/04
to
Andrew Plotkin wrote:

> I really think that if the parser was magically smarter, and could
> accept more variants of commands, the player would (paradoxically)
> find himself less able to control the game. He would be less able to
> distinguish the significant differences in his commands from the
> incidental ones -- the pattern would be more difficult to see.

Really? Why do you say that? The way I see it, the most basic test for
a new (improved?) parser would be its ability to return the same output
for the same input with the possible exception of disambiguation, etc.
Thus, if the parser becomes magically smarter while the players remains
the same, assuming we have experienced players, they should be able to
achieve the same level of control as before by totally ignoring the fact
that the parser is smarter. Beyond that, I think that a more flexible
parser is a good thing. I recall I once played something which mapped
"i" to "in" instead of "inventory" to my extreme annoyance. Having a
parser capable of figuring out what I probably mean wouldn't hurt (and
any errors it makes wouldn't be as drastic as in an AI that can probably
land an airplane).

Are you suggesting that new players would have less control because they
wouldn't be forced into learning IFese syntax? There, I'd have to agree
that teaching the player to communicate with the computer is easier than
teaching the computer to communicate with the player. Nonetheless, if
we assume the existence of the Better Parser, how does its flexibility
hurts the player's ability to communicate? As I see it, we learn IFese
by hitting up against what the parser can't understand. If we have a
more intelligent parser, we would hit that wall less often and thus
learn less of the "proper" syntax, but we probably wouldn't care either.

--
Michael

Neil Toronto

unread,
Dec 3, 2004, 1:33:22 AM12/3/04
to
Alan Mead wrote:
> On Thu, 02 Dec 2004 14:14:24 -0700, Neil B Toronto wrote:
>
> I think it's the last and you're saying, "Ok, The "command" is what the
> user types and "action" is the action that the user means in the
> vocabulary of the IF author. And I'll make a system that finds what words
> people use to describe any action. Then I'll assume that the action with
> the greatest probability conditional on the command is the intended
> action."
>
> Is that right?
>

That's usually how it works. Mine differs in that it constructs
distributions for each example command, and has a nifty similarity
measure that magically works out context. If an IF author uses the word
"flip" with certain words associated with switches in one place, and the
word "hit" with mostly the same words elsewhere to mean the same action,
it'll be able to draw a correlation and allow the player to use "hit"
and "flip" in both places.

It's very hard to explain how it works over Usenet, especially since I'm
still figuring it out. The similarity measure I'm using has this
property of being able to find correlations, and I don't know exactly
why yet. Isn't research fun?

> The hardest part isn't defining the verbs, either. It's pretty easy to
> make 'slay' a synonym for 'kill'. The hard part is anticipating all the
> synonyms that a player will use. I read an author's website where he
> mentioned that playtesters all failed to "flip" a power switch, they
> instead smacked it, hit it ('hit the power'), etc. I had trouble in a
> game that didn't recognize "tip" as a synonym for "move". In fact, I
> think the game told me that the object was too heavy to tip ... then it
> allowed me to move it. :)
>
> The remedy is pretty simple though... it doesn't require a new parser, it
> just requires that verb synonyms be defined. In other words, it requires
> a process whereby all the author is encouraged to add synonyms... kinda of
> like spell checking a document prompts you for misspellings..
>
> There are some other hardest parts... people describe nouns and then
> forget to define nouns referenced in the description ("You are in a small
> armory. Weapons line the walls." >x weapons "I don't see any weapons
> here." --or-- "You are in a spartan bedroom with only a bed." >x bed "It's
> a spartan bed with only a thin blanket and pillow" >x blanket "I don't see
> a blanket here.")
>

Great stuff. I'll mull over this. :)

A spell checker type thing that gives the IF author hints at what still
needs to be described might be cool. Out of my realm, though.

For the verbs, just a list of synonyms won't do. "Hit" isn't always a
synonym for "flip." ("Flip guard with mace.") Maybe we need a humongous,
tagged corpus of phrases, *not* supplied by the IF author. I've been
assuming the author supplies the parser everything it needs, but I'm
starting to think an outside source might be a good idea...hmm...

It's generally true that the larger the corpus, the better probabilistic
algorithms perform.

Here we go. I've got more context for you. Say this kind of stuff is in
the corpus:

"hit the troll" -> hit (with fist)
"hit the giant beetle" -> hit (with fist)
"hit the switch" -> toggle
"hit the light switch" -> toggle
"hit the lights" -> toggle

Having those kinds of associations in your corpus would allow the parser
to figure out which kind of "hit" you meant.

Of course, that's nearly obviated by this next thing you wrote:

> There is the hardest part that you *do not* associate most verbs with most
> nouns. So a room back from the troll you couldn't machine-gun the hill
> giant... you had to give him the daisy and sneak past while he was in a
> fit of sneezing.
>

...because most of the time you can determine deductively what the verb
meant.

I don't know how you would fix this specific example without some
extremely detailed world modeling, Grand Theft Auto-style.

> There is also the really hard hardest part of making the noun-verb
> relationships clear. For example, I recently wrote a small TADS 3 game
> with a bedroom, a desk and a book. I can "read book" but when I "open
> book" I get an error about the book not being openable. I can fix that
> but basically it comes down to IF being a very thin charade and opening
> books just isn't a level of detail that IF authors usually bother
> with. Mike Roberts (the Linus Torvalds of TADS) has written some
> interesting articles about this.
>

I'll have to look them up. Good info.

>>Second, it's a solution to the notorious "none of the above / I don't
>>know" classification problem. It knows when to say "I really don't
>>understand you" - which ML algorithms usually can't do. This part may
>>end up in a thesis.
>
>
> Sorry, I don't follow.
>

That's my fault. I didn't explain well enough.

So you've got this probability mass function -
P(action|command-you-typed) - for the command the user just input.
You've also got a P(action|command) for each command example given by
the IF author for any action anywhere. (Yes, there are a lot of them. If
there's an outside corpus...jeez.) The other thing you've got - which I
didn't explain - is a probability mass function P(action|nonsense).
Though there's an infinite number of nonsensical/totally ambiguous
commands, you can actually calculate this. If the mass function
P(action|command-you-typed) matches that best, the game doesn't
understand what you meant.

> Well, and a vote for discussing it with the real gate keepers. If someone
> authoritative from one of the full-featured development systems doesn't at
> least say "We'll consider adding your code to our product if you can make
> it do X." then you're wasting your time. Moreover, you'll meet a lot of
> rabble here like myself who have a glancing familiarity with the
> difficulties of writing a parser but the people developing Inform and
> TADS would be the ones who have spend years working on it and they will
> also be in a unique position to describe what it's hard to do with a
> deterministic parser.
>

Excellent idea.

>>Another huge problem that experienced players don't think about much is
>>"guess the syntax." We don't think about it because we *know* the
>
> What are some examples?
>

You gave one, actually, with your machine gun / troll example. The most
obvious problems I can think of come from users thinking the game can
read their mind. You expect a human to be able to figure out that you
want to throw a grenade at the jeep when you tell it to "blow up jeep"
and you have a grenade in your inventory. But we make the user type
either "throw grenade at jeep" or (worse, IMO) "pull pin from grenade,
throw grenade at jeep."

>>I'd like new players to be able to type in whatever they want, and learn
>>the quick syntax as they go.
>
>
> Great.. If you can do it... where "do it" means resolving arbitrary
> commands into noun, verb, indirect object, and direct object bits.
> Otherwise, the existing way that games are described/authored will not
> work.
>

That's pretty much where I want to go.

Cirk R. Bejnar

unread,
Dec 2, 2004, 5:02:08 PM12/2/04
to
neil.t...@gmail.com (Neil Toronto) wrote in message news:<6c8b4b4e.04120...@posting.google.com>...
> I do machine learning research at BYU. I've been interested in IF for
> a long time (since I played "Dog Star Adventure" on my C64), and more
> recently in applying machine learning techniques to it. Somehow I
> hadn't heard of raif until a couple of days ago, when Slashdot linked
> to it. Go figure.

Welcome! It is always good to see new faces around here. Who knows
they might write more games. :-)

> I've been through the FAQs and looked up a few of the most popular IF
> engines. Many have very sophisticated command interpreters, which is
> nice. (I still remember trying to find *exact* sequences of words in
> the older stuff...ick.) What I haven't seen yet is a *probabilistic*
> command interpreter, and I'm interested in making one.

I haven't seen one though you could try searching the raif archives on
groups.google.com to see what comes up. There has periodically been
some discussion of AI programming and how it relates or could relate
to IF. But I don't recall any practical examples.

<snip>


> Anyway, thanks for letting me type your eyes out. If anybody has
> information on these two topics (probabilistic command interpreters
> and modeling complex human behavior in game characters), please let me
> know or point me to it.
>
> Cheers!

Emily Short is a major modern IF writer known for, among other things,
her complex and well written NPC's. Though not exactly what you may
be looking for her discussion of how to effectively characterize a
character may be a good place to start
(http://emshort.home.mindspring.com/NPC4.htm). Also worth taking a
look at is her award winning game Galatea with its marvelously complex
title character and a nifty newer version that shows some of the
calculation behind the scenes
(http://emshort.home.mindspring.com/galatea.htm).

Good Luck,
Cirk R. Bejnar

Alan Mead

unread,
Dec 2, 2004, 11:10:07 PM12/2/04
to
On Thu, 02 Dec 2004 14:14:24 -0700, Neil B Toronto wrote:

> Probabilistic reasoning in ML uses Bayes' rule for estimating
> probabilities:
>
> P(action|command) = P(command|action) * P(action) / P(command)

So, I hope there's no quiz but I think I understand your methodology, at
least in abstract... what's your purpose? What is 'action' and 'command'
here? Is this the business of NPC states or parsing user input? Or
finding synonyms?

I think it's the last and you're saying, "Ok, The "command" is what the
user types and "action" is the action that the user means in the
vocabulary of the IF author. And I'll make a system that finds what words
people use to describe any action. Then I'll assume that the action with
the greatest probability conditional on the command is the intended
action."

Is that right?

That's cool for the commands in the training set, but then that's already
isomorphic with the current state of the art. If everyone uses the
commands that we authors intend, then there's no problem. I don't see how
this will help (but be sure and disagree with a concrete example if I
don't get it...) I especially don't get how this will automagically
understand the context.

At the risk of telling you what you already know and simplifying terribly,
the way TADS works (I can only speak to TADS) is: the IF author defines
nouns and, sometimes, verbs. She then makes associations between the
nouns and the verbs (open the box). Sometimes the nouns have direct
object or indirect object relations with the verbs (kill the troll with
the machine gun).

That's pretty much it... the game displays the nouns' descriptions, the
parser translates user input into verbs (e.g., look) with direct (open
box) or indirect (unlock the box with the gold key) objects and displays
the results. Any engine you write, has to help this simple system work
better.

It may be that hordes of would-be IF players stop playing because they
cannot type "machine gun the troll to a bloody death" or "use the machine
gun to slay the troll" but I don't think most players are that unable to
adopt the straight-forward syntax that games prefer. Oh, I suppose there
are occasional instances where things are not so happy but I don't think
parsing the user's input is the hardest part.

The hardest part isn't defining the verbs, either. It's pretty easy to
make 'slay' a synonym for 'kill'. The hard part is anticipating all the
synonyms that a player will use. I read an author's website where he
mentioned that playtesters all failed to "flip" a power switch, they
instead smacked it, hit it ('hit the power'), etc. I had trouble in a
game that didn't recognize "tip" as a synonym for "move". In fact, I
think the game told me that the object was too heavy to tip ... then it
allowed me to move it. :)

The remedy is pretty simple though... it doesn't require a new parser, it
just requires that verb synonyms be defined. In other words, it requires
a process whereby all the author is encouraged to add synonyms... kinda of
like spell checking a document prompts you for misspellings..

There are some other hardest parts... people describe nouns and then
forget to define nouns referenced in the description ("You are in a small
armory. Weapons line the walls." >x weapons "I don't see any weapons
here." --or-- "You are in a spartan bedroom with only a bed." >x bed "It's
a spartan bed with only a thin blanket and pillow" >x blanket "I don't see
a blanket here.")

There is the hardest part that you *do not* associate most verbs with most


nouns. So a room back from the troll you couldn't machine-gun the hill
giant... you had to give him the daisy and sneak past while he was in a
fit of sneezing.

There is also the really hard hardest part of making the noun-verb


relationships clear. For example, I recently wrote a small TADS 3 game
with a bedroom, a desk and a book. I can "read book" but when I "open
book" I get an error about the book not being openable. I can fix that
but basically it comes down to IF being a very thin charade and opening
books just isn't a level of detail that IF authors usually bother
with. Mike Roberts (the Linus Torvalds of TADS) has written some
interesting articles about this.

> It's got a couple of nifty properties. First, that contextual knowledge
> you refer to naturally falls out of the math. It's capable of finding
> first-order correlations. So if you refer to hitting something with
> something else as "whacking" and "smacking" in one place, and "smacking"
> and "hitting" somewhere else, it'll let you "hit" in the first place and
> "whack" in the second. I can also find more complex correlations
> involving multiple words.

I don't see how this works exactly but I grant that it could with the
right data and even if it's killing a fly with a sledgehammer, what we all
really want for Christmas are dead flies. But I wonder what data you need
and whether this is the easiest route to building out synonyms.

> This partially solves the the "guess the noun" and "guess the verb"
> problems problems you referred to later in your post.

Guess the noun is pretty different from guess the verb.

> Second, it's a solution to the notorious "none of the above / I don't
> know" classification problem. It knows when to say "I really don't
> understand you" - which ML algorithms usually can't do. This part may
> end up in a thesis.

Sorry, I don't follow.

>> At any rate, any such work would only be helpful if it were embedded
>> transparently into an existing product such as Inform or TADS 3.
>> Without the remaining system, no one if likely to use such an engine to
>> write IF. So you should make your case to those authors. I suspect
>> those authors are also best able to tell you where they see weaknesses
>> in parsing.
>>
>>
> That's...three votes for working it into Inform or TADS. I think I
> believe it now. :D

Well, and a vote for discussing it with the real gate keepers. If someone
authoritative from one of the full-featured development systems doesn't at
least say "We'll consider adding your code to our product if you can make
it do X." then you're wasting your time. Moreover, you'll meet a lot of
rabble here like myself who have a glancing familiarity with the
difficulties of writing a parser but the people developing Inform and
TADS would be the ones who have spend years working on it and they will
also be in a unique position to describe what it's hard to do with a
deterministic parser.

> Another huge problem that experienced players don't think about much is


> "guess the syntax." We don't think about it because we *know* the

What are some examples?

> I'd like new players to be able to type in whatever they want, and learn


> the quick syntax as they go.

Great.. If you can do it... where "do it" means resolving arbitrary
commands into noun, verb, indirect object, and direct object bits.
Otherwise, the existing way that games are described/authored will not
work.

-Alan

Alan Mead

unread,
Dec 2, 2004, 3:29:13 PM12/2/04
to
On Wed, 01 Dec 2004 22:05:42 -0800, Neil Toronto wrote:

> I do machine learning research at BYU. I've been interested in IF for

Neal,

I'm a research psychologist and I've compared ML techniques to classical
statistical methods for predicting in applied psychology situations (e.g.,
predicting job choice from personality test scores). I don't have your
confidence that ML will have much accuracy in predicting from noisy data.
(I've been using latent semantic analysis to find similar bits of text
lately.. that's pretty cool beans...)

I mention this only to reassure you that I am at least glancingly familiar
with what ML can do.

I think that there is relatively little improvement that could be made to
the current parsers. They are far from perfect, but they obviously work
well enough for most cases. A lot of the cases where they don't work are
for odd but idiosyncratic phrasings that might be ambiguous without deep
contextual knowledge.

At any rate, any such work would only be helpful if it were embedded
transparently into an existing product such as Inform or TADS 3. Without
the remaining system, no one if likely to use such an engine to write
IF. So you should make your case to those authors. I suspect those
authors are also best able to tell you where they see weaknesses in
parsing.

There is a related problem that I think is much more of an issue for IF
authors and players: Eliminate guess-the-noun and guess-the-verb
problems. I played a game recently where I had to move an object. I had
tried tipping it but the game wasn't programmed to understand that tipping
and moving were similar verbs. I suspect more experienced IF players
already have a "thesaurus script" wherein they automatically try all the
common synonyms (and, in fact, they probably would have known to start
with verbs like 'move').

I don't know if solving this would be as sexy as the parsing problem you
mention. I think it would be more useful to IF. And I think it could be
applied during off-line, development so it doesn't need to be super fast.

Also, of the things you mention, I think realistic NPC's would have more
effect on the state of IF art than improved parsing. You might also take a
close look at one of the systems. I am learning TADS 3 (so I cannot speak
to Inform) which has a fairly complex set of classes which can be
instantiated and linked together to generate a facsimile of complex NPC
behavior. I'm not sure how ML could be used but any improvement in
animated NPC's would be a big improvement.

-Alan

ems...@mindspring.com

unread,
Dec 2, 2004, 6:09:47 PM12/2/04
to
Neil Toronto <neil.t...@gSPAMmail.com> wrote in message news:<conqgp$cdoe$1...@acs2.byu.edu>...

re: NPC augmentation


> Possibly. What I'm thinking of isn't so much a replacement for any
> existing NPC stuff, but a very small augmentation. It wouldn't dictate
> anything the NPC does, but allow the author to create fuzzy functions.
> Something like this, for example (definitely in pseudocode), goes in the
> guard code:
>
> if is_suspicious(time_of_day, saw_you_with_certain_item,
> hasnt_seen_you_doing_thus_and_such,
> heard_you_doing_something_suspicious, etc., etc.) then do your normal
> suspicious stuff...

Right. What I was getting at is that there is no standard model in
any IF language I know of for keeping track of things like "NPC X has
seen action Y occur". (Unless this is buried in TADS 3 and I just
haven't heard about it, which is possible.) So the author can mark
these things by setting a bunch of flags, but every author is likely
to come up with a different system and a different set of things he
wants the NPC to track.

On the other hand,...



> ...and the single "if" would replace the normal batch of nested "if"
> statements that determines whether the guard is suspicious of you. You
> might declare a fuzzy function like this:
>
> fuzzy is_suspicious(time_of_day, saw_you_with_certain_item,
> hasnt_seen_you_doing_thus_and_such,
> heard_you_doing_something_suspicious, etc., etc.): boolean

...this admittedly doesn't make very many assumptions at all about the
underlying world model, but allows the author to design his own flags.
So I suppose it might work.

At that point, you've got something that wouldn't have to be applied
solely to NPCs, though: it looks to me like it's basically a general
system for taking *any* set of information about the world model and
reaching a conclusion. I can't make up my mind whether this would be
really cool or completely useless, but I'd be curious to see what you
came up with.

For what it's worth, I disagree with Alan Mead about the utility of
parser improvements: comments I've read from newbie IF-players suggest
that guess-the-syntax is very much an issue.

-- Emily Short

Message has been deleted

Neil B Toronto

unread,
Dec 2, 2004, 4:14:24 PM12/2/04
to
Alan Mead wrote:
> On Wed, 01 Dec 2004 22:05:42 -0800, Neil Toronto wrote:
>
> I'm a research psychologist and I've compared ML techniques to classical
> statistical methods for predicting in applied psychology situations (e.g.,
> predicting job choice from personality test scores). I don't have your
> confidence that ML will have much accuracy in predicting from noisy data.
> (I've been using latent semantic analysis to find similar bits of text
> lately.. that's pretty cool beans...)
>

Excellent. I should have guessed there would people people like you and
Aleks in related fields that do IF as a hobby.

By the way, the data shouldn't be all that noisy. The IF author can be
regarded as an oracle that always supplies correct examples.

> I think that there is relatively little improvement that could be made to
> the current parsers. They are far from perfect, but they obviously work
> well enough for most cases. A lot of the cases where they don't work are
> for odd but idiosyncratic phrasings that might be ambiguous without deep
> contextual knowledge.

That's the fun part. (Hope nobody else minds if I launch into technical
stuff.) First, I should say that I've already coded up a simple world
model and run a bunch of tests on toy problems.

Probabilistic reasoning in ML uses Bayes' rule for estimating probabilities:

P(action|command) = P(command|action) * P(action) / P(command)

The algorithm constructs a probability mass function P(action|command),
so P(command) can be ignored - normalizing the distribution will take
care of it. P(action) is usually estimated as (# words in action's
examples) / (# words in all examples). P(command|action) is the hairy
part - involving word frequency and order, and mashing them together
with what seem like arbitrary mathematical operators - so I won't go
into it.

Usually, after P(action|command) is constructed, an ML algorithm would
return the action with the highest probability in P(action|command).
Mine goes a bit further: it constructs a P(action|command) for *every*
example command in the game, and compares the user's P(action|command)
with those. The most similar is the command most similar to the command
the user typed. (The similarity metric is hairier than the computation
of P(command|action), so I won't go into that, either.)

It's got a couple of nifty properties. First, that contextual knowledge
you refer to naturally falls out of the math. It's capable of finding
first-order correlations. So if you refer to hitting something with
something else as "whacking" and "smacking" in one place, and "smacking"
and "hitting" somewhere else, it'll let you "hit" in the first place and
"whack" in the second. I can also find more complex correlations
involving multiple words.

This partially solves the the "guess the noun" and "guess the verb"

problems problems you referred to later in your post.

Second, it's a solution to the notorious "none of the above / I don't

know" classification problem. It knows when to say "I really don't
understand you" - which ML algorithms usually can't do. This part may
end up in a thesis.

Third, the classification accuracy is 100% on the training data. That

means if a user types in what the IF author supplied as an example for
an action or object, the input will be classified as the action or
object. Generally, probabilistic algorithms won't do that.

Fourth, it works well on very, very small data sets.

Properties 2, 3, and 4 are requirements for IF. These were the unique
challenges I referred to in my original post.

> At any rate, any such work would only be helpful if it were embedded
> transparently into an existing product such as Inform or TADS 3. Without
> the remaining system, no one if likely to use such an engine to write
> IF. So you should make your case to those authors. I suspect those
> authors are also best able to tell you where they see weaknesses in
> parsing.
>

That's...three votes for working it into Inform or TADS. I think I
believe it now. :D

> [guess-the-noun and guess-the-verb]


>
> I don't know if solving this would be as sexy as the parsing problem you
> mention. I think it would be more useful to IF. And I think it could be
> applied during off-line, development so it doesn't need to be super fast.
>

Another huge problem that experienced players don't think about much is

"guess the syntax." We don't think about it because we *know* the

syntax. I'm willing to bet money that this ranks near the top on the
frustration list with "guess the noun" and "guess the verb" for
*beginning* users.

I'd like new players to be able to type in whatever they want, and learn
the quick syntax as they go.

> Also, of the things you mention, I think realistic NPC's would have more


> effect on the state of IF art than improved parsing. You might also take a
> close look at one of the systems. I am learning TADS 3 (so I cannot speak
> to Inform) which has a fairly complex set of classes which can be
> instantiated and linked together to generate a facsimile of complex NPC
> behavior. I'm not sure how ML could be used but any improvement in
> animated NPC's would be a big improvement.
>

I'll be looking into TADS 3 as well. Thanks for the tips!

Andrew Plotkin

unread,
Dec 3, 2004, 12:40:41 AM12/3/04
to
Here, Neil B Toronto <neil.t...@gspammail.com> wrote:
>
> Another huge problem that experienced players don't think about much is
> "guess the syntax." We don't think about it because we *know* the
> syntax. I'm willing to bet money that this ranks near the top on the
> frustration list with "guess the noun" and "guess the verb" for
> *beginning* users.
>
> I'd like new players to be able to type in whatever they want, and learn
> the quick syntax as they go.

There's a backwards effect which we don't think about much, but which
(IMHO) is important for IF being as playable as it is. It's true
that experienced players know the syntax -- but that's because the
syntax is *easy to learn*. Which is because it's simple. There's a
verb and a noun phrase, and possibly some prepositions (in a few
simple patterns). Once you see the pattern you can get into the swing
of it, and then you can *both* see the straightforward possibilities
and riff the unusual ones which the game wants you to think of.

I really think that if the parser was magically smarter, and could
accept more variants of commands, the player would (paradoxically)
find himself less able to control the game. He would be less able to
distinguish the significant differences in his commands from the
incidental ones -- the pattern would be more difficult to see.

This is not to say your idea is bad. Just that the goal of accepting
more possible player inputs is not, *of itself*, an improvement in IF.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
I'm still thinking about what to put in this space.

L. Ross Raszewski

unread,
Dec 3, 2004, 2:06:33 PM12/3/04
to
On Thu, 02 Dec 2004 22:10:07 -0600, Alan Mead <am...@comcast.net> wrote:
>It may be that hordes of would-be IF players stop playing because they
>cannot type "machine gun the troll to a bloody death" or "use the machine
>gun to slay the troll" but I don't think most players are that unable to
>adopt the straight-forward syntax that games prefer. Oh, I suppose there
>are occasional instances where things are not so happy but I don't think
>parsing the user's input is the hardest part.
>

If I read you right, I think I agree. The experience of others may
not jive, but it's been my experience that we're, in a way, trying too
hard. None of my novice, know-nothing playtesters tried typing *too
much*; no one was disappointed because they couldn't use adverbs, or
got confused because it didn't like "Please pick up that thing I found
interesting", or even because you had to say "turn switch on" instead
of "flip switch." They were typing things like "SWITCH" and "GUN"
(Indeed, perhaps approaching it from the same mindset you'd approach a
modern graphical adventure, where verbs aren't an issue, and the key
is to find the right object on which to click).

Now, in this respect, machine learning may be useful, since I think it
would tend toward interpreting unknown requests as "do the most useful
thing possible with this object," but I'm not sure that's the
direction we want to go.

I think the 'mistake' we've been making all this time is to try to make
the parser smarter. That's not going to work, because the problem
isn't that the parser is too stupid to interpret every possible way
the user could phrase the command. The answer is to make the *user*
smarter. And I don't simply mean "The parser gets it wrong because
the user doesn't know about the IF-command style of English." I mean
that the user gets it wrong because they don't really understand what
kinds of interactions exist in the model world." yes, I'm saying it's
not as much a parser issue as a world model issue. These players
aren't sitting there thinking "I want to flip the switch. How do I
tell the computer that?" They're thinking "That's a switch. Do that
thing that switches do." The problem is that they're not seeing an
object as a thing which can be taken, pushed, flipped, licked,
sniffed, waylayed, parried, and examined. They're seeing it as a
switch.

And that's where I think the breakdown happens. It's not that they
can't work out *how* to tell the computer specifically what to do with
the object. It's that they don't think in terms of what specifically
can be done to the object. I don't simply mean "They do not look
beyond the obvious," because that's (a) not right and (b) not a
problem. It might be more accurate to say that they don't expect the
*game* to look beyond the obvious. Hrm. Still a little off. Okay.
Say you've got a cup. What do you do with a cup? You drink from a
cup. Now, the IF author chimes in and says "You can also use it to
store things. you can use it as a shovel. If you've got a very small
head, you can invert it and use it as a helmet." Wrong. In a sort of
vague platonic way, if you do those things with it, it is *not a
cup*. If I can be forgiven for waxing heideggarian for a second, the
instant I start using the rock to bang nails into things, it ceases to
be a rock, and starts being a hammer. In the physical world, this is
no problem, because objects have a material existance outside their
names. I have no issue with the same lump of metal and plastic being
at one moment a stepladder and at the next an ottoman.
In the game world, however, the object has no existence outside the
words used to describe it. I can't use that cup as a shovel -- you
just told me it was a cup. Indeed, some cups I have met can *become*
shovels, but you just said this was a cup, not a shovel, so this cup
is, to me, in "cup-mode".

So on to what I think the answer is. And no, I don't think the answer
in general is to radically change the world model so that cups can
turn into shovels. I also don't think the answer is to make the
parser better at guessing. I think that how we identify that the user
is wrong may be more important than how we make the user's answer
right. And this is why I'm not sure machine learning is the right
answer. One of the biggest difficulties with a machine-learning based
system is that when the machine-learning gets something wrong, it's
often very hard to work out *why* it got it wrong. (Sit down with your
spam-checker some time and try to work out what it is about *this*
mismarked message that caused it to be mismarked. Or, better, have
someone who's barely computer-literate try to work it out.) If we
want to build better parsers, we should worry less about accepting a
wider ranger of inputs (I mean, we still should worry about it, but
we've already got it mostly licked) and more about providing better
error messages. I think the player will benefit more if we stop trying
to make anything he types be right and start trying to tell him in as
much detail as possible, why what he typed is *wrong*.

If possible, we should do this without this happening:

>MACHINE-GUN THE TROLL TO A BLOODY DEATH
Clippy says, "Hiya Skipper! You seem to want to do something to the
troll, but I don't know how to 'Machine-gun' something. But
'machine-gun' is a noun I know. Here's some things you can do with a
troll and a machine gun:
>GIVE MACHINE-GUN TO TROLL
>THROW MACHINE-GUN AT TROLL
>SHOOT MACHINE-GUN AT TROLL
>ASK TROLL ABOUT MACHINE-GUN"

But it is, in fact, surprisingly helpful.

Mr. J

unread,
Dec 3, 2004, 5:11:23 PM12/3/04
to
Regarding doing this in Inform:

I don't know how familiar you are with "pname.h", but it's a great
tool to help disambiguate word choice for objects with over lapping
names.

Forgive any errors, but the way it works is that Inform would normally
confuse an object named "Coffee Table" with a "coffee cup".

If you said "get coffee" it will ask "do you mean the coffee table or
the coffee cup?"

You can get into trouble if one object is only called "coffee" while
the other is "coffee table".

These are solvable other ways, but "pname.h" make it more use of
"defining" the labels rather than makeing a program find solutions to
weak definitions.

Same could be done for verbs and command choice.

I think way before you could define machine learning into the games,
you need to be able to define the words (verbs, adjectives, etc) much
better.

I like the way you can make many commands synonymouse, but I wonder if
there are some uncharted areas of making commands based more on
context.

Like words that mean different things in different context.

There isn't anything that can't be well defined such as making "turn
on" "switch on" etc. all turn on a light. (I still can't get that
lamp in Zork to "light" though!)

But maybe there can be a better flow of "what does the player mean"
based on context?

I'm really blanking on examples... how about..

"turn dial"
"turn camera on"
"ask benny about coffee"
"order coffee"

These all have easy solutions now, but I we veteran players are used
to "talking to the parser". Whenever I see someone new play, they use
phrases that I've "learned" will confuse a parser and thus avoid.


Any thoughts?

-John

kalli.f...@gmail.com

unread,
Dec 3, 2004, 5:36:12 PM12/3/04
to

ems...@mindspring.com

unread,
Dec 3, 2004, 5:57:30 PM12/3/04
to
lrasz...@loyola.edu (L. Ross Raszewski) wrote in message news:<ZO2sd.84$3T2.30@trnddc04>...

re: training the player to understand options in the world


> If possible, we should do this without this happening:
>
> >MACHINE-GUN THE TROLL TO A BLOODY DEATH
> Clippy says, "Hiya Skipper! You seem to want to do something to the
> troll, but I don't know how to 'Machine-gun' something. But
> 'machine-gun' is a noun I know. Here's some things you can do with a
> troll and a machine gun:
> >GIVE MACHINE-GUN TO TROLL
> >THROW MACHINE-GUN AT TROLL
> >SHOOT MACHINE-GUN AT TROLL
> >ASK TROLL ABOUT MACHINE-GUN"
>
> But it is, in fact, surprisingly helpful.

Point taken.

I don't see why this suggestion and Neil Toronto's need to be mutually
exclusive, though. It seems to me that a probabilistic parser might
be able to notice when it can't usefully guess between three or four
different options, and present the options to the player for further
clarification.

As for how to suggest options, I think one might want to pose them in
the same form as a disambiguation question; that way you avoid the
ugliness of a menu and remain consistent with the rest of the game.
So perhaps something like:

>MACHINE-GUN THE TROLL TO A BLOODY DEATH

Would you prefer to shoot the gun at the troll, hit the troll with the
gun, give the gun to the troll, or ask the troll about the gun?


I also feel obliged to mention this:

http://www.ainewsletter.com/newsletters/aix_0407.htm

Dennis Merritt comes at these issues from a somewhat different angle,
but is also concerned with teaching the player what world-model
aspects are accessible.

Mike Roberts

unread,
Dec 3, 2004, 7:38:02 PM12/3/04
to
"Andrew Plotkin" <erky...@eblong.com> wrote:
> I really think that if the parser was magically smarter, and
> could accept more variants of commands, the player would
> (paradoxically) find himself less able to control the game.

I think that's very much the case. I'd add a qualification, though: the
curve clearly has to invert at some point along the Intelligence axis
between current-IF and human, because we know empirically that it's easier
to get across a complex idea if you're talking to a human than if you're
talking to an IF parser. The question is where the curve turns. My feeling
is that it's quite a ways out, probably well past foreseeable developments
in parsing - so for all practical purposes, you're probably right that most
attempts to make parsers smarter at this point will yield diminishing (or
negative) returns.

--Mike
mjr underscore at hotmail dot com


Andrew Plotkin

unread,
Dec 4, 2004, 12:45:59 AM12/4/04
to
Here, Michael Roy <inv...@invalid.invalid> wrote:
> Andrew Plotkin wrote:
>
> > I really think that if the parser was magically smarter, and could
> > accept more variants of commands, the player would (paradoxically)
> > find himself less able to control the game. He would be less able to
> > distinguish the significant differences in his commands from the
> > incidental ones -- the pattern would be more difficult to see.
>
> Really? Why do you say that? The way I see it, the most basic test for
> a new (improved?) parser would be its ability to return the same output
> for the same input with the possible exception of disambiguation, etc.
> Thus, if the parser becomes magically smarter while the players remains
> the same, assuming we have experienced players, they should be able to
> achieve the same level of control as before by totally ignoring the fact
> that the parser is smarter.

I'm not talking about the experienced players; I'm talking about the
newcomers, who don't know how to interact with the game. (The
experienced player will never see the magically smarter parser, which
means it's wasted.)

The more the control scheme tries to second-guess the player, the less
information the player will have about the control scheme -- that's
true of *any* interface. The new player could wind up orbiting in the
"fringes" of the parser's understanding -- sometimes getting his
intent across, sometimes failing -- and never learn enough about the
underlying parser model to figure out the concise and reliable forms.
And (again) without those, you may be handicapped in discovering the
less orthodox, game-specific actions -- the actions[*] which it's a
puzzle to realize that they're *possible*.

[* I didn't say "verbs" or "commands".]

One possible way around this problem, which I think has already been
suggested, is to display the "canonical" form of any command which a
player types in an unusual way.

Mike Rozak

unread,
Dec 4, 2004, 2:30:48 AM12/4/04
to
Neil Toronto wrote:
> 5. Automatic disambiguation. If you're not very specific in what you
> type, it would pick the most likely thing. If you need to do the
> unlikely thing, you could be more specific.

I am working on a graphical IF system with a parser. It doesn't use machine
learning, although I've considered it. It does use probabilities though...

Basically, it uses a system similar to AIML, but my system is probability
based. AIML (you can find it on the web) is used for chatterbots, and is
basically a set of rules that converts strings around, like: Convert "pick
up *" to "get *". It allows for words, multi-word wildcards, and single-word
wildcards.

I added a probability number to the convertsion, so "pick up *" -> "get *"
is right 90% of the time, but 10% "pick up *" -> "go-get-and-give-a-ride-to
*". "color" -> "colour" and "meter" -> "metre" are 99% accurate. Etc. The
probabilities are entered by a human, and are only approximate.

Rules are automatically generated for nouns, so that "the red lantern" ->
"lantern005", "the green lantern" -> "lantern006". "the lantern" -> "lantern
005" and "lantern006". Plus, the pronouns are handled in the same way,
"it" -> "lantern005".

The probabilistic system produces a set of hypothesis along with a score.
These hypothesis are passed into a simple parser, like a standard adventure
game uses, which then multiplies its own score in based on the the
"meaningfulness" of the sentence. For example: "pick up Fred" -> "get Fred"
with a 90% score, and "go-get-and-give-a-ride-to Fred" with a 10% score.
However, since Fred is not commonly "gotten", the meaning parser would
provide a low probability, 5%, for that meaning, and a higher probability
(80%) for driving to Fred and taking him for a ride. Thus, the final score
for "pick up Fred" is 0.9 x 0.05 = 0.045 for "get fred", and 0.1 x 0.8 =
0.08 for "go-get-and-give-a-ride-to fred". In this contrived example, it
choses the correct answer. In reality, it's pretty good too, although I
haven't taxed it too much.

The extra layer of abstration also makes localization easy, since only the
first part is language dependent.

Adding machine learning to this would be very easy. However, I don't think
it's worth the work for commands since my system is also graphical, and
commands are less commonly used.

The system will ALSO handle chatting with NPCs. (Might as well kill two
birds with one stone.) I'm much more likely to use machine learning there,
but haven't gotten to the NPC part yet; that's coming in a few months. I
won't do the machine learning for awhile, but it's definitely possible.


--

Mike Rozak
http://www.mxac.com.au


Neil Toronto

unread,
Dec 4, 2004, 2:10:28 AM12/4/04
to

Actually, I haven't see that yet. (Still working my way through today's
batch of replies.) But I was *thinking* it. (Scary!)

You type, "machine-gun the troll to a bloody death" and the game echoes,
"You shoot the troll with the machine gun." Most games echo your actions
already.

I have two questions. First, how would freer form keep you from
realizing what's possible? My evidence against that idea is my children.
I'd assume it would help, actually - if the player goes into the game
assuming the game knows what he means when he types, wouldn't he be more
willing to experiment?

Neil

Neil Toronto

unread,
Dec 4, 2004, 3:21:09 AM12/4/04
to
Mike Rozak wrote:

> I added a probability number to the convertsion, so "pick up *" -> "get *"
> is right 90% of the time, but 10% "pick up *" -> "go-get-and-give-a-ride-to
> *". "color" -> "colour" and "meter" -> "metre" are 99% accurate. Etc. The
> probabilities are entered by a human, and are only approximate.
>

Fascinating!

Have you considered using a corpus of already-existing phrases to
approximate? The hard part is getting one...

I wonder how receptive most IF authors would be to tagging phrases with
probabilities?

> Rules are automatically generated for nouns, so that "the red lantern" ->
> "lantern005", "the green lantern" -> "lantern006". "the lantern" -> "lantern
> 005" and "lantern006". Plus, the pronouns are handled in the same way,
> "it" -> "lantern005".
>

This reminded me of an idea I had a while back. Wouldn't it be possible
to give higher scores to objects that the user has recently interacted
with? With your system, it wouldn't take too much of a "recently used"
nudge to push one hypothesis to the front.

Neil

Neil Toronto

unread,
Dec 4, 2004, 3:15:40 AM12/4/04
to
L. Ross Raszewski wrote:

> On Thu, 02 Dec 2004 22:10:07 -0600, Alan Mead <am...@comcast.net> wrote:
>
> I think the 'mistake' we've been making all this time is to try to make
> the parser smarter. That's not going to work, because the problem
> isn't that the parser is too stupid to interpret every possible way
> the user could phrase the command. The answer is to make the *user*
> smarter. And I don't simply mean "The parser gets it wrong because
> the user doesn't know about the IF-command style of English." I mean
> that the user gets it wrong because they don't really understand what
> kinds of interactions exist in the model world." yes, I'm saying it's
> not as much a parser issue as a world model issue. These players
> aren't sitting there thinking "I want to flip the switch. How do I
> tell the computer that?" They're thinking "That's a switch. Do that
> thing that switches do." The problem is that they're not seeing an
> object as a thing which can be taken, pushed, flipped, licked,
> sniffed, waylayed, parried, and examined. They're seeing it as a
> switch.
>

Maybe they do see it as an object that can be manipulated, but they're
used to clicking on it and letting the computer deal with doing the
action - whatever it is for that object. Have GUI interfaces
fundamentally changed our users to the point where being specific is too
hard?

Anyway, I think you're on to something. The only problem I have is that,
generally, good user interface design *never* assumes that the user
becomes smarter because of something you did to the interface. It also
never assumes the user will change.

Obviously, that's wrong. :) So is expecting that the *only* answer is
user education.

"Teach the user to use this program" has received a lot of attention
lately. ("Before you lay a click on it, please tour our neat-o
application!") Does anybody know whether it's actually worked?

> So on to what I think the answer is. And no, I don't think the answer
> in general is to radically change the world model so that cups can
> turn into shovels.

When I first read this, I thought, "Why not? Look at Half-life
2...things are going that way."

But just a few minutes later, I finished up a batch of eggnog. (Ever had
homemade eggnog? Mmmmm...) What kind of world model would allow you to
*cook*?

It's definitely a question of degree. Computers are finite machines, and
users are used to interacting with certain restrictions, and with
certain freedoms. What kind do they expect? If IF is to have a revival,
shouldn't you give it to them?

Is it still IF if you do?

> One of the biggest difficulties with a machine-learning based
> system is that when the machine-learning gets something wrong, it's
> often very hard to work out *why* it got it wrong.

Excellent point. Heck, just the "I don't know" classification is a hard
enough problem. There's definitely research going on in making an ML
algorithm's reasoning available and usable to humans, but I don't know
how far it's gotten.

However, much of how well you can introspect an ML algorithm depends on
how you slice the problem. If you break understanding a typed command
into multiple classifications (which I'm suggesting), it would be able
to, say, identify the direct object, but not the action, and query the
user about what to do.

Neil

Michael Roy

unread,
Dec 4, 2004, 3:29:29 AM12/4/04
to
Neil Toronto wrote:

> I have two questions. First, how would freer form keep you from
> realizing what's possible?

I'm not entirely decided on whether it does, but I'm debating this one
with myself, so I'm going to try and present a case for both sides. I'm
also going to make up notation as I go along. Sorry about that.
[ Executive summary: Giving the player the illusion of freedom prevents
him from being able to distinguish the details of his commands that he
can modify to change the overall effect of his command from those which
are incidental. In IFese, things are so compact that it's hopefully
clearer to the player what effect a change will have on the
interpretation of the command. This freedom may stop the player from
realizing what's possible to change. Additionally, when the player
finds a command that the parser does not understand, he will be less
able to rephrase it because he does not have a clear idea of the form
that the parser is expecting. The greater freedom of syntax would
hopefully but not necessarily make up for this lack of knowledge. ]

Suppose that despite the availability of a better parser, programmers
continue coding games in basically the same way that they always have.
In this case, no matter what the player types, the parser will have to
reduce it to some request for the game to either perform an action
(e.g., GO NORTH) or to return information (e.g., INVENTORY). Thus for
any meaningful command c, there is an arbitrary form I(c) which the
coder feels is the Ideal way for the players to express that request.
In this case, the job of the parser is to convert c => I(c). However,
the more the player's command differs from I(c), the more likely it is
that the parser will fail to convert it correctly.

Thus, whether or not they realize it, a player wishing to be understood
seeks to determine the behavior of the Ideal function through
experimentation. In effect, the player finds commands that don't work
in one circumstance and reasons that they probably won't work in any
others. Current parsers seem to basically require I(c) syntax with a
few extra filler words ("GET THE SWORD" => GET SWORD) so that I(c) is
typically contained within c. Thus, the parser will seem unforgiving to
new players, but once they get the hang of it they will know that they
are using a near-Ideal form.

Now, creating a more advanced parser does not get rid of the fact that
an ideal form exists but instead tries to increase the domain of
acceptable inputs. Thus, we now have commands c and d so that I(c) =
I(d) when neither c nor d is formally similar to I(c). Thus, the
hypothetical player giving random input in an attempt to figure out how
to make the interface understand him finds that both c and d work. In
this case, this is good, as making both c and d work was the whole
purpose of improving the parser. However, internally, the programmer is
working with the assumption that the parser will deliver I(c) and thus
nothing but I(c) is really possible. Because both c and d work, the
player will not be able to refine c or d into I(c) through experimenting
with small variations of syntax. I'm guessing that this is the core of
Andrew's argument.

The question, then, is whether it is necessary for the player to be able
to supply I(c). If the parser can convert c => I(c) with 100% accuracy,
it clearly isn't. If the parser can covert c => I(c) with some loss of
nuance ("I WANT TO WALK NORTH BRISKLY" => GO NORTH), it probably isn't
necessary for most circumstances. It does, however, become necessary if
there are c1 and c2 which are similar syntactically (though not in terms
of game action) so that the parser can convert c1 => I(c1) but not c2 =>
I(c2) or if there are c1 and c2 which should have identical game action
with I(c1) != I(c2).

I think you mentioned earlier having the parser learn to figure out what
the player means through probabilistic comparison to earlier commands,
in which case the parser, have understood c1, would hopefully be able to
draw on that in order to understand c2. However, let's assume that the
player picks a form for c1 that the parser can just barely understand.
The player, not knowing how close he came to getting a "Huh?", assumes
that this is the way that commands are supposed to be entered and tries
to phrase everything in a similar fashion. However, as it's really just
a convoluted expression that has to be reduced to I(c1), it presents him
with the appearance of being able to change things that he really can't
(if "I WANT TO WALK NORTH" worked in one place, a player might decide to
try "I REALLY NEED TO WALK NORTH" in response to "You can't go that
way.") and is thus less able to recognize what control he does have over
the command he is sending to the interface. Eventually, he tries
flipping it around somehow into a form the parser doesn't understand.
The problem then becomes that the player doesn't know how to fix his
command so that the parser will understand it. Hopefully, the smarter
parser would be forgiving enough to figure out a decent rephrasing, but
in the end the player is going to be smarter than the parser no matter
what you do and teaching him is probably easier than teaching it.

Though I would love to see a parser that could handle "TAKE THE ROAD
LESS TRAVELED BY."

> My evidence against that idea is my children.
> I'd assume it would help, actually - if the player goes into the game
> assuming the game knows what he means when he types, wouldn't he be more
> willing to experiment?

Yes, but that's not always a good thing.

> Neil

--
Michael

Mr. J

unread,
Dec 4, 2004, 12:06:41 PM12/4/04
to
Of course there is an inherent problem if the parser is TOO smart.

A RED DOOR IS YOUR ONLY WAY OUT
>KICK DOOR

DID YOU MEAN "UNLOCK DOOR WITH KEY"?
>YEA

YOU OPEN THE DOOR AND ENTER THE ROOM.
YOU SEE AN UGLY GREEN TROLL BEFORE YOU.
>F**K TROLL

DID YOU MEAN "TAKE THE 9MM GUN FROM THE CABINET, LOAD IT WITH BULLETS
FOUND IN THE SECRET DRAWER AND FIRE IT INTO THE TROLLS LEFT EYE?"
>UH.. SURE

**** YOU HAVE WON ****

L. Ross Raszewski

unread,
Dec 4, 2004, 3:00:11 PM12/4/04
to
On 3 Dec 2004 14:57:30 -0800, ems...@mindspring.com

<ems...@mindspring.com> wrote:
>
>I don't see why this suggestion and Neil Toronto's need to be mutually
>exclusive, though. It seems to me that a probabilistic parser might
>be able to notice when it can't usefully guess between three or four
>different options, and present the options to the player for further
>clarification.

Well now, I didn't think of it while I was writing it, but you have a
good point here. What I'm not sure about is whether it *could*
restrict itself to guessing when its guess was "good enough" -- my
instinct, based on what I learned in information retrieval, is that
this would be an even harder task than a machine-learning-parser.

I think that the place for machine learning here is not in doing the
everyday parsing, but in trying to work out candidates for what the
player actually meant when parsing has failed. Unfortunately, I think
we're now way out along the law of diminishing returns.

>
>As for how to suggest options, I think one might want to pose them in
>the same form as a disambiguation question; that way you avoid the
>ugliness of a menu and remain consistent with the rest of the game.
>So perhaps something like:
>
>>MACHINE-GUN THE TROLL TO A BLOODY DEATH
>Would you prefer to shoot the gun at the troll, hit the troll with the
>gun, give the gun to the troll, or ask the troll about the gun?
>
>

I agree that a menu is not a good way to go (And if Clippy looked like
a menu, I (a) didn't mean it and (b) was intentionally giving an
annoying and ugly example anyway). I'm not even sure that the
disambiguation-question is all that good either, insofar as I think
it's still oriented more toward "ask the player to help the parser
overcome its weakness" than "tell the player something that helps him
become a better player. I also would prefer displaying the
suggestions (And that's the thing, really: I want to convey these as
suggestions, not choices) in >STANDARD IF COMMAND CONVENTION to make
it clearer that we're telling the player what he needs to *type*,
because I could easily see a player reading that prompt, and typing
>SHOOT, because he thinks he just has to identify which of *these four
choices* he wants.

Though this is almost entirely a stylistic concern.

L. Ross Raszewski

unread,
Dec 4, 2004, 3:11:47 PM12/4/04
to
On Sat, 04 Dec 2004 01:15:40 -0700, Neil Toronto
<neil.t...@gSPAMmail.com> wrote:

>Maybe they do see it as an object that can be manipulated, but they're
>used to clicking on it and letting the computer deal with doing the
>action - whatever it is for that object. Have GUI interfaces
>fundamentally changed our users to the point where being specific is too
>hard?

Honestly, I barely remember the golden age of IF. But I do have some
vague notion that even back in the 80s, my mother (Who is the
archetype of the User Who Doesn't Get It) had trouble understanding
the, let's say, verb-oriented nature of the command parser.

And I think that's more the thing: it's not that users don't want
to/can't be specific. It's that they aren't accustomed to thinking in
terms of the *verbs* so much as thinking in terms of the *objects*.

The Legend games, which I for one found very easy to use, tended to
encourage an input style where you'd pick an object first, and then
decide what verb you wanted to use with it. I don't think that
switching to a Legend-menu-driven interface would be right for all IF (some
of it, certainly, though), but maybe we can find some way to reorient
the user with a minimum of pain.

Like, maybe this: in a normal IF game, if I just type the name of an
object at the prompt, I'm told that there was no verb in that
sentence. How about, instead, I'm told (some of) the verbs that apply
to the object?

>
>"Teach the user to use this program" has received a lot of attention
>lately. ("Before you lay a click on it, please tour our neat-o
>application!") Does anybody know whether it's actually worked?

I think it anoys the savvy users, but it makes the novice ones, if not
better at using the program, feel shame before they complain about the
difficulty of using it.

>
>However, much of how well you can introspect an ML algorithm depends on
>how you slice the problem. If you break understanding a typed command
>into multiple classifications (which I'm suggesting), it would be able
>to, say, identify the direct object, but not the action, and query the
>user about what to do.

Probably, yes. And at this point, I think it's less a matter of me
thinking that machine learning is unhelpful, as it is of me thinking
that machine learning is an awful lot of work if that's all it's going
to accomplish. (After all, just checking all the words against the
object model is already going to give you a pretty accurate sense of
what the nouns are).

Mike Rozak

unread,
Dec 4, 2004, 5:11:27 PM12/4/04
to
> Have you considered using a corpus of already-existing phrases to
> approximate? The hard part is getting one...

Actually, getting a corpus is very easy... or will be. My system is designed
to run as a stand-alone single-player experience, or as a multi-player
experience over the internet. It will be able to store a log of everything
and anything. With up to 1000 players logged on at once, you'll quickly have
more corpus than you'd want.

I think that tads and inform will keep a command log, although I don't know
if they remember what room the player was in along with the objects present.
This extra information is needed to analyze your context.


> I wonder how receptive most IF authors would be to tagging phrases with
> probabilities?

The probabilities only need to be approximately right. I suspect that many
IF authors will use them as scores... if "pick up X" is not understood with
the right sense, they'll merely increase or decrease one of the scores until
it does work.


> This reminded me of an idea I had a while back. Wouldn't it be possible to
> give higher scores to objects that the user has recently interacted with?
> With your system, it wouldn't take too much of a "recently used" nudge to
> push one hypothesis to the front.

Sure, this would be easy enough to do. I don't think you'll get much gain in
it though, maybe a few percent more accurate.


About 6-12 months ago I posted on rec.arts.int-fiction about some of the
probabilities ideas. The way you need to approach the problem is:

1) Collect a corpus of commands that players type in.
2) Hand "parse" the corpus into the "right" answer.
3) Take half the corpus and use it for training, the other half for accuracy
tests.
4) Come up with as many random rules as you can. If adding a rule makes your
system more accurate, keep it. Otherwise, forget about the rule. You do
accuracy tests using the 1/2 of your data that your rules weren't based on.
5) If your rules depend upon learning from a corpus then use the training
data.

This is how speech recognition research works, and you're talking about
essentially the same problem, although with different input data.

Very few (if any) authors will go through this much work.

In some ways, you may be better off using a word-net derived from dictionary
definitions, as well as a grammar parser. (NOTE: This is LOTS of work.) This
would make your machine learning require less author input (which is good),
and significantly increase its accuracy.

You might also want to view command parsing as a subset of a NPC
conversation system, because it is.

Michael Roy

unread,
Dec 5, 2004, 2:31:58 AM12/5/04
to
L. Ross Raszewski wrote:

> And I think that's more the thing: it's not that users don't want
> to/can't be specific. It's that they aren't accustomed to thinking in
> terms of the *verbs* so much as thinking in terms of the *objects*.
>
> The Legend games, which I for one found very easy to use, tended to
> encourage an input style where you'd pick an object first, and then
> decide what verb you wanted to use with it. I don't think that
> switching to a Legend-menu-driven interface would be right for all IF (some
> of it, certainly, though), but maybe we can find some way to reorient
> the user with a minimum of pain.

Frobnitz (for Palm) has this for a user defined verb list. It's done
there so the user can just click on a noun instead of trying to write
something in for the common actions, but as far as the interface goes,
I've never found to be less appropriate than entering commands in
verb-noun form.

--
Michael

Neil Toronto

unread,
Dec 5, 2004, 3:43:03 AM12/5/04
to
Michael Roy wrote:

> L. Ross Raszewski wrote:
>
>> The Legend games, which I for one found very easy to use, tended to
>> encourage an input style where you'd pick an object first, and then
>> decide what verb you wanted to use with it. I don't think that
>> switching to a Legend-menu-driven interface would be right for all IF
>> (some
>> of it, certainly, though), but maybe we can find some way to reorient
>> the user with a minimum of pain.
>
>
> Frobnitz (for Palm) has this for a user defined verb list. It's done
> there so the user can just click on a noun instead of trying to write
> something in for the common actions, but as far as the interface goes,
> I've never found to be less appropriate than entering commands in
> verb-noun form.
>

Funny. I was thinking of this kind of interface just today while mulling
over the GUI-ization of computing, and after playing a bit with TADS 3.
I did a search in raif for "mouse" and turned up quite a few interesting
discussions.

It seems the best way would be to hyperlink all the objects that can be
involved in action (indirect and direct objects), and drop a context
menu down with common verbs that apply when they're clicked on. Put a
"More..." at the bottom so they can choose from a huge list, and if one
they find works, ask them if they want it added permanently. If you need
to work with an indirect object, most of the time you'd put the verb in
the indirect object's menu. The player would click it, choose the verb,
and then click the direct object.

Pros:

1) Nifty, nifty for palm users, assuming you can squeeze in a tabbed
window for the room/inventory at the top and have room for messages at
the bottom. Graffiti + IF = a pain for people who don't graffiti well.
(I'm raising my hand.)

2) No more guess-the-verb or guess-the-syntax. The player always knows
exactly what he's doing.

3) Most existing games could be retrofitted in a matter of hours. The
tricky parts would be where an author relied on an obscure action being
performed on an object that the player had to learn about during the
course of the game. The story would likely have to change.

4) The game would generally play faster, especially if a left-click
always meant "look at."

Cons:

1) Difficult, if not impossible, to rely on this plot device: making a
win depend on performing an obscure action that the player has to learn
about. The "More..." option on the context menu could help, but not much
if the action is really wild.

2) Similarly, relying on an obscure object hidden in the open would be a
bit more difficult. Not much, though. You can look at most things, and
the verb would be in the indirect object's menu, not the obscure
object's menu.

3) I imagine that a bunch of die-hards would assert that it "isn't
interactive fiction." I saw that in a 1994 thread...I wonder if the
reaction would be the same nowadays. Jihad out the wazoo, Emacs vs. vim
style.

4) There may be a screen real-estate problem on palm devices. Making it
playable would require that some text (room, inventory) does not scroll.

5) Talking to NPCs would have to revert to a command line if the author
wants to avoid totally scripted conversations. This may not be a bad thing.

6) Games of this type might *appear* to be less open-ended than
analagous command-line games, even when they're not. I'm not sure that's
such a bad thing either.

I suppose that text + hyperlinks doesn't get much attention, because
when you add a mouse, people expect graphics. Or the designers *think*
people would demand graphics. I'd love to play a text-based mousing IF
game, personally.

*adds it to his list of things to do in his infinite spare time*

Andrew Plotkin

unread,
Dec 5, 2004, 12:51:35 PM12/5/04
to
Here, Neil Toronto <neil.t...@gspammail.com> wrote:
>
> It seems the best way would be to hyperlink all the objects that can be
> involved in action (indirect and direct objects), and drop a context
> menu down with common verbs that apply when they're clicked on. Put a
> "More..." at the bottom so they can choose from a huge list, and if one
> they find works, ask them if they want it added permanently. If you need
> to work with an indirect object, most of the time you'd put the verb in
> the indirect object's menu. The player would click it, choose the verb,
> and then click the direct object.
> [...]


> 3) I imagine that a bunch of die-hards would assert that it "isn't
> interactive fiction." I saw that in a 1994 thread...I wonder if the
> reaction would be the same nowadays. Jihad out the wazoo, Emacs vs. vim
> style.

Let me try to respond non-jihadically:

I think you're creating a system in which it's more important to look
at the list of underlined words, and then look at their pull-down
menus, than it is to read the game text. Players are not stupid, and
will read the menus first.

It may be possible to create a game that works effectively this way. I
am sure that it's an unexplored field: what we know about creating
effective interaction in a parser game will *not* apply. All the
technique that I put into my games revolves around the interaction
model of the IF parser. That's how I get the player's attention, evoke
his reactions, and make him feel complicit. If you take the text
parser out of one of my games, you are taking out the interactivity.
Now it may be possible to put that back, but then you're redesigning
the game from the ground up -- as much so as if you were translating
the game into a screenplay or novel.

Michael Roy

unread,
Dec 5, 2004, 8:17:26 PM12/5/04
to

Hyperlinks would also be a nice way of immediately indicating to the
player whether an object in the description had been implemented
(although of course they all should be). In terms of indirect objects,
I think that choosing verb and direct object and then choosing the
indirect object after would probably be cleaner. For one thing, I
wouldn't expect to find "UNLOCK DOOR" sorted under KEY.

> Pros:
>
> 1) Nifty, nifty for palm users, assuming you can squeeze in a tabbed
> window for the room/inventory at the top and have room for messages at
> the bottom. Graffiti + IF = a pain for people who don't graffiti well.
> (I'm raising my hand.)

On the other hand, IF is the best way to learn Graffiti that I know.

> 2) No more guess-the-verb or guess-the-syntax. The player always knows
> exactly what he's doing.

Bringing about the advent of guess-the-context-menu. Probabilistic
interpreters aside, we're always going to have to guess something.

> 3) Most existing games could be retrofitted in a matter of hours. The
> tricky parts would be where an author relied on an obscure action being
> performed on an object that the player had to learn about during the
> course of the game. The story would likely have to change.

It'd be interesting to see if the conversion could be built into the
compiler. Most objects in Inform at least could have fairly good
context menu's built by whether they have the "edible" attribute or so
on. The hyperlinking to works in the text (which isn't possible in
Z-Code anyway, so ignore the last sentence) could probably be done
automatically with the exception of the few cases when a room would
contain two similarly named objects. And it'd have to have a few extra
rules, like not hyperlinking things like "north."

> 4) The game would generally play faster, especially if a left-click
> always meant "look at."
>
> Cons:
>
> 1) Difficult, if not impossible, to rely on this plot device: making a
> win depend on performing an obscure action that the player has to learn
> about. The "More..." option on the context menu could help, but not much
> if the action is really wild.

Is depending on the player to do something obscure really a plot device?

> 2) Similarly, relying on an obscure object hidden in the open would be a
> bit more difficult. Not much, though. You can look at most things, and
> the verb would be in the indirect object's menu, not the obscure
> object's menu.

Not sure what you mean here. Can you give an example of an obscure
object hidden in the open for which the player would reference it
through an indirect object?

> 3) I imagine that a bunch of die-hards would assert that it "isn't
> interactive fiction." I saw that in a 1994 thread...I wonder if the
> reaction would be the same nowadays. Jihad out the wazoo, Emacs vs. vim
> style.
>
> 4) There may be a screen real-estate problem on palm devices. Making it
> playable would require that some text (room, inventory) does not scroll.

That would mean that the whole screen doesn't scroll, on my Palm.

> 5) Talking to NPCs would have to revert to a command line if the author
> wants to avoid totally scripted conversations. This may not be a bad thing.
>
> 6) Games of this type might *appear* to be less open-ended than
> analagous command-line games, even when they're not. I'm not sure that's
> such a bad thing either.
>
> I suppose that text + hyperlinks doesn't get much attention, because
> when you add a mouse, people expect graphics. Or the designers *think*
> people would demand graphics. I'd love to play a text-based mousing IF
> game, personally.
>
> *adds it to his list of things to do in his infinite spare time*

--
Michael

Neil Toronto

unread,
Dec 6, 2004, 1:25:47 AM12/6/04
to
Michael Roy wrote:
> Hyperlinks would also be a nice way of immediately indicating to the
> player whether an object in the description had been implemented
> (although of course they all should be). In terms of indirect objects,
> I think that choosing verb and direct object and then choosing the
> indirect object after would probably be cleaner. For one thing, I
> wouldn't expect to find "UNLOCK DOOR" sorted under KEY.

It totally depends on the object and action. I wouldn't expect to find
"SHOOT TROLL" under TROLL, but under MACHINE GUN. I'd say you'd put
actions you would normally expect to do to an object (or with an object)
on the object itself, like UNLOCK on LOOR. It's totally fuzzy, though.

>> 1) Difficult, if not impossible, to rely on this plot device: making a
>> win depend on performing an obscure action that the player has to
>> learn about. The "More..." option on the context menu could help, but
>> not much if the action is really wild.
>
> Is depending on the player to do something obscure really a plot device?

I tried to stay neutral when listing the pros and cons. I agree with
you. I don't find it especially fun in general.

** Spider and Web Spoilers (as if there's anybody here who hasn't played
it - and if you haven't, please do) **

However...I was just playing Spider and Web a couple of days ago.
There's a part early on where you have to jump up and grab onto a lip
that used to hold a ceiling tile. You have to figure out that's what
you're supposed to do after failing another interview with what'. It
seems too much part of the game to be really annoying.

You couldn't do it *exactly* like that with context menus. You could add
it after failing the interview, I suppose. Or have the player jump and
hold the lip after selecting "Me->Jump."

** End Spoilers **

>> 2) Similarly, relying on an obscure object hidden in the open would be
>> a bit more difficult. Not much, though. You can look at most things,
>> and the verb would be in the indirect object's menu, not the obscure
>> object's menu.
>
> Not sure what you mean here. Can you give an example of an obscure
> object hidden in the open for which the player would reference it
> through an indirect object?

Sure. You're in a weird temple thingy, and the wall in front of you is
covered in sandstone idols. You can turn the head of the smallest one to
open a secret passage.

Huh. That's a guess-the-verb one. Maybe I can't give an example. :)
Strike #2.

>> 4) There may be a screen real-estate problem on palm devices. Making
>> it playable would require that some text (room, inventory) does not
>> scroll.
>
> That would mean that the whole screen doesn't scroll, on my Palm.

Crap. I'm not sure how you'd do it nicely if you can't keep one section
of the screen static.

Neil

Michael Roy

unread,
Dec 6, 2004, 2:15:07 AM12/6/04
to
Neil Toronto wrote:
> Michael Roy wrote:
>
>> Hyperlinks would also be a nice way of immediately indicating to the
>> player whether an object in the description had been implemented
>> (although of course they all should be). In terms of indirect objects,
>> I think that choosing verb and direct object and then choosing the
>> indirect object after would probably be cleaner. For one thing, I
>> wouldn't expect to find "UNLOCK DOOR" sorted under KEY.
>
> It totally depends on the object and action. I wouldn't expect to find
> "SHOOT TROLL" under TROLL, but under MACHINE GUN. I'd say you'd put
> actions you would normally expect to do to an object (or with an object)
> on the object itself, like UNLOCK on LOOR. It's totally fuzzy, though.

I might look under SHOOT TROLL, but I see your point. However, if we're
hypothetically abandoning the command line, there's no reason not to
rephrase special commands like these so that they follow the direct
object consistently. That is, SHOOT MACHINE GUN AT TROLL.

>>> 4) There may be a screen real-estate problem on palm devices. Making
>>> it playable would require that some text (room, inventory) does not
>>> scroll.
>>
>>
>> That would mean that the whole screen doesn't scroll, on my Palm.
>
>
> Crap. I'm not sure how you'd do it nicely if you can't keep one section
> of the screen static.

How about having three tabbed windows, one for standard output and two
devoted to the inventory and room description?

--
Michael

M.D. Dollahite

unread,
Dec 6, 2004, 5:09:24 AM12/6/04
to
>>> I think that choosing verb and direct object and then choosing the
>>> indirect object after would probably be cleaner. For one thing, I
>>> wouldn't expect to find "UNLOCK DOOR" sorted under KEY.
>>
>> It totally depends on the object and action. I wouldn't expect to find
>> "SHOOT TROLL" under TROLL, but under MACHINE GUN. I'd say you'd put
>> actions you would normally expect to do to an object (or with an object)
>> on the object itself, like UNLOCK on LOOR. It's totally fuzzy, though.
>
>I might look under SHOOT TROLL, but I see your point. However, if we're
>hypothetically abandoning the command line, there's no reason not to
>rephrase special commands like these so that they follow the direct
>object consistently. That is, SHOOT MACHINE GUN AT TROLL.

Why not put two-object actions in the menus for *both* objects? If you try to
guess where the player will look for it, you'll be wrong about 50% of the time,
because about 50% of players will think the opposite of whatever you think.

Gene Wirchenko

unread,
Dec 6, 2004, 6:37:35 PM12/6/04
to
Michael Roy <inv...@invalid.invalid> wrote:

>Andrew Plotkin wrote:
>
>> I really think that if the parser was magically smarter, and could
>> accept more variants of commands, the player would (paradoxically)
>> find himself less able to control the game. He would be less able to
>> distinguish the significant differences in his commands from the
>> incidental ones -- the pattern would be more difficult to see.
>

>Really? Why do you say that? The way I see it, the most basic test for
>a new (improved?) parser would be its ability to return the same output
>for the same input with the possible exception of disambiguation, etc.
>Thus, if the parser becomes magically smarter while the players remains
>the same, assuming we have experienced players, they should be able to
>achieve the same level of control as before by totally ignoring the fact

>that the parser is smarter. Beyond that, I think that a more flexible

Well, maybe not.

One of the biggest frustrations I have with Microsoft Word and
Excel is that they try to help me. I have lost hours because of this
in Word. I do not use Excel as much, so I have lost less time to its
"help".

I was quite happily using an Excel spreadsheet to prepare a
schedule for my Toastmasters club. All was working just fine until we
had two members where ones first name started with the same letters as
another member's first name.

As soon as that happened, I had to check when I typed one of the
names. Suddenly, my typing was now probabilistic. If I type "Lee", I
do not want to see "Lee-Ann", and vice versa. This was particularly a
pain, because in Toastmasters, we try to get as many members involved
in each meeting as we can. If someone already has a role, there
should be LESS chance that he will have another role.

Maybe an analog of this situation will not happen, but do not be
too sure of that. One of my general frustrations with Windows is that
it makes some things easy to do at the expense of more difficult
things. This makes it easy-to-learn and hard-to-use.

[snip]

Sincerely,

Gene Wirchenko

Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.

Richard Bos

unread,
Dec 6, 2004, 7:17:25 PM12/6/04
to
Gene Wirchenko <ge...@mail.ocis.net> wrote:

> Michael Roy <inv...@invalid.invalid> wrote:
>
> >Thus, if the parser becomes magically smarter while the players remains
> >the same, assuming we have experienced players, they should be able to
> >achieve the same level of control as before by totally ignoring the fact
> >that the parser is smarter. Beyond that, I think that a more flexible
>
> Well, maybe not.
>
> One of the biggest frustrations I have with Microsoft Word and
> Excel is that they try to help me. I have lost hours because of this
> in Word. I do not use Excel as much, so I have lost less time to its
> "help".
>
> I was quite happily using an Excel spreadsheet to prepare a
> schedule for my Toastmasters club. All was working just fine until we
> had two members where ones first name started with the same letters as
> another member's first name.

And then there's the "helpful" feature where Excel decides that if it
looks like an e-mail address, not only _is_ it an e-mail address
(completely ignoring the fact that the @-sign predates the computer,
never mind the 'net), but it _must_ behave like one, being clickable and
all. Yes, _must_. It will automatically turn all e-mail addresses into
hyperlinks. There is no way to turn this off. Amazingly, this "feature"
can be turned off in M$Word, but not in Excel. And if you have a whole
column of e-mail addresses, you cannot select the whole column and
remove all hyperlinks - oh, no, that would not be nearly "helpful"
enough! No, you must select each hyperlink - separately - right-click
it, choose the sub-context-menu "hyperlink", and then choose "turn
hyperlink off". Every. Single. Fucking. Time.

Sometimes, I really, honestly, deep down want to strangle someone. The
painful way. Where the victim doesn't go unconscious because of a lack
of blood to the brain, but is very much aware of the agony for as long
as it takes me to crush his adam's apple to pulp. And whoever put that
bloody pain in the goddamned neck hyperlink feature in Excel is _very_
high on the list.

No, I'm not kidding - not really. No, I don't think I need medication.
This is a _rational_ hatred.

Richard

Michael Roy

unread,
Dec 6, 2004, 8:00:11 PM12/6/04
to

That would, of course, be the obvious solution. The only con that I can
think of is it might potentially make both action menus twice as long as
they would otherwise be and fill them with a few bizarre things that no
player would ever think of. As one concrete example, you'd have to have
"ASK ___ ABOUT" for every item in sight, instead of just placing it
under the NPC.

--
Michael

Michael Roy

unread,
Dec 6, 2004, 8:18:00 PM12/6/04
to
Gene Wirchenko wrote:

> Michael Roy <inv...@invalid.invalid> wrote:
>
>>Andrew Plotkin wrote:
>>
>>
>>>I really think that if the parser was magically smarter, and could
>>>accept more variants of commands, the player would (paradoxically)
>>>find himself less able to control the game. He would be less able to
>>>distinguish the significant differences in his commands from the
>>>incidental ones -- the pattern would be more difficult to see.
>>
>>Really? Why do you say that? The way I see it, the most basic test for
>>a new (improved?) parser would be its ability to return the same output
>>for the same input with the possible exception of disambiguation, etc.
>>Thus, if the parser becomes magically smarter while the players remains
>>the same, assuming we have experienced players, they should be able to
>>achieve the same level of control as before by totally ignoring the fact
>>that the parser is smarter. Beyond that, I think that a more flexible
>
>
> Well, maybe not.
>
> One of the biggest frustrations I have with Microsoft Word and
> Excel is that they try to help me. I have lost hours because of this
> in Word. I do not use Excel as much, so I have lost less time to its
> "help".

I used to feel that way until I realized that Word was not actually
trying to help me. Now I just feel glad when I outsmart its sadistic
tendencies and trick it into actually doing what I want and resign
myself to fate the rest of the time.

Now, I wonder how this would carry over to IF. Even with the current
parser, a player can type absolutely clear commands and still have the
possibility of the parser making frustrating inferences:
> SIT
(on the electric chair)

However, if the goal of the smarter parser is to funnel more commands
into the same verb-noun-second framework, I still wouldn't think that an
experienced player already using this syntax would enter any commands
that the parser thought worth "correcting."

--
Michael

Poster

unread,
Dec 7, 2004, 7:58:05 PM12/7/04
to
Alan Mead wrote:

> On Wed, 01 Dec 2004 22:05:42 -0800, Neil Toronto wrote:
>
>
>>I do machine learning research at BYU. I've been interested in IF for
>
>
> Neal,
>
> I'm a research psychologist and I've compared ML techniques to classical
> statistical methods for predicting in applied psychology situations (e.g.,
> predicting job choice from personality test scores). I don't have your
> confidence that ML will have much accuracy in predicting from noisy data.
> (I've been using latent semantic analysis to find similar bits of text
> lately.. that's pretty cool beans...)
>
> I mention this only to reassure you that I am at least glancingly familiar
> with what ML can do.
>
> I think that there is relatively little improvement that could be made to
> the current parsers. They are far from perfect, but they obviously work
> well enough for most cases. A lot of the cases where they don't work are
> for odd but idiosyncratic phrasings that might be ambiguous without deep
> contextual knowledge.
>
> At any rate, any such work would only be helpful if it were embedded
> transparently into an existing product such as Inform or TADS 3. Without
> the remaining system, no one if likely to use such an engine to write
> IF. So you should make your case to those authors. I suspect those
> authors are also best able to tell you where they see weaknesses in
> parsing.
>
> There is a related problem that I think is much more of an issue for IF
> authors and players: Eliminate guess-the-noun and guess-the-verb
> problems. I played a game recently where I had to move an object. I had
> tried tipping it but the game wasn't programmed to understand that tipping
> and moving were similar verbs. I suspect more experienced IF players
> already have a "thesaurus script" wherein they automatically try all the
> common synonyms (and, in fact, they probably would have known to start
> with verbs like 'move').
>
> I don't know if solving this would be as sexy as the parsing problem you
> mention. I think it would be more useful to IF. And I think it could be
> applied during off-line, development so it doesn't need to be super fast.

Hear, hear. I think the fuzzy algorithms you suggested for allowing
life-like NPC interactions would be great.

Now that would be doable, in the sense of relatively quick, relatively
painless, and generating something that is an immediate improvement upon
the existing laborious manual coding of NPCS.

I've thought about this a bit, myself. Couple fuzzy logic with an
ability to remember and preserve knowledge (statefulness and state
awareness) and a truly random number generation (to make game life
unpredictable) and you've got one heck of an NPC system.

Me? I'm an ex comp-sci major cum-humanities major with a hearty interest
in AI.

~Poster

"I seek the social ownership of property, the abolition of the
propertied class, and the sole control of those who produce wealth.
Communism is the goal." -- Roger Baldwin, founder of the ACLU.

Poster

unread,
Dec 7, 2004, 8:05:52 PM12/7/04
to

As for "guess the verb" you should be able to fix this by allowing the
parser to be self-modifying and correctable by the user. Take the
following bit of INFORM game play:

> Strike the troll.

I don't know the word "strike".

> Synonym "hit".

Understood. ["Strike" is synonym of "hit."]

Even the best parser can fail, and what can you, the player do about it?
Usually nothing. The parser should be modifiable during game play --
that is -- it is corrected by a wiser spirit, the game-player
him/herself. Ideally you could do this by building a library of synonyms
which could be generated during beta-testing and then just compiled with
the final release -- so that the game would "know" all the words
already. This kind of customization would allow you release say British
and Australian versions of the same game...

~Poster

Alan Mead wrote:
> On Thu, 02 Dec 2004 14:14:24 -0700, Neil B Toronto wrote:
>
>
>>Probabilistic reasoning in ML uses Bayes' rule for estimating
>>probabilities:
>>
>>P(action|command) = P(command|action) * P(action) / P(command)
>
>
> So, I hope there's no quiz but I think I understand your methodology, at
> least in abstract... what's your purpose? What is 'action' and 'command'
> here? Is this the business of NPC states or parsing user input? Or
> finding synonyms?
>
> I think it's the last and you're saying, "Ok, The "command" is what the
> user types and "action" is the action that the user means in the
> vocabulary of the IF author. And I'll make a system that finds what words
> people use to describe any action. Then I'll assume that the action with
> the greatest probability conditional on the command is the intended
> action."
>
> Is that right?
>
> That's cool for the commands in the training set, but then that's already
> isomorphic with the current state of the art. If everyone uses the
> commands that we authors intend, then there's no problem. I don't see how
> this will help (but be sure and disagree with a concrete example if I
> don't get it...) I especially don't get how this will automagically
> understand the context.
>
> At the risk of telling you what you already know and simplifying terribly,
> the way TADS works (I can only speak to TADS) is: the IF author defines
> nouns and, sometimes, verbs. She then makes associations between the
> nouns and the verbs (open the box). Sometimes the nouns have direct
> object or indirect object relations with the verbs (kill the troll with
> the machine gun).
>
> That's pretty much it... the game displays the nouns' descriptions, the
> parser translates user input into verbs (e.g., look) with direct (open
> box) or indirect (unlock the box with the gold key) objects and displays
> the results. Any engine you write, has to help this simple system work
> better.
>
> It may be that hordes of would-be IF players stop playing because they
> cannot type "machine gun the troll to a bloody death" or "use the machine
> gun to slay the troll" but I don't think most players are that unable to
> adopt the straight-forward syntax that games prefer. Oh, I suppose there
> are occasional instances where things are not so happy but I don't think
> parsing the user's input is the hardest part.
>
> The hardest part isn't defining the verbs, either. It's pretty easy to
> make 'slay' a synonym for 'kill'. The hard part is anticipating all the
> synonyms that a player will use. I read an author's website where he
> mentioned that playtesters all failed to "flip" a power switch, they
> instead smacked it, hit it ('hit the power'), etc. I had trouble in a
> game that didn't recognize "tip" as a synonym for "move". In fact, I
> think the game told me that the object was too heavy to tip ... then it
> allowed me to move it. :)
>
> The remedy is pretty simple though... it doesn't require a new parser, it
> just requires that verb synonyms be defined. In other words, it requires
> a process whereby all the author is encouraged to add synonyms... kinda of
> like spell checking a document prompts you for misspellings..
>
> There are some other hardest parts... people describe nouns and then
> forget to define nouns referenced in the description ("You are in a small
> armory. Weapons line the walls." >x weapons "I don't see any weapons
> here." --or-- "You are in a spartan bedroom with only a bed." >x bed "It's
> a spartan bed with only a thin blanket and pillow" >x blanket "I don't see
> a blanket here.")
>
> There is the hardest part that you *do not* associate most verbs with most
> nouns. So a room back from the troll you couldn't machine-gun the hill
> giant... you had to give him the daisy and sneak past while he was in a
> fit of sneezing.
>
> There is also the really hard hardest part of making the noun-verb
> relationships clear. For example, I recently wrote a small TADS 3 game
> with a bedroom, a desk and a book. I can "read book" but when I "open
> book" I get an error about the book not being openable. I can fix that
> but basically it comes down to IF being a very thin charade and opening
> books just isn't a level of detail that IF authors usually bother
> with. Mike Roberts (the Linus Torvalds of TADS) has written some
> interesting articles about this.
>
>
>>It's got a couple of nifty properties. First, that contextual knowledge
>>you refer to naturally falls out of the math. It's capable of finding
>>first-order correlations. So if you refer to hitting something with
>>something else as "whacking" and "smacking" in one place, and "smacking"
>>and "hitting" somewhere else, it'll let you "hit" in the first place and
>>"whack" in the second. I can also find more complex correlations
>>involving multiple words.
>
>
> I don't see how this works exactly but I grant that it could with the
> right data and even if it's killing a fly with a sledgehammer, what we all
> really want for Christmas are dead flies. But I wonder what data you need
> and whether this is the easiest route to building out synonyms.
>
>
>>This partially solves the the "guess the noun" and "guess the verb"
>>problems problems you referred to later in your post.
>
>
> Guess the noun is pretty different from guess the verb.
>
>
>>Second, it's a solution to the notorious "none of the above / I don't
>>know" classification problem. It knows when to say "I really don't
>>understand you" - which ML algorithms usually can't do. This part may
>>end up in a thesis.
>
>
> Sorry, I don't follow.


>
>
>>>At any rate, any such work would only be helpful if it were embedded
>>>transparently into an existing product such as Inform or TADS 3.
>>>Without the remaining system, no one if likely to use such an engine to
>>>write IF. So you should make your case to those authors. I suspect
>>>those authors are also best able to tell you where they see weaknesses
>>>in parsing.
>>>
>>>
>>

>>That's...three votes for working it into Inform or TADS. I think I
>>believe it now. :D
>
>
> Well, and a vote for discussing it with the real gate keepers. If someone
> authoritative from one of the full-featured development systems doesn't at
> least say "We'll consider adding your code to our product if you can make
> it do X." then you're wasting your time. Moreover, you'll meet a lot of
> rabble here like myself who have a glancing familiarity with the
> difficulties of writing a parser but the people developing Inform and
> TADS would be the ones who have spend years working on it and they will
> also be in a unique position to describe what it's hard to do with a
> deterministic parser.
>
>
>>Another huge problem that experienced players don't think about much is
>>"guess the syntax." We don't think about it because we *know* the
>
>
> What are some examples?
>
>
>>I'd like new players to be able to type in whatever they want, and learn
>>the quick syntax as they go.
>
>
> Great.. If you can do it... where "do it" means resolving arbitrary
> commands into noun, verb, indirect object, and direct object bits.
> Otherwise, the existing way that games are described/authored will not
> work.
>
> -Alan


--

Michael Roy

unread,
Dec 7, 2004, 10:07:01 PM12/7/04
to
Poster wrote:
>
> As for "guess the verb" you should be able to fix this by allowing the
> parser to be self-modifying and correctable by the user. Take the
> following bit of INFORM game play:
>
> > Strike the troll.
>
> I don't know the word "strike".
>
> > Synonym "hit".
>
> Understood. ["Strike" is synonym of "hit."]

But if the player already knows what the synonym is he'd just use it in
the first place. Guess-the-verb only comes when we don't know the
proper synonym. I think something like this would probably end up being
more useful for creating user defined shortcuts.

--
Michael

Fred the Wonder Worm

unread,
Dec 7, 2004, 11:42:21 PM12/7/04
to

In article <31n9elF...@individual.net>,

Michael Roy <inv...@invalid.invalid> wrote:
>Poster wrote:
>>
>> As for "guess the verb" you should be able to fix this by allowing the
>> parser to be self-modifying and correctable by the user. Take the
>> following bit of INFORM game play:
>>
>> > Strike the troll.
>>
>> I don't know the word "strike".
>>
>> > Synonym "hit".
>>
>> Understood. ["Strike" is synonym of "hit."]

BTW, the book _God Game_ by Andrew Greeley contains various
instances of something similar to the example above.

> But if the player already knows what the synonym is he'd just use it
> in the first place.

Not necessarily -- the player may find a certain term fits better
with the way they think. (Otherwise synonyms wouldn't flourish.)
For instance, I invariably use 'get' rather than 'take' -- in a game
with only the latter I would certainly appreciate being able to
synonymise the former. Not just because it is shorter, but because
that's how I would verbalise my thought processes. What I think to
myself is "I want to get the apple", not "I want to take the apple".

[ Side point: however, if someone were offering it to me, I would
think of it as 'take' rather than 'get'. Go figure. ]

Of course, this particular instance _should_ be done by default,
but you can't catch every dialect. I have friends who would use
'snarf' similarly, for instance. A more difficult example would
be 'frob'; a system which could handle its multiple meanings
correctly would be interesting.

http://www.retrologic.com/jargon/F/frobnicate.html

(Specific uses I have in mind are 'frob the switch' and 'frob the
lever', in which case 'flip' is the obvious synonym. But I could
see it being used for a knob as in the example above.)

> Guess-the-verb only comes when we don't know the proper synonym.

The above is not about avoiding guess-the-verb, but in not making
the user go through an internal translation step once they've
worked out how to convey their desire to the program. This might
be more useful with nouns, which seem to vary more widely.

(Specific instances that come to mind: torch/flashlight,
boot/trunk (cars), petrol/gas. I can _read_ the "wrong" version
of these without difficulties, but I think in terms of the other
one.)

> I think something like this would probably end up being more
> useful for creating user defined shortcuts.

Certainly that is a convenient consequence of the facility.

Cheers,
Geoff.

-----------------------------------------------------------------------------
Geoff Bailey (Fred the Wonder Worm) | Programmer by trade --
ft...@maths.usyd.edu.au | Gameplayer by vocation.
-----------------------------------------------------------------------------

Poster

unread,
Dec 12, 2004, 8:17:03 AM12/12/04
to

Well to be fair, I did leave out a step, which would be "listall"
wherein the command lists all the verbs known to the game. The user
could then pick one to map to.

I think Fred nailed it, though as for the reasons why this would be useful.

--Poster

Reply all
Reply to author
Forward
0 new messages