Making a parser - what are the minimal requirements?

1680 views
Skip to first unread message

Mark Borok

unread,
Mar 8, 2002, 10:51:50 PM3/8/02
to
I recently posted a message about writing IF in Lingo, the Director
scripting language. Of course, I'm not going to try to make a parser as
advanced as that in TADS, Inform or the others. My first thought was to
make one as simple as the one found in World Builder, which simply
checks for the presense of a given word in an input string. The
process, as I imagine it, would be as follows;

Put player's input into a list, word by word.
Remove any articles, conjunctions.
Check first word against list of character names (in case it's a
command to an NPC). If match found, run appropriate handler and delete
word from list.
Check first word against list of all verbs understood by game (with
their synonyms)
If match found, go to appropriate handler (function or subroutine),
which will then go through list looking for words it needs (e.g. if the
verb is "take" or "get", the handler looks for objects in the room that
match any of the words in the player's input, then, if they are
takeable, adds them to player's inventory and deletes them from the
room's contents. It also takes care of "get all" commands).

If necessary, this can be tweaked to accept multiple commands on a
single line by looking for the word "then" and putting all the words
after "then" into their own list, which would then be processed like
the first. However, I personally never use multiple commands on one
line when playing IF games and I don't know if this is a feature that's
useful enough to warrant the extra scripting. Call me lazy.

I understand this kind of minimal parser is too stupid to tell between
"put the kettle on the stove" and "put the stove on the kettle", but
this isn't critical to my needs. Dyslexic players need to have some fun
too, after all.

I would like to know what other pitfalls I would need to watch out for.
Can anyone think, offhand, of situations in which such a simple parser
would be inadequate? Types of commands that it couldn't handle?

--Mark

Kodrik

unread,
Mar 8, 2002, 11:26:19 PM3/8/02
to
> I recently posted a message about writing IF in Lingo, the Director
> scripting language. Of course, I'm not going to try to make a parser as
> advanced as that in TADS, Inform or the others. My first thought was to
> make one as simple as the one found in World Builder, which simply
> checks for the presense of a given word in an input string. The
> process, as I imagine it, would be as follows;

I haven't followed the traditional way of recognizing inputs for my engine
and it might be a way you can handle it in Lingo, I am not sure.

The way I do it, things are activated by "keys".
keys can be activated by a sequence of words that must be present in a
specific order.

So, if you want to recognize "put the kettle on the stove", you would set
the key to be activated by:
put * kettle * on * stove

"get "and "place" are synonyms of "put"
"pot" is synonym of "kettle"

So if the user types a sentence that matches this structure:
{put/get/place} * {pot/kettle} * on * {stove}
the key will be activated and the pot placed on the stove.

This works incredible well and the parser understands people writing plain
english:
"put the pot that I found in the blue room on the stove that is in front of
me"
"put the stove on the kettle" -> no match, those words are not in the
correct order.
You can of course set multiple commands to activate a same key.

This is failry easy to code, especially with regular expressions (don't
knowhow powerful they are in english), the trick will be to let the author
extract the data form the user input to custom built his output in various
ways. This becomes very complex but an interesting challenge.

Other advantages, which were my main reasons to code my parser this way 5
months ago was to be able to make the best possible use of speech
recognition and easy porting of the engine to other languages.

The engine is grammar-stupid but it is amazing how well it can match plain
english inputs with the appopriate keys.

Jim Aikin

unread,
Mar 8, 2002, 11:42:56 PM3/8/02
to
Mark Borok wrote:

> I recently posted a message about writing IF in Lingo, the Director
> scripting language. Of course, I'm not going to try to make a parser as
> advanced as that in TADS, Inform or the others.


Just out of curiosity, why not? Aside from the amount of work involved?
I'm very curious whether Lingo could do the job (crunch a lot of
disambiguation with reasonable speed, etc.).

I know next to nothing about Director and Lingo, but see my post earlier
tonight on text adventures with full multimedia support. If there was a
good text engine in Lingo, I would wrestle a whole football team full of
eight-foot-tall purple trolls with my bare hands in order to be able to
develop in that environment. Honestly, if you're serious about this,
please email me directly at midiguru23 (at-sign goes here) earthlink
(dot goes here) net. I'd love to learn more about what you have in mind.


> If match found, go to appropriate handler (function or subroutine),
> which will then go through list looking for words it needs (e.g. if the
> verb is "take" or "get", the handler looks for objects in the room that
> match any of the words in the player's input, then, if they are
> takeable, adds them to player's inventory and deletes them from the
> room's contents. It also takes care of "get all" commands).


As the gentleman was heard to remark in a satisfied tone as he passed
the 58th floor on his way down the outside of the Empire State Building,
"So far, so good." The difficulties you're going to have to wade into at
this point include, for instance, can the object in fact be taken? Or is
it perhaps tied or bolted down? Is it too heavy to lift? Et cetera. A
lot of this is up to the game code; the parser doesn't need to worry
about it in any direct way; but the parser DOES need to know that it has
to pass control to the code the programmer has tucked away into the
object, so that the object can indicate whether or not it feels like
being taken.


> If necessary, this can be tweaked to accept multiple commands on a
> single line by looking for the word "then" and putting all the words
> after "then" into their own list, which would then be processed like
> the first. However, I personally never use multiple commands on one
> line when playing IF games and I don't know if this is a feature that's
> useful enough to warrant the extra scripting. Call me lazy.


No, you're being practical. If you're not going to allow two nouns per
command (but see below), allowing two commands per line is a cosmetic
feature you can easily ditch.


> I understand this kind of minimal parser is too stupid to tell between
> "put the kettle on the stove" and "put the stove on the kettle", but
> this isn't critical to my needs. Dyslexic players need to have some fun
> too, after all.


Dyslexia is rather beside the point, I think. Spelling errors can be
corrected after the parser issues an error message. The point is, your
command set will be way too limited if you don't allow one object to be
used on another object in a specific way. "Adventure" was great fun, but
that was then. This is now. I wouldn't touch a programming environment
that didn't allow my users to manipulate objects in this way.


> I would like to know what other pitfalls I would need to watch out for.
> Can anyone think, offhand, of situations in which such a simple parser
> would be inadequate? Types of commands that it couldn't handle?


A simple parser can make assumptions that will cover you in certain
areas, but those assumptions are fraught with their own sort of peril.
To take a simple instance, say the user wants to type "stab troll with
sword," but has to make do with "stab troll." At this point, the parser
has to be smart enough to know that the sword is a suitable implement
for stabbing (while the rutabaga is not), and has to check whether the
player has immediate access to the sword, so that it can use the implied
tool in order to carry out the action. And what if the game developer
happens to want to include both a sword and a knife in the game, and
what if the player happens to be carrying them both at the moment, but
the knife is rusty while the sword is sharp, or the knife is sturdy
while the sword blade is liable to break off?

Even ignoring the attributes of the weapons that may or may not be
available, choosing the sword implicitly implies a level of
disambiguation in the parser that will be, I should think, rather
amusing to code up. You might in fact find it easier to allow "stab
troll with sword." I've never developed a parser, but that's my bet.

--Jim Aikin

Kodrik

unread,
Mar 9, 2002, 12:04:50 AM3/9/02
to
> As the gentleman was heard to remark in a satisfied tone as he passed
> the 58th floor on his way down the outside of the Empire State Building,
> "So far, so good." The difficulties you're going to have to wade into at
> this point include, for instance, can the object in fact be taken? Or is
> it perhaps tied or bolted down? Is it too heavy to lift? Et cetera. A
> lot of this is up to the game code; the parser doesn't need to worry
> about it in any direct way; but the parser DOES need to know that it has
> to pass control to the code the programmer has tucked away into the
> object, so that the object can indicate whether or not it feels like
> being taken.

The parser doesn't need to understand the sentence, just know if the
matches are valid.

Before reading below, you have to understand the concept of keys from my
other post:

Let's make a room with a candy in a box.
The parser will only try to match keys that are valid:
Valid keys: "open box"
Sleeping keys: "take candy", "eat candy", "close box"
So the parser is only trying to match open box.

Now we open the box, the key to open the box sets the key to take the candy
and close the box as active.
So the parser will only recognize "take candy" and "close box".
And so on and so on.

Keys control everything, their status is based on any other variable of the
game and when activated they can chaneg any variable of the game.

CardinalT

unread,
Mar 9, 2002, 1:15:45 PM3/9/02
to
Kodrik wrote:

> This works incredible well and the parser understands people writing plain
> english:
> "put the pot that I found in the blue room on the stove that is in front
> of me"

It would still break down, though, in a case, say, where the player finds a
pot in the blue room and another in the red room, right? For example, if
you distinguished them in the code by naming them "blue room pot" and "red
room pot," the parser would no longer understand the above input correctly.
Or am I wrong about that?

In many ways I like the idea of the parser simply ignoring words it
considers extraneous. But it seems like that method has the potential for
confusing the player as well (if what I've said here is true).

--
--CardinalT
Archbishop of Frith and Funeral Barker to the Stars

Mark Borok

unread,
Mar 9, 2002, 1:19:06 PM3/9/02
to
In article <3C8992EC.5030600@kill_spammers.org>, Jim Aikin
<kill_spammers@kill_spammers.org> wrote:

> Mark Borok wrote:
>
> > I recently posted a message about writing IF in Lingo, the Director
> > scripting language. Of course, I'm not going to try to make a parser as
> > advanced as that in TADS, Inform or the others.
>
>
> Just out of curiosity, why not? Aside from the amount of work involved?
> I'm very curious whether Lingo could do the job (crunch a lot of
> disambiguation with reasonable speed, etc.).
>
> I know next to nothing about Director and Lingo, but see my post earlier
> tonight on text adventures with full multimedia support. If there was a
> good text engine in Lingo, I would wrestle a whole football team full of
> eight-foot-tall purple trolls with my bare hands in order to be able to
> develop in that environment. Honestly, if you're serious about this,
> please email me directly at midiguru23 (at-sign goes here) earthlink
> (dot goes here) net. I'd love to learn more about what you have in mind.

I'm not as experienced with Lingo as I'd like to be, although I feel
that I've just passed from "beginner" to "intermediate". I can script
most things that don't involve advanced math.

Having said that, I suppose theoretically the parser could be made as
powerful as the one in TADS, etc. since Lingo has the full complement
of string commands (and more commands for handling lists than I've seen
in TADS). It is likely to be slower, although on modern machines, and
with the speed improvements of the latest version of Director, that
shouldn't be noticeable. My purpose, however, is to use it as a
teaching tool for a possible class on game design for people with
little or on Director experience, so I don't want to get too advanced.
I don't want to use this NG to promote Director, so I'll be more
detailed in a separate email.


>
>
> > If match found, go to appropriate handler (function or subroutine),
> > which will then go through list looking for words it needs (e.g. if the
> > verb is "take" or "get", the handler looks for objects in the room that
> > match any of the words in the player's input, then, if they are
> > takeable, adds them to player's inventory and deletes them from the
> > room's contents. It also takes care of "get all" commands).
>
>
> As the gentleman was heard to remark in a satisfied tone as he passed
> the 58th floor on his way down the outside of the Empire State Building,
> "So far, so good." The difficulties you're going to have to wade into at
> this point include, for instance, can the object in fact be taken? Or is
> it perhaps tied or bolted down? Is it too heavy to lift? Et cetera. A
> lot of this is up to the game code; the parser doesn't need to worry
> about it in any direct way; but the parser DOES need to know that it has
> to pass control to the code the programmer has tucked away into the
> object, so that the object can indicate whether or not it feels like
> being taken.

Director is very object-oriented. Properties can easily be assigned to
objects and checked by the handler.


>
>
> > If necessary, this can be tweaked to accept multiple commands on a
> > single line by looking for the word "then" and putting all the words
> > after "then" into their own list, which would then be processed like
> > the first. However, I personally never use multiple commands on one
> > line when playing IF games and I don't know if this is a feature that's
> > useful enough to warrant the extra scripting. Call me lazy.
>
>
> No, you're being practical. If you're not going to allow two nouns per
> command (but see below), allowing two commands per line is a cosmetic
> feature you can easily ditch.

You can use as many nouns as you want, the parser looks through all of
them and compares them to what's available. It's just the order that
would be arbitrary. Again, one could compare any two words to see which
comes first (you make them items in a list and then compare their
positions), but I can't think of many instances where it would be
ambiguous what the player really wants to do.


>
>
> > I understand this kind of minimal parser is too stupid to tell between
> > "put the kettle on the stove" and "put the stove on the kettle", but
> > this isn't critical to my needs. Dyslexic players need to have some fun
> > too, after all.
>
>
> Dyslexia is rather beside the point, I think. Spelling errors can be
> corrected after the parser issues an error message. The point is, your
> command set will be way too limited if you don't allow one object to be
> used on another object in a specific way.

Like an earlier poster mentioned, you would check for all words that
apply in a given situation. I'm just not sure it's necessary to insist
that they be in the correct order. This can be done, if there are
realistically situations where different word order could make equal
sense ("put the red box on top of the blue box") or where switching
word order would create an impossible situation ("put the big box
inside the little box"), but not where reversing word order results in
something no player could have seriously intended ("put the keyhole in
the key"). In a game without objects that can interact in ways that
would cause problems, the effort involved in such scripting would, I
think, be unnecessary.

Of course, if the player wanted to type, "hit the anvil with the hammer
and the chicken", the game might simply ignore the chicken and respond
as if only hammer was intended. It would look for the word "with", then
send each word after that as a parameter to the "anvil" object until it
got a valid response. If the word "with" wasn't found, it would assume
you meant "with my fist" and respond accordingly.


>
> A simple parser can make assumptions that will cover you in certain
> areas, but those assumptions are fraught with their own sort of peril.
> To take a simple instance, say the user wants to type "stab troll with
> sword," but has to make do with "stab troll." At this point, the parser
> has to be smart enough to know that the sword is a suitable implement
> for stabbing (while the rutabaga is not),

If the verb "stab" was used, the relevant handler would check to see if
the player's command had any words matching words from the list
"inventory", then check that word against the list "weapons". It would
respond appropriately. I never considered this a parser problem,
although maybe I'm using the wrong definition of the word "parser".

> --Jim Aikin

--Mark Borok

Andrew Plotkin

unread,
Mar 9, 2002, 1:46:51 PM3/9/02
to

I think I've *used* a parser that ignored words like that -- no, I
don't remember where, it was a while ago -- and indeed, it *was*
confusing.

In many ways it's more important for the player to understand what the
parser understands, than for the parser to understand the player.

--Z

"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
* Make your vote count. Get your vote counted.

Kodrik

unread,
Mar 9, 2002, 3:14:13 PM3/9/02
to
CardinalT wrote:

> Kodrik wrote:
>
>> This works incredible well and the parser understands people writing
>> plain english:
>> "put the pot that I found in the blue room on the stove that is in front
>> of me"
>
> It would still break down, though, in a case, say, where the player finds
> a pot in the blue room and another in the red room, right? For example, if
> you distinguished them in the code by naming them "blue room pot" and "red
> room pot," the parser would no longer understand the above input
> correctly. Or am I wrong about that?

If you use this system, ordering your inputs is very important and
associating clauses to them also. Since you can associate conditions to
your keys, you can make them act differently depening on the status of the
game.

if(blue pot in inventory)
put * pot * blue * stove ->"put blue pot"
else
put * pot * blue * stove ->"you don't have pot"

if(red pot in inventory)
put * pot * red * stove ->"put red pot"
else
put * pot * red * stove ->"you don't have the red pot"

if(blue pot and red pot in inventory)
put * pot * stove -> "which pot?"
else
put * pot * stove -> put whichever pot on stove


So if you don't specify a color and have only one pot it works, if you have
both pots, it asks you to narrow your questions, if you specify the red
pot, it tells you that you don't have it.


chy...@ludens.elte.hu

unread,
Mar 9, 2002, 10:29:42 PM3/9/02
to
In article <a6dlar$c6q$1...@reader2.panix.com>, Andrew Plotkin <erky...@eblong.com> writes:
> CardinalT <card...@helpmejebus.com> wrote:
>> Kodrik wrote:
>
>>> This works incredible well and the parser understands people writing plain
>>> english:
>>> "put the pot that I found in the blue room on the stove that is in front
>>> of me"
>
>> It would still break down, though, in a case, say, where the player finds a
>> pot in the blue room and another in the red room, right? For example, if
>> you distinguished them in the code by naming them "blue room pot" and "red
>> room pot," the parser would no longer understand the above input correctly.
>> Or am I wrong about that?
>
>> In many ways I like the idea of the parser simply ignoring words it
>> considers extraneous. But it seems like that method has the potential for
>> confusing the player as well (if what I've said here is true).
>
> I think I've *used* a parser that ignored words like that -- no, I
> don't remember where, it was a while ago -- and indeed, it *was*
> confusing.

The MUD I code for had almost exactly such a parser. Everyone hated it.
It was fixed, and is now similar to the parsers used in IF (with some
streamlining, to make it more appropriate for a real-time environment).

Chyron
--
"Beware of he who would deny you access to information, for in his
heart he dreams himself your master." -- Commissioner Pravin Lal

"People who think they have a right not to be offended are trouble."
-- Alsee

CardinalT

unread,
Mar 9, 2002, 10:35:49 PM3/9/02
to
Kodrik wrote:

> CardinalT wrote:
>
>> Kodrik wrote:
>>
>>> This works incredible well and the parser understands people writing
>>> plain english:
>>> "put the pot that I found in the blue room on the stove that is in front
>>> of me"
>>
>> It would still break down, though, in a case, say, where the player finds
>> a pot in the blue room and another in the red room, right? For example,
>> if you distinguished them in the code by naming them "blue room pot" and
>> "red room pot," the parser would no longer understand the above input
>> correctly. Or am I wrong about that?
>
> If you use this system, ordering your inputs is very important and
> associating clauses to them also. Since you can associate conditions to
> your keys, you can make them act differently depening on the status of the
> game.
>
> if(blue pot in inventory)
> put * pot * blue * stove ->"put blue pot"
> else
> put * pot * blue * stove ->"you don't have pot"

Ok, I understand that your parser is capable of disambiguation. That's not
the issue. What I'm saying is that if you have two pots and you distinguish
them in the code by their color, such that you have a "blue [room] pot" and
a "red [room] pot," the player is no longer going to be able to type "put
the pot that I found in the blue room on the stove" because the words "pot"
and "blue" will now both be tokens understood by the engine but will be in
the wrong word order.

If this much is true, it's a problem for the player because in cases where
things aren't specifically assigned the distinguishing adjective "blue" but
are nevertheless found in the blue room--let's take, for example, a radio,
where this radio is the one and only radio in the game--the player is going
to be allowed to type "put the radio that I found in the blue room on the
stove," while "put the pot that I found in the blue room on the stove" will
be rejected. Do you see the problem with that? It will be a huge source of
confusion and frustration for the player.

However, are you saying that with your system a designer can avoid the
situation I'm describing by specifically ordering the engine to recognize
the word order "pot, blue" in addition to "blue, pot?"

If so, I think I'm beginning to understand that your engine doesn't have a
default parsing behavior, but only follows whatever rules the designer
tells it to follow, and that moreover the designer must write these rules
in toto and anew for each and every referenceable object he creates. Is
that correct?

Kodrik

unread,
Mar 9, 2002, 10:55:47 PM3/9/02
to
> However, are you saying that with your system a designer can avoid the
> situation I'm describing by specifically ordering the engine to recognize
> the word order "pot, blue" in addition to "blue, pot?"

Yes, you specify the order of the words on top of the order in which the
parser will try to match the sentences:

So could could say:
1 {pot} {blue} -> talking about the pot from the blue room
2 {blue} {pot} -> talking about the blue pot
3 {pot} -> ask which pot
4 {blue} ask whether he is talking about the blue pot or the pot from the
room

> If so, I think I'm beginning to understand that your engine doesn't have a
> default parsing behavior, but only follows whatever rules the designer
> tells it to follow, and that moreover the designer must write these rules
> in toto and anew for each and every referenceable object he creates. Is
> that correct?

Exactly, but it is not as hard as it sounds for the author to define them.

Kodrik

unread,
Mar 9, 2002, 11:19:28 PM3/9/02
to
> The MUD I code for had almost exactly such a parser. Everyone hated it.
> It was fixed, and is now similar to the parsers used in IF (with some
> streamlining, to make it more appropriate for a real-time environment).

The key was to let the author order the sequence in which the parser
matches the input, on top of the word order. By ordering the
matching you can make the parser trim the possibilities in sequence,
matching detailed structures first then go to the most basic ones:
1 "cloak hook" -> put the cloak on the hook
2 "examine hook" -> examine the hook
3 "take hook" -> try to take the hook
4 "drop cloak" -> drop the cloak on the ground
5 "examine cloak" -> examine the cloak
6 "cloak" -> what do you want to do with the cloak?
7 "drop" -> You don't have that to drop.

And this will understand most commands the user enters to hang the cloak in
"cloak of darkness".

Then, the interface had to be made so it is easy for the author, in my case
I chose pop-up menus with:

Adverb / Verb / Preposition / Object / Preposition / Object

but I plan to let the author enter full regular expressions for more
complex matching.

Also, when you build your sentence, you only need to use the master words,
synonyms will be combined automatically to solve all possible combinations.
Also, youcan have multiple word/synonym combinations which you can handle
by placing them appropriately.

The result is that people can type in plain english.

One drawback is for replies based on user input. It is quite challenging
but also quite doable. I am waiting for specific request from authors to
implement it because there are so many approach I can take and I would
prefer to be guided by people with a different perspective.

Finally, porting the engine to other language just means translating the
dictionary and speech recognition is much more accurate.

Kodrik

unread,
Mar 10, 2002, 12:02:15 AM3/10/02
to
> One drawback is for replies based on user input. It is quite challenging
> but also quite doable.

What I mean is replies that includes extractions of part of the user input.
I would like to offer another way to authors than having the learn regular
expression, alothough they will eb abl to use them if they wish.


CardinalT

unread,
Mar 10, 2002, 12:40:00 AM3/10/02
to
Kodrik wrote:

>> If so, I think I'm beginning to understand that your engine doesn't have
>> a default parsing behavior, but only follows whatever rules the designer
>> tells it to follow, and that moreover the designer must write these rules
>> in toto and anew for each and every referenceable object he creates. Is
>> that correct?
>
> Exactly, but it is not as hard as it sounds for the author to define them.

Ah, but it is if you want your parser to respond sensibly to a wide variety
of attempted, albeit failed, actions. Even though "throw me" is unlikely to
be successful in any game, it's just much more satisfying and "friendly"
for the player to receive a response like "You can't throw yourself!" than
"error 672: illegal input". But such context-sensitive error messages seem
impossible under your implementation. Are they? That is, are they without
having to code one for each and every object in the game?

CardinalT

unread,
Mar 10, 2002, 12:52:03 AM3/10/02
to
Andrew Plotkin wrote:

> In many ways it's more important for the player to understand what the
> parser understands, than for the parser to understand the player.

I completely, 100% agree.

Kodrik

unread,
Mar 10, 2002, 1:33:24 AM3/10/02
to
> Ah, but it is if you want your parser to respond sensibly to a wide
> variety of attempted, albeit failed, actions. Even though "throw me" is
> unlikely to be successful in any game, it's just much more satisfying and
> "friendly" for the player to receive a response like "You can't throw
> yourself!" than "error 672: illegal input". But such context-sensitive
> error messages seem impossible under your implementation. Are they? That
> is, are they without having to code one for each and every object in the
> game?

With only the system I described so far, you would have to code one for
each object in the game.
Which is okay for all default response such as "throw myself" because once
an author will have created a library of default response, other authors
will be able to import his libraries.

The problem is for answers with objects specific to the game, the author
shouldn't have to implement each and every combinations.

I am developing a system where you will be able to specify states of
objects instead of words:

"take" {object not in view} -> You don't see $objectname
"take" {object in inventory} -> You already have $objectname
"take" {objecy in view} -> You can't take it (if it can be taken, another
author defined key to take it would have had precedence.

Again, once an author develops a library of default replies based on object
states other authors will be able to import them and customize them for
their adventures.

I won't know how succesfull it will be versus grammar interpretation until
it is implemented and tested with, which won't be for another month.

Mark W

unread,
Mar 10, 2002, 1:56:35 AM3/10/02
to
> What I'm saying is that if you have two pots and you
> distinguish them in the code by their color, such that you have a
> "blue [room] pot" and a "red [room] pot," the player is no longer
> going to be able to type "put the pot that I found in the blue room on
> the stove" because the words "pot" and "blue" will now both be tokens
> understood by the engine but will be in the wrong word order.

This also assumes that the author decided to attach that value to the pots.
The engine certainly didn't arbitrarily decide that the color of the room
that the pot was found in should be important to the player.

In this case there are two obstacles I see. I have a tendancy to state the
obvious, so bear with me.

First, and most obvious, the author decided to identify an item based on
it's association to another item. "This Pot came from a Room" where both
Pot and Room are things identified by the parser.

Second, this thing that is associated is itself identified by a quality it
posesses (being either red or blue). The color of the room is almost an
adverb to the pot (the deep red pot or the bright red pot/the red room pot
the blue room pot).

This parser would have to recognize speach in a manner that's exponentially
more complex than the current breed of parsers. They'd be cutting edge in
terms of language recognition, and not just in IF in the world of AI as
well.

Perhaps regular expression is rich enough to solve this problem (or create
the illusion of solving this problem), but you'd be opening the door for
more and more complex player input in unanticipated ways. "Examine the pot
that I found around the time that I lost the key to the front gate." "Pick
up the locket that Aunta Freida said she was given by a German officer
during World War II and put it to the left of the urn that contains the
ashes of Uncle Frank on the mantle piece."

Authors will have to ancipate every possible association the player might
make to an object games would become a complex web of objects and
relationships.

Mark

Kodrik

unread,
Mar 10, 2002, 2:10:12 AM3/10/02
to
CardinalT wrote:

> Andrew Plotkin wrote:
>
>> In many ways it's more important for the player to understand what the
>> parser understands, than for the parser to understand the player.
>
> I completely, 100% agree.
>

Like you, I don't mind adapting my speech for Zork to understand my inputs
but believe me it is a major issue with a lot of people.

My wife, for example, wants to type in english full sentences with many
useless words, she can't play the inform cloak of darkness because she
wants to type in english:
"Remove the cloak that I am wearing"
"Hang the cloak on that hook"
"Read the message inscribed in the sawdust"
And from the feedback from phpzork, she is far from being alone.

It is hard for us programmers to understand that because we naturally
follow strict language but it is not the case for the general public.

When we play an IF game, some of our judgment criterias are how far the
author pushed the limit of the engine and we actually enjoy playing "guess
the right word and command structure".
But I believe the the mass wants to dialog with their own words and would
even prefer to talk than to type. They will rather not play than discipline
their speech so much.

IF you type "read the message that is inscribed in the sawdust" in the
inform version of Cloak of Darkness, it will answer:
"You discover nothing of interest in the scrawled message."
We know better and would type "read message" that will tell us "You win".
But a neophyte would have no clue and they would assume there is no need to
read the message again or reword their sentence.
If you type "look at the hook on the wall", it will answer:
"I only understood you as far as wanting to look at the small brass hook"
Many people don't care about the mechanism of the parser, they just want
the parser to understand them when they speack plain English (or whatever
language).

I record everything that is typed in phpzork, you wouldn't believe how many
people start playing the game typing sentences as if they were talking to a
human being. Some quit, frustrated and some adapt their speech.

What us authors and programmers see as the most convenient to play is not
always what the non-initiated want.

I think grammar parsing will always have an edge on fully understanding the
user input and therefore offer more appropriate generic replies and until I
finish the system, we won't know how far structure parsing can go.

I might end up with a hybrid parser structure/grammar where default
response are handled by the grammar parser and direct actions handled by
the structure parser.

Engines evolve, mine like current one, the parser behavior won't make
authors switch engines because the engines are regurarly enhanced towards
the same goal, and if some new elements are proved beneficial, major
engines can easily incorporate them.

CardinalT

unread,
Mar 10, 2002, 4:34:23 AM3/10/02
to
Mark W wrote:

> This parser would have to recognize speach in a manner that's
> exponentially more complex than the current breed of parsers. They'd be
> cutting edge in terms of language recognition, and not just in IF in the
> world of AI as well.
>
> Perhaps regular expression is rich enough to solve this problem (or create
> the illusion of solving this problem), but you'd be opening the door for
> more and more complex player input in unanticipated ways. "Examine the pot
> that I found around the time that I lost the key to the front gate." "Pick
> up the locket that Aunta Freida said she was given by a German officer
> during World War II and put it to the left of the urn that contains the
> ashes of Uncle Frank on the mantle piece."
>
> Authors will have to ancipate every possible association the player might
> make to an object games would become a complex web of objects and
> relationships.

I'm not sure I completely follow you, but you seem to be thinking that
Kodrik's parser actually understands all the extra verbage that's being
thrown at it. It doesn't, however. It simply ignores it as if it was never
said. The player is totally free to type whatever he wants so long as
somewhere along the line he matches all the necessary tokens. Thus, "put
blue pot stove" is equivalent in every way to "put blue pot <insert entire
text of Rime of the Ancient Mariner here> stove."

There are several problems with this, one of which hasn't been mentioned
yet: to wit, if the parser doesn't understand and ignores *true* extraneous
assertions, it will do the same for false ones. Thus, there's no reason the
parser wouldn't accept "put the pot that I found in the blue room right
after I assassinated JFK on the stove" as valid, "successful" input even if
the player never, in fact, assassinated JFK.

CardinalT

unread,
Mar 10, 2002, 5:03:51 AM3/10/02
to
Kodrik wrote:

> With only the system I described so far, you would have to code one for
> each object in the game.
> Which is okay for all default response such as "throw myself" because once
> an author will have created a library of default response, other authors
> will be able to import his libraries.

Ok, this is a good thing. I'm listening. :)

> The problem is for answers with objects specific to the game, the author
> shouldn't have to implement each and every combinations.

Couldn't have said it better myself. :)

> I am developing a system where you will be able to specify states of
> objects instead of words:
>
> "take" {object not in view} -> You don't see $objectname
> "take" {object in inventory} -> You already have $objectname
> "take" {objecy in view} -> You can't take it (if it can be taken, another
> author defined key to take it would have had precedence.
>
> Again, once an author develops a library of default replies based on
> object states other authors will be able to import them and customize them
> for their adventures.
>
> I won't know how succesfull it will be versus grammar interpretation until
> it is implemented and tested with, which won't be for another month.

I don't know why you say you don't know how successful it will be vs.
grammar interpretation...this *is* grammar interpretation. This is
precisely the way the (for lack of a better word) "mainstream" IF languages
do it. They evaluate word tokens based upon their positions and functions
within a sentence.

I think it's good news that you're considering heading in this direction,
as otherwise I think you're dooming your system to failure. In fact, even
if you make the above grammar system optional somehow, what you're going to
find is that people are going to use it exclusively anyway, due to its much
greater overall power (and reduction of workload), making it a de facto
core component of your overall game package. So design it well :)

Kodrik

unread,
Mar 10, 2002, 5:53:18 AM3/10/02
to
> I don't know why you say you don't know how successful it will be vs.
> grammar interpretation...this *is* grammar interpretation. This is
> precisely the way the (for lack of a better word) "mainstream" IF
> languages do it. They evaluate word tokens based upon their positions and
> functions within a sentence.

I'm saying it's not grammar interpration because the parser doesn't know
the type of words and down't care to understand the sentence, he is just
trying to find patterns in the sentence. Current IF tries to understand the
whole sentence, not just pattern matching, which is what I would be doing
here in a more elaborate manner.

"take" {object in inventory} -> You already have $objectname

If I write:
Let's take the pretty cloak that is on the floor.
It matches "take" and "cloak" as one of the inventory names and activates
the key. It never breaks up the sentence gramatically.

Current parser understand the sentence and then match it with a key, I list
all possible matching for each key and try to match the patterns.
In the case above, I would build all patterns of combinations of, take and
its synonyms, and all object currently in inventory.
If you have three synonyms for take (grab, get, acquire) and five object in
inventory, it will try to match 20 patterns and if it fails move on to the
next key.

> I think it's good news that you're considering heading in this direction,
> as otherwise I think you're dooming your system to failure. In fact, even
> if you make the above grammar system optional somehow, what you're going
> to find is that people are going to use it exclusively anyway, due to its
> much greater overall power (and reduction of workload), making it a de
> facto core component of your overall game package. So design it well :)

It's not optional, authors will decide what system to match different keys.
For some, like {take} {cloak}, they will probably use the simple pattern
matching, for general behavior, the system I talked about, and for other
special needs, regular expressions.

The parser goes through the keys in order, trying to find a match for each
one of them using whatever system is set for the key.
They all have their strengh and weaknesses for different kind of keys and I
think a good author will use them accordingly.

Kodrik

unread,
Mar 10, 2002, 6:02:48 AM3/10/02
to
> There are several problems with this, one of which hasn't been mentioned
> yet: to wit, if the parser doesn't understand and ignores *true*
> extraneous assertions, it will do the same for false ones. Thus, there's
> no reason the parser wouldn't accept "put the pot that I found in the blue
> room right after I assassinated JFK on the stove" as valid, "successful"
> input even if the player never, in fact, assassinated JFK.

That is very true, it can validate inputs that shoudn't be

In cloak of darkness, if you say "burn the cloak and put it on the hook",
it will understand "put it on the hook" and will not burn it.
To balance that problem, the key outputs what it actually does so the
player is not misguided.

>burn the cloak and put it on the hook
-----------------------
You hang the cloak on the hook
-----------------------
You are in the cloakroom, there is a cloak hanging on the hook.

So far, it hasn't been an problem for users that the parser understands
more than it should. I think it is better than understanding less or
misleading the character like in Inform's Cloak of Darkness where you
actually believe you have read the sawdust when you haven't.

The major drawback is that the player might move on in the game by accident
sometimes rather than by wits.

CardinalT

unread,
Mar 10, 2002, 6:31:49 AM3/10/02
to
Kodrik wrote:

> Like you, I don't mind adapting my speech for Zork to understand my inputs
> but believe me it is a major issue with a lot of people.
>
> My wife, for example, wants to type in english full sentences with many
> useless words, she can't play the inform cloak of darkness because she
> wants to type in english:
> "Remove the cloak that I am wearing"
> "Hang the cloak on that hook"
> "Read the message inscribed in the sawdust"
> And from the feedback from phpzork, she is far from being alone.

This is a very good point. There's certainly a learning curve involved in
beginning to use the "smart" parsers that the "dumb" ones don't have
("smart" and "dumb" not being value judgments, but simply a way to
distinguish between those that insist upon understanding every word in a
sentence and those that don't much care what's typed). However, ask your
wife to type in "remove the cloak that I'm not wearing." I'd be interested
to hear her response after the game goes ahead and removes the cloak for
her. Maybe she doesn't care--I don't want to anticipate her response for
her--but I know I would have cared way back when if Zork had allowed
something like that. I wouldn't have taken the parser seriously in that
case, even as a rank newbie player with no pretensions whatsoever toward
grasping the underlying programming.

> It is hard for us programmers to understand that because we naturally
> follow strict language but it is not the case for the general public.

You may be right, but the player can't have his cake and eat it too. If he
truly wants to play games that don't recognize commands for one object that
they just a second ago understood for another then who can argue with that?
But if the player wants to be able to type whatever in the world he wants
to and have the computer actually *understand* it to boot--well, who's
being unrealistic now? :)

> When we play an IF game, some of our judgment criterias are how far the
> author pushed the limit of the engine and we actually enjoy playing "guess
> the right word and command structure".

This is not really true. While I know enough about IF languages to engage
in this guessing game, it's far from the case that I enjoy it. Like I said
in an earlier post, there's a lot to like about the notion of a "dumb"
parser.

> But I believe the the mass wants to dialog with their own words and would
> even prefer to talk than to type. They will rather not play than
> discipline their speech so much.

I don't see how your system eliminates the "guess the command" game. The
player still has to type in something the parser recognizes, right? All it
really eliminates are contextual error messages and the confusion they once
in awhile inspire. Part of that confusion is unavoidable, I think, so your
criticism is justified, but part of it also depends upon the skill with
which the default messages are written. I've seen some horribly written
default messages that could have easily been fixed with just a little more
forethought on the author's part.

> IF you type "read the message that is inscribed in the sawdust" in the
> inform version of Cloak of Darkness, it will answer:
> "You discover nothing of interest in the scrawled message."
> We know better and would type "read message" that will tell us "You win".
> But a neophyte would have no clue and they would assume there is no need
> to read the message again or reword their sentence.

Yep, you're right, and not even necessarily neophytes.

> If you type "look at the hook on the wall", it will answer:
> "I only understood you as far as wanting to look at the small brass hook"
> Many people don't care about the mechanism of the parser, they just want
> the parser to understand them when they speack plain English (or whatever
> language).

But again, there's a tradeoff involved. They want the parser to understand
"plain English," yet how is it "understanding plain English" to look at the
hook on the wall in response to, say, "don't look at the hook on the wall"
or "look at the hook that's not on the wall?"

> I record everything that is typed in phpzork, you wouldn't believe how
> many people start playing the game typing sentences as if they were
> talking to a human being. Some quit, frustrated and some adapt their
> speech.
>
> What us authors and programmers see as the most convenient to play is not
> always what the non-initiated want.

Believe me, I understand the problem. That's not why I'm arguing what I'm
arguing. I simply think that unless you or me or someone else can come up
with a way to let the player have his cake and eat it too, the "smart"
parser approach ends up being the better, more popular approach among
*players*. True, rank newbies or players-in-passing aren't going to
gravitate to it, but I think those who perservere and become interested in
the genre eventually become frustrated with the limitations of the "dumb"
parser approach and end up consenting to the notion that they share a bit
of the responsibility in learning how to play.

Matthew Russotto

unread,
Mar 10, 2002, 11:02:04 AM3/10/02
to
In article <u8m20ls...@corp.supernews.com>, Kodrik <kod...@zc8.net> wrote:
>
>My wife, for example, wants to type in english full sentences with many
>useless words, she can't play the inform cloak of darkness because she
>wants to type in english:
>"Remove the cloak that I am wearing"
>"Hang the cloak on that hook"
>"Read the message inscribed in the sawdust"
>And from the feedback from phpzork, she is far from being alone.
>
>It is hard for us programmers to understand that because we naturally
>follow strict language but it is not the case for the general public.
>
>When we play an IF game, some of our judgment criterias are how far the
>author pushed the limit of the engine and we actually enjoy playing "guess
>the right word and command structure".
>But I believe the the mass wants to dialog with their own words and would
>even prefer to talk than to type. They will rather not play than discipline
>their speech so much.

Fine. Take away their keyboards, hand them a joystick, and start up the
latest 1st person shooter.

Understanding general English is too difficult a problem and won't be
solved in any IF engine anytime soon.

--
Matthew T. Russotto mrus...@speakeasy.net
=====
Dmitry is free, but the DMCA survives. DMCA delenda est!
"Extremism in defense of liberty is no vice, and moderation in pursuit
of justice is no virtue."

David Thornley

unread,
Mar 10, 2002, 11:43:51 AM3/10/02
to
In article <3c8af...@corp-news.newsgroups.com>,

CardinalT <card...@helpmejebus.com> wrote:
>Andrew Plotkin wrote:
>
>> In many ways it's more important for the player to understand what the
>> parser understands, than for the parser to understand the player.
>
>I completely, 100% agree.
>
The same issue has come up in the design of computer languages, and
has been essentially resolved in the same way. Languages like COBOL,
which attempt to model natural language, are harder to use properly
than languages with simpler grammars that look less like English.

People are good with language, and are good at adapting their
language to the circumstances. This means that they can fairly
easily learn a limited form of language to communicate with a
game, and we know that it's very hard to understand actual
English. To oversimplify, somebody's going to have to be flexible
in this interface, and it's really hard to make it the computer.


--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-

David Thornley

unread,
Mar 10, 2002, 11:50:06 AM3/10/02
to
In article <3c8a5...@corp-news.newsgroups.com>,

CardinalT <card...@helpmejebus.com> wrote:
>Kodrik wrote:
>
>> This works incredible well and the parser understands people writing plain
>> english:
>> "put the pot that I found in the blue room on the stove that is in front
>> of me"
>
>It would still break down, though, in a case, say, where the player finds a
>pot in the blue room and another in the red room, right? For example, if
>you distinguished them in the code by naming them "blue room pot" and "red
>room pot," the parser would no longer understand the above input correctly.
>Or am I wrong about that?
>
I think the answer here is "don't do that". No author is forced to
make pots indistinguishable only by what room they were found in.
There are limitations to this medium, and sometimes the best thing
to do is to live with them.

Kevin Forchione

unread,
Mar 10, 2002, 12:19:43 PM3/10/02
to
Kodrik <kod...@zc8.net> wrote in message news:<u8m20ls...@corp.supernews.com>...


> It is hard for us programmers to understand that because we naturally
> follow strict language but it is not the case for the general public.

Well, the general public that doesn't interface with technology, that
is. Even the X-Box WWF game comes equiped with a tutorial instructing
the player on how to move and manipulate objects in the game. Games
like Laura Croft have training areas where the player is taught the
proper keyboard/mouse combinations required to function in the game
world. Other games have tutorial modes, as well as manuals, that are
used to instruct the newbies on the use of the interface - because
even the joypad doesn't carry the same semantics across all platform
games.

Infocom games came with instructions on what the player command syntax
was, as part of the package of materials that usually provided
background information. Modern IF often has an Instructions command or
Help that then provides a brief summary of the player command syntax
and examples.

However, if a newbie encounters Zork or any other infocom game without
browsing the documentation then it's probably even odds that they'll
give up, just as the newbie would for any graphical game that involved
more than a joystick and fire button.

The game-playing public *does* understand restricted languages. It's a
basic part of the "let's pretend..." psychology we all had as
children. The failure of finding satisfaction in the gaming experience
is a matter of managed expectations, of understanding the rules of
engagement, the rules of the game.

--Kevin

wo...@one.net

unread,
Mar 10, 2002, 1:05:01 PM3/10/02
to

Hi Kodrik,

>Current parser understand the sentence and then match it with a key, I list
>all possible matching for each key and try to match the patterns.
>In the case above, I would build all patterns of combinations of, take and
>its synonyms, and all object currently in inventory.
>If you have three synonyms for take (grab, get, acquire) and five object in
>inventory, it will try to match 20 patterns and if it fails move on to the
>next key.

How do you avoid combinatorial explosions with your system?

For example, in PAWS I have about 35 verbs (not counting synonyms)
that deal with direct objects.

In Thief's Quest there are (currently) about 100 objects (things and
scenery). Are you saying in your system to completely handle
illogical/unlikely commands like "Climb Cloak" or "Taste Cloak" TQ
would need *3,500* keys?

And what about verbs that also handle *indirect* objects? Doesn't that
mean the 13 indirect object verbs in PAWS would generate an additional
(100*99)*13 = 128,700 keys, for a grand total of 132,200 keys?

Unless I misunderstand you, or there's a mechanism to provide default
responses, it seems the result would either be the parser not
understanding the command or performing an action that's likely to
bewilder the player.

In other words, how well does your parser technique scale? TQ is a
fairly large game, but the performance issue would seem to be
formidable

Respectfully,

Wolf

"The world is my home, it's just that some rooms are draftier than
others". -- Wolf

Ben A L Jemmett

unread,
Mar 10, 2002, 1:08:58 PM3/10/02
to
"Kevin Forchione" <ke...@lysseus.com> wrote in message
news:665b644a.02031...@posting.google.com...

> Infocom games came with instructions on what the player command syntax
> was, as part of the package of materials that usually provided
> background information.

The extract from a walkthrough from another (I think it was always
non-existent) game was a good way of showing what sort of interaction the
game supported; not as dry as a list of commands or words that were
understood, and still providing a bit of a 'I wonder if this will work'
aspect.

--
Regards,
Ben A L Jemmett.
(http://web.ukonline.co.uk/ben.jemmett/, http://www.deltasoft.com/)


CardinalT

unread,
Mar 10, 2002, 1:57:00 PM3/10/02
to

"Kodrik" <kod...@zc8.net> wrote in message
news:u8mf2vo...@corp.supernews.com...

> I'm saying it's not grammar interpration because the parser doesn't know
> the type of words and down't care to understand the sentence, he is just
> trying to find patterns in the sentence.

But that's what grammar is. It's the study of the rules of language, which
boils down to a study of the functions of different types of words and their
word order or positions within a sentence. The grammatist understands the
sequence <noun><verb><noun> in just the same way Inform's parser does.

> Current IF tries to understand the
> whole sentence, not just pattern matching, which is what I would be doing
> here in a more elaborate manner.

Well, it's true I've been away for awhile, so I may not be fully up on
current IF practices, but I have to tell you I can't see any way for a
parser to "understand" any arbitrary old sentence unless the programmer
painstakingly goes through and codes for it in advance.

> "take" {object in inventory} -> You already have $objectname
>
> If I write:
> Let's take the pretty cloak that is on the floor.
> It matches "take" and "cloak" as one of the inventory names and activates
> the key. It never breaks up the sentence gramatically.

Which is why I quarrelled with your claiming that your way of doing things
should be called "grammar interpretation." :) It shouldn't. It should be
called "direct symbol matching."

> Current parser understand the sentence and then match it with a key, I
list
> all possible matching for each key and try to match the patterns.
> In the case above, I would build all patterns of combinations of, take and
> its synonyms, and all object currently in inventory.
> If you have three synonyms for take (grab, get, acquire) and five object
in
> inventory, it will try to match 20 patterns and if it fails move on to the
> next key.

Ok, tell me if I've got this right.

The designer provides a "key" that "unlocks" a particular action. Thus, in
the example you've been using, the key "take" + "cloak" unlocks the action
that moves the cloak to the player's inventory. Ok, so now the player types
"take cloak." When you say above that you list all possible matchings for
each key, I'm taking you to mean that you now run through the object list to
see which objects have the key "take" + "cloak." Let's say there are two of
them, a red cloak and a blue cloak. Now, at this point you say you try to
"match the patterns." By that I'm taking you to mean that you go to your
synonyms table and pull out all the synonyms for "take" and "cloak" and then
run back through the object list to see if you can find any more matches
based on all possible synonymous combinations. Is that right?

If so, I'm afraid I don't quite see the significance of it. I mean, I think
I see how it works and all, but this still doesn't address the problems, or
shortcomings, that I and others here have pointed out.


CardinalT

unread,
Mar 10, 2002, 2:09:31 PM3/10/02
to

"Kodrik" <kod...@zc8.net> wrote in message
news:u8mfkq3...@corp.supernews.com...

>
> So far, it hasn't been an problem for users that the parser understands
> more than it should. I think it is better than understanding less or
> misleading the character like in Inform's Cloak of Darkness where you
> actually believe you have read the sawdust when you haven't.

I admit that most players are probably not going to try to type stupid or
false things--at least until they discover they can, at which point that's
*all* they'll probably want to type :) But leaving that aside, your system
has a certain potential for confusion here as well, and you just suggested
it.

What if the player thinks, for whatever reason, that burning the cloak will
have some positive benefit in the game? Might not your failure to trap the
attempt and respond to it with a failure message mislead the player into
thinking that he's just performed a successful action? Isn't that just as
potentially harmful and confusing as the Inform case you talked about?

> The major drawback is that the player might move on in the game by
accident
> sometimes rather than by wits.

I can see that potentially happening, although I don't really have a feel
for how likely it is. A player can luck onto the right keys under any
system, so I won't hold that against you unless it's just ridiculously
excessive :)


Derek F.

unread,
Mar 10, 2002, 2:53:49 PM3/10/02
to

"CardinalT" <card...@helpmejebus.com> wrote in message
news:3c8af...@corp-news.newsgroups.com...

> Andrew Plotkin wrote:
>
> > In many ways it's more important for the player to understand what the
> > parser understands, than for the parser to understand the player.
>
> I completely, 100% agree.
>

So instead of a prospective player having to learn IF's vernacular the hard
way, by trial and error, perhaps the game could teach the base mechanics by
way of a mini in-game tutorial. Something short, sweet, and to the point.
(Cloak of Darkness, perhaps?)

Bound by, say, raif consensus, such a tutorial could then be ported to each
language as a libary and included in any or all subsequent games (and could
of course be modified to include any game specific commands, such as
'diagnose'.)

Derek


Kodrik

unread,
Mar 10, 2002, 3:02:35 PM3/10/02
to
> In other words, how well does your parser technique scale? TQ is a
> fairly large game, but the performance issue would seem to be
> formidable

Well, there are two sets of keys, global keys that are always accounted for
and local keys that are accounted for only when an object is accessible.

The global keys are made to handle global responses:
>take {whatever}
You can't take that

It basically checks if the verb take is in the sentence, if it is, then it
outputs this appropriate message, "you can't take that" or whatever. This
key will be considered last so if other keys are active for "take cloak",
they will be considered first.

Then you have the global keys that affect objects in scope. So if the Cloak
is in a box, all the specific keys for cloak are not even considered, if
it's in the box, the "take cloak" key becomes active, if it's in inventoy,
the "wear cloak", "examine cloak" and "drop cloak" will be active.

There is no need for an "eat cloak" key because it can be handled by the
default responses of the system.

In a detailed room, you will probably have 500-1000 keys, including the
global ones.
In the complete game, it can be 100,000s.

But this is very little for a query to sort, in phpzork, when you look at
your log, it is querying a table of about 700,000 rows (all the players
logs) and it does it in a tenth of a second.

Kodrik

unread,
Mar 10, 2002, 3:09:30 PM3/10/02
to
> The game-playing public *does* understand restricted languages. It's a
> basic part of the "let's pretend..." psychology we all had as
> children. The failure of finding satisfaction in the gaming experience
> is a matter of managed expectations, of understanding the rules of
> engagement, the rules of the game.

But the less restrictive the language requirements the more pleasure for
the player. The argument, "it's better restricted" makes no sense.
The valid argument here :

Compared to grammar parsing, structure parsing understands less of the
meaning of the sentence, understand more than it should so it can result in
misapprorpriate actions, finally it understands more to activate actions in
the game.
There are positives and negatives, and someone like my wife will rather it
understands more and doesn't mislead than get more appropriate error
messages and understand less.

Kodrik

unread,
Mar 10, 2002, 3:27:08 PM3/10/02
to
> However, ask your
> wife to type in "remove the cloak that I'm not wearing." I'd be interested
> to hear her response after the game goes ahead and removes the cloak for
> her. Maybe she doesn't care--I don't want to anticipate her response for
> her--but I know I would have cared way back when if Zork had allowed
> something like that. I wouldn't have taken the parser seriously in that
> case, even as a rank newbie player with no pretensions whatsoever toward
> grasping the underlying programming.

Well, if someone types that, he is trying to trick the game. If the player
ask for things that don't make sense I don't think it is a big deal to
misintepret it. This is not a "trick the parser" adventure.
But you point is still valid, the player can enter a genuine request and
activate a key that has nothing to do with it:

>Don't attack the giant with the sword, use the torch instead
You attack the troll with the sword and it breaks on him, he eats you
whole. You should have used fire.
Yes, the player will be pissed but I think this will be rare enough (just
like the Inform "read the messages in sawdust") to repel someone. One think
it doesn't do, is mislead the player becaue the keys echo specific replie
to inputs.

> You may be right, but the player can't have his cake and eat it too. If he
> truly wants to play games that don't recognize commands for one object
> that they just a second ago understood for another then who can argue with
> that? But if the player wants to be able to type whatever in the world he
> wants to and have the computer actually *understand* it to boot--well,
> who's being unrealistic now? :)

The engine will never recognize everything the player types, and grammar
will always recognize more, but structure recognizes more correct commands
that affect the game actions.

> I don't see how your system eliminates the "guess the command" game. The
> player still has to type in something the parser recognizes, right?

Yes, but while a grammar parser would only recognize a few sentences to
pick up the cloak, the structure parser would recognize much much more so
the player will have to guess the command, but not the structure and
vocabulary of the command (or very little)

> I've seen some horribly
> written default messages that could have easily been fixed with just a
> little more forethought on the author's part.

Regardless of the parser, the author has a big responsibilities in making
his game understand the player.

> Believe me, I understand the problem. That's not why I'm arguing what I'm
> arguing. I simply think that unless you or me or someone else can come up
> with a way to let the player have his cake and eat it too, the "smart"
> parser approach ends up being the better, more popular approach among
> *players*. True, rank newbies or players-in-passing aren't going to
> gravitate to it, but I think those who perservere and become interested in
> the genre eventually become frustrated with the limitations of the "dumb"
> parser approach and end up consenting to the notion that they share a bit
> of the responsibility in learning how to play.

I think the grammar parser do a great job, the point I am trying to make to
this community is that structure parsers can be pretty good too and I don't
think the choice of an engine or a game to play will be because of the
parser type because they both do a good job, they both have their strengh
and weaknesses but they both allow a good gameplay for the player.

Kodrik

unread,
Mar 10, 2002, 3:32:23 PM3/10/02
to
> Understanding general English is too difficult a problem and won't be
> solved in any IF engine anytime soon.

Not understanding english, associating complex player inputs with correct
keys with a good success rate. Understanding English is a formidable task
that is best handled by IBM.
I do think existing parser will incorporate ignoring unknown words to a
larger extent so more input can be accepted. The drawback is that some
unvoluntary actions may be triggered but it is a worthwhile tradeoff from
my perspective.

Mark W

unread,
Mar 10, 2002, 3:56:48 PM3/10/02
to
"Derek F." <dfe...@yahoo.com> wrote in
news:a6gdm9$ea4m3$1...@ID-124731.news.dfncis.de:

> So instead of a prospective player having to learn IF's vernacular the
> hard way, by trial and error, perhaps the game could teach the base
> mechanics by way of a mini in-game tutorial. Something short, sweet,
> and to the point. (Cloak of Darkness, perhaps?)

I'm still having a hard time grasping what's so difficult about verb/noun
pairs? Leave out adjectives except when there are two similar objects, and
state your action as a verb/object pair with an implied subject of "I" or
"you."

Mark

Mark W

unread,
Mar 10, 2002, 4:01:19 PM3/10/02
to
Kodrik <kod...@zc8.net> wrote in news:u8nh0mn...@corp.supernews.com:

> I do think existing parser will incorporate ignoring unknown words to
> a larger extent so more input can be accepted. The drawback is that
> some unvoluntary actions may be triggered but it is a worthwhile
> tradeoff from my perspective.

I couldn't disagree more. I would rather have a game tell me that it didn't
understand me than do something I didn't want it to do. I HATE when games
do that.

Have you ever played a game that showed you your options, and you clicked
on something and your character did something that didn't make any sense? I
believe the X-Files game is an example of this. You're walking around
asking questions, click on an icon and insult the person you're talking to.
Why didn't it ask a question about that object? WHY? STUPID STUPID STUPID.
If I can't control my own character's actions, what's the point of me
playing?

Mark

Kodrik

unread,
Mar 10, 2002, 4:22:03 PM3/10/02
to
Mark W wrote:

Regardless of the engine, the authors have set some path and not covering
every possible things you would want to do. So you'll get very frustrated
that you can't do things that seem obvious.
So you will eventually have to follow one of the path of the author, and
sometimes, it will happen because of misintepretation instead of displaying
an error that you can't do it, but this is as unusual as the Inform Cloak
error that I doubt it will be a major issue.
The author will have a lot to do in how well the commands are understood.

Jon Zeppieri

unread,
Mar 10, 2002, 4:29:51 PM3/10/02
to
russ...@grace.speakeasy.net (Matthew Russotto) wrote in message news:<u8n0rs9...@corp.supernews.com>...

> Understanding general English is too difficult a problem and won't be
> solved in any IF engine anytime soon.

Not only that, but what would we *do* with a parser that could perform
a good semantic analysis of English? Would we build games that try to
offer reasonable responses to any input that is meaningful? Good
luck.

Someone is probably going to say that we could have an AI narrator, or
something like that. But when I write a story, *I* want to be in
control of the narrative, thank you very much. Writing an AI that
could tell a good story would be a great technical achievement, but
the artistic achievement would be the AI's, not the programmer's.

Mark W

unread,
Mar 10, 2002, 4:59:13 PM3/10/02
to
jalf...@yahoo.com (Jon Zeppieri) wrote in
news:4edb3231.02031...@posting.google.com:

<rambling>

Perhaps if we had a sophisticated enough parser with a huge and growing
library of objects, you could create a really sophisticated game world with
relatively little effort. I'm thinking along the lines of a MUD, but much
much more than that.

For example, let's say your character lives in an apartment. That apartment
would have rooms and objects, obviously. The interesting thing is, your
character went to the store to buy a toaster and brought it home. The same
with your phone system, and you had your phone turned on. Other players can
call you and have discussions with you. You get on the bus to go to the
museum.

If we were to go through with the effort to develop a really really
sophisticated parser that understood speech, could be added onto to
understand slang (and if you went to Harlem you'd hear people talking in a
different way than if you went to Carnegie Hall, and the parser understood
both because people too the time out to define both). Then you might as
well put that effort into creating a more convincing game world.

STORE
>buy bread
You buy the loaf of Blunder Bread. You get change of a ten dollar bill and
how have a five, three singles, and eighty nine cents.

HOME
>toast bread
How much bread?
>enough for a peanut butter and jelly sandwich
You get two slices of bread and put them into your Select-O-Matic toaster.
You put the rest back into the fridge. A few moments later your toaster
DINGS and your toast pops up.
>Make Peanut Butter and Jelly sandwich

etc.

This is a rather mundane example, but if we had a library of objects and a
significantly intelligent parser, robust dictionary of words, etc. It would

a) lower learning curve for players
b) remove some of the obstacles for programmers (endless streams of "how do
I create a car" posts would be solved by adding cars to the library)
c) create realistic worlds
d) let game developers focus on story rather than mechanics (similar to
"Unlimited Adventures" and Advent, I guess)

I think something like this is within the realm of possibility, and I think
the brainpower on RAIF is significant enough to accomplish this.... Enough
people would have to want to, so I don't think it's going to happen.

</rambling>
Mark

Mark W

unread,
Mar 10, 2002, 5:05:22 PM3/10/02
to
Kodrik <kod...@zc8.net> wrote in news:u8nju1r...@corp.supernews.com:

> Regardless of the engine, the authors have set some path and not
> covering every possible things you would want to do. So you'll get
> very frustrated that you can't do things that seem obvious.

I regularly encounter frustration at believing I know what to do, but not
being able to tell the parser how to do it because I don't have the psychic
ability to know the exact syntax the author wanted me to use.

Occasionally this gets bad enough for me to put the game down entirely, but
usually it just means I go online and look up a walkthrough (if one is
available) and find out that my idea was completely wrong anyway.

> The author will have a lot to do in how well the commands are
> understood.

Doesn't this put a lot of work onto the author to think as dozens of
players and solve his puzzle from dozens of points of view?

Mark

CardinalT

unread,
Mar 10, 2002, 6:02:43 PM3/10/02
to

"Kodrik" <kod...@zc8.net> wrote in message
news:u8ngms2...@corp.supernews.com...

> > I don't see how your system eliminates the "guess the command" game. The
> > player still has to type in something the parser recognizes, right?
>
> Yes, but while a grammar parser would only recognize a few sentences to
> pick up the cloak, the structure parser would recognize much much more so
> the player will have to guess the command, but not the structure and
> vocabulary of the command (or very little)

I don't think you're being entirely fair to the grammar parsers here.
They're designed to be easy, flexible, and to reduce the workload of the
designer as much as possible, but if someone wanted to put in the effort he
could make his grammar parser understand a lot more than it currently does.

> I think the grammar parser do a great job, the point I am trying to make
to
> this community is that structure parsers can be pretty good too and I
don't
> think the choice of an engine or a game to play will be because of the
> parser type because they both do a good job, they both have their strengh
> and weaknesses but they both allow a good gameplay for the player.

I agree, and I will repeat: there's a lot to recommend your parser. For
smaller games it's particularly attractive.


Kodrik

unread,
Mar 10, 2002, 6:09:27 PM3/10/02
to
> I regularly encounter frustration at believing I know what to do, but not
> being able to tell the parser how to do it because I don't have the
> psychic ability to know the exact syntax the author wanted me to use.

So you understand the value for the parser to be able to understand more.

> Doesn't this put a lot of work onto the author to think as dozens of
> players and solve his puzzle from dozens of points of view?

Yes it does and that's why I am developing tools for authors to have their
games tested as they are being developed as well as enhancing productive
dialogs between the testers and the authors.
I am testing this right now and it helps design a game tremendously, I
think to the point that the testers end up being co-authors and push the
game way beyond its original scope.

The author mustn't be alone in thinking, he offers the base, does the code
work and group brainstorms and tests from different directions.
It has the potential of allowing the creation of great complex games in
short times if the group is good.

I haven't found a practical way to allow mutliple authors actually coding
the same file, it brings more troubles than advantages.

But one coder and many brains with the proper tools to communicate works
great.

Adam Thornton

unread,
Mar 10, 2002, 8:31:38 PM3/10/02
to
In article <29Mi8.18479$N7.41...@ruti.visi.com>,

David Thornley <thor...@visi.com> wrote:
>I think the answer here is "don't do that". No author is forced to
>make pots indistinguishable only by what room they were found in.
>There are limitations to this medium, and sometimes the best thing
>to do is to live with them.

And, let's face it, this is a limitation with real life. If I have
three identical glasses, I probably mean to treat them as a set. And if
I leave one in the living room and one in the kitchen, and then they
each get moved four or five times, and then I stick them in the
dishwasher, I'm no longer going to know when I get them out which one
came from the kitchen and which from the living room. Fortunately for
me, I don't care.

Adam

L. Ross Raszewski

unread,
Mar 10, 2002, 10:42:30 PM3/10/02
to
On Sat, 9 Mar 2002 18:46:51 +0000 (UTC), Andrew Plotkin
<erky...@eblong.com> wrote:
>> In many ways I like the idea of the parser simply ignoring words it
>> considers extraneous. But it seems like that method has the potential for
>> confusing the player as well (if what I've said here is true).
>
>I think I've *used* a parser that ignored words like that -- no, I
>don't remember where, it was a while ago -- and indeed, it *was*
>confusing.
>
>In many ways it's more important for the player to understand what the
>parser understands, than for the parser to understand the player.
>

If mermory serves, isn't there an inform standard library patch to do
just this? IIRC, its touted praise was that it allowed the player to
freely use prepositions such as >TAKE THAT ZORKMID OVER YONDER

Kodrik

unread,
Mar 10, 2002, 11:49:22 PM3/10/02
to
> If mermory serves, isn't there an inform standard library patch to do
> just this? IIRC, its touted praise was that it allowed the player to
> freely use prepositions such as >TAKE THAT ZORKMID OVER YONDER

I am convinced that Infrom as well as tads, if they don't handle it
already, will offer the authors smart options to freely use preposition as
well as ignore words in different and intelligent ways. Like many features,
it add benefits and flaws, and it is my opinion that the benefits to do
this outweight the problems.

CardinalT

unread,
Mar 11, 2002, 2:36:24 AM3/11/02
to
Kodrik wrote:

> Well, there are two sets of keys, global keys that are always accounted
> for and local keys that are accounted for only when an object is
> accessible.
>
> The global keys are made to handle global responses:
>>take {whatever}
> You can't take that
>
> It basically checks if the verb take is in the sentence, if it is, then it
> outputs this appropriate message, "you can't take that" or whatever. This
> key will be considered last so if other keys are active for "take cloak",
> they will be considered first.

The only problem here is that (correct me if I'm wrong) your system can't
distinguish one type of object from another, so the default response has to
cover the entire gamut of game objects.

For instance, in Hugo or Inform you might see something like this:

verb "wear"
* DoVague
* clothing DoWearClothing
* object DoWearOtherStuff

Now, when the parser finds a potential match, it checks to see whether the
object has the attribute "clothing." If it does, it executes one routine.
If it doesn't, it executes another.

My understanding is that your system can't do that. Is that right? Or is
their some way of "typing" objects?

Because if you'd make your system do that so that we could provide
customized error messages, you'd remove a huge hurdle that currently stands
in the way of the adoption of your system.

Magnus Olsson

unread,
Mar 11, 2002, 4:36:31 AM3/11/02
to
In article <u8m20ls...@corp.supernews.com>, Kodrik <kod...@zc8.net> wrote:
>CardinalT wrote:

>
>> Andrew Plotkin wrote:
>>
>>> In many ways it's more important for the player to understand what the
>>> parser understands, than for the parser to understand the player.
>>
>> I completely, 100% agree.
>>
>
>Like you, I don't mind adapting my speech for Zork to understand my inputs
>but believe me it is a major issue with a lot of people.

>
>My wife, for example, wants to type in english full sentences with many
>useless words, she can't play the inform cloak of darkness because she
>wants to type in english:
>"Remove the cloak that I am wearing"
>"Hang the cloak on that hook"
>"Read the message inscribed in the sawdust"
>And from the feedback from phpzork, she is far from being alone.

I think this is one of the major problems with IF:

Since the game apparently uses natural English, and addresses the player
in full sentences, the player is led to expect that the parser will
accept commands in natural English. Which it doesn't, of course.

And the situation is aggravated by the fact that we authors tend to
downplay this difficulty, in effect telling users that they can type
commands in English.

>It is hard for us programmers to understand that because we naturally
>follow strict language but it is not the case for the general public.

Yes, programmers are used to the formal language accepted by command
interpreters and will quickly pick up "Informese" or whatever you call
it. People who aren't computer literate, or who have never used anything
but a point-and-click interface are likely to have difficulties.

This is of course a problem with all conversational interfaces, but
they have gone out of fashion in all areas except IF, it seems.

What can we do about this? Better parsers that actually understand
commands like "examine the jewel that I found in the blue room" are
the easy part - because understanding such a sentence would require
understanding it on a semantic level, and the necessary augmentations
of the world model. In this case, keeping track of where every object
in the game was first found may not seem like a huge task - but what
if we want to accept commands like "drop the gem that I used to cut
the glass five turns ago"?

I think users must be taught to speak Informese, as it were - but the
best way of teaching that seems to be through playing games. And if
the Informese is a big hurdle in playing the games...


--
Magnus Olsson (m...@df.lth.se, m...@pobox.com)
------ http://www.pobox.com/~mol ------

Kodrik

unread,
Mar 11, 2002, 4:33:40 AM3/11/02
to
> Because if you'd make your system do that so that we could provide
> customized error messages, you'd remove a huge hurdle that currently
> stands in the way of the adoption of your system.

Yes, and just offering library keys is not enough, it will still be too
cumbersome for the author.

I've bnthinking about it since your other post, auhtors should be able to
define universal objects wth all keys and be able to associate universal
"powers" such as "light", "fire", "attack", that they can also define.

This way, once an author created a door with with all it's possible keys
and combinations, open, go though, "burnt down with the power fire"...
Other authors will just have to import these to have fully functiional
objects.
He could also create a group of objects (door/key) in the universal library
and then the author just has to place them wherever he wants.

It will take some time and some pioneer dedicated authors to build the
librairies but it will be well worth it in the long run.

These converations on raif are much more rewardng than I expected, I think
I will make my engine public to the raif pretty soon, even if it is
unfinished, because the interaction generated here can really make a
difference. I'll probably announce it on April 1st or April 13th (my
birthday).

So far, I've been basing myself on a few authors using it and general
discussions on IF as well as engine-specific discussions. But my engine has
too many particularities to limit my input this way if I do want to take a
wrong turn in future development.

Kodrik

unread,
Mar 11, 2002, 4:38:03 AM3/11/02
to
> What can we do about this? Better parsers that actually understand
> commands like "examine the jewel that I found in the blue room" are
> the easy part - because understanding such a sentence would require
> understanding it on a semantic level, and the necessary augmentations
> of the world model. In this case, keeping track of where every object
> in the game was first found may not seem like a huge task - but what
> if we want to accept commands like "drop the gem that I used to cut
> the glass five turns ago"?

I think accepting inputs that are still only refering to the direct object
used but more freely written, would be a big first step.

Put the cloak that sucks darkness on the hook that I see on the wall.

Grammatically, it could be done:
Verb -> put
direct object -> cloak
location object -> on the hook

We have a match without ambiguity, let's ignore the rest and accept it.

Magnus Olsson

unread,
Mar 11, 2002, 7:37:28 AM3/11/02
to
In article <3c8b4...@corp-news.newsgroups.com>,

CardinalT <card...@helpmejebus.com> wrote:
>However, ask your
>wife to type in "remove the cloak that I'm not wearing." I'd be interested
>to hear her response after the game goes ahead and removes the cloak for
>her. Maybe she doesn't care--I don't want to anticipate her response for
>her--but I know I would have cared way back when if Zork had allowed
>something like that. I wouldn't have taken the parser seriously in that
>case, even as a rank newbie player with no pretensions whatsoever toward
>grasping the underlying programming.

I think the problem that Kodrik's wife and lots of other newcomers
to IF have is that what seems to be a natural-language interface
really isn't; the game sets up expectations that it can't deliver on.

In other words, the problem is that the player expects the parser
to understand more than it actually does.

From that perspective, I think Kodrik's proposed solution looks to be
a step in the wrong direction: instead of giving error messages when
the player types something that the parser doesn't recognize, it
just *pretends* that it understands, while in reality it may have
misunderstood the player's intentions completely.

To distinguish between cases like
"Wear the hat that I'm carrying"
and
"Wear the hat that I'm not carrying"

or to handle a command like

"Ask the wizard which gate is safe to open and which is booby-trapped"

requires a rather sophisticated level of semantic understanding on
the part of the program - a level of understanding that today belongs
in AI research projects.

A parser that merely pretends to understand commands like this,
and gets it right at some times and wrong at others, is bound
to confuse the player immensely. "But it understood when I asked the
troll to go back and pick up the hat that I'd left in the bar - why
doesn't it understand me now?"

Anyway, I don't think it's much use debating this issue now, without
any actual game that works this way. If Kodrik finishes his game,
we can all have a go at the parser, and see if it's confusing or not.

Lucian P. Smith

unread,
Mar 11, 2002, 9:25:44 AM3/11/02
to
Kodrik <kod...@zc8.net> wrote in <u8m20ls...@corp.supernews.com>:

: CardinalT wrote:

:> Andrew Plotkin wrote:

:>> In many ways it's more important for the player to understand what the
:>> parser understands, than for the parser to understand the player.

:> I completely, 100% agree.

: Like you, I don't mind adapting my speech for Zork to understand my inputs
: but believe me it is a major issue with a lot of people.

: My wife, for example, wants to type in english full sentences with many
: useless words, she can't play the inform cloak of darkness because she
: wants to type in english:
: "Remove the cloak that I am wearing"
: "Hang the cloak on that hook"
: "Read the message inscribed in the sawdust"
: And from the feedback from phpzork, she is far from being alone.

OK, there's a very simple method here of satisfying both camps.

When the parser has to make an educated guess about what the player typed,
*tell the player what you guessed*. It's really that easy.

-----
>REMOVE THE CLOAK THAT I AM WEARING
(Assuming you mean: >REMOVE THE CLOAK)

You take off the cloak.
-----

Not only will this let the player do what they wanted most of the time, it
also starts teaching them what kinds of inputs it's more likely to
correctly interpret. Feedback. It's all about feedback.

In general, the Inform parser is pretty good about this, but the main
difference is that if Inform doesn't have at least a good guess about what
each and every word means, it fails. On a system without 'undo', this is
important. But are there any platforms left that don't?

In contrast, when the parser makes a 'best guess' about what the player
means, it will inform the player that it's making that assumption.

-----
>COOK
(the meat)

The meat simmers and turns brown.
-----

Perhaps unfortunately, the Inform error message 'I only understood you as
far as _____' is probably confusing to newbies, because it can be hard to
see where in the sentence the parser gave up:

-----
>REMOVE THE CLOAK THAT I AM WEARING THEN GO NORTH

I only understood you as far as wanting to remove the cloak.
-----

Where did the parser give up? The veteran understands that it gave up at
'that'. The newbie would logically deduce it gave up at 'then'. The
parser is aiming for English here, but as I think 'Winchester's Nightmare'
amply demonstrated, the player doesn't *want* the parser to speak in
english. The parser is separate from the story; it's there for
information and feedback. What about the more awkward-sounding but more
informative:

-----
>REMOVE THE CLOAK THAT I AM WEARING THEN GO NORTH

I only understood you as far as '>REMOVE THE CLOAK'.
-----

Using Kodrik's parser and my proposed feedback mechanism, the parser would
then go ahead and perform the bit that it understood, as a courtesy to the
player so they didn't have to re-type their sentence. As long as the
player is made aware of what's going on, I have no problem with this.

-Lucian

Magnus Olsson

unread,
Mar 11, 2002, 10:22:33 AM3/11/02
to
In article <a6iep8$os4$1...@joe.rice.edu>,

Lucian P. Smith <lps...@rice.edu> wrote:
>OK, there's a very simple method here of satisfying both camps.
>
>When the parser has to make an educated guess about what the player typed,
>*tell the player what you guessed*. It's really that easy.
>
>-----
>>REMOVE THE CLOAK THAT I AM WEARING
>(Assuming you mean: >REMOVE THE CLOAK)
>
>You take off the cloak.

This is a very good idea. I'm not sure it solves all the problems - I
think there may still be a problem with the player's not being able to
predict beforehand exactly how a command will be parsed - but at least
the player isn't led to believe that the parser understands more than
it does.

>>REMOVE THE CLOAK THAT I AM WEARING THEN GO NORTH
>
>I only understood you as far as wanting to remove the cloak.
>-----
>
>Where did the parser give up? The veteran understands that it gave up at
>'that'. The newbie would logically deduce it gave up at 'then'.

Not only newbies have problems with this particular error message -
I've been misled by it many times.

>What about the more awkward-sounding but more
>informative:
>
>-----
>>REMOVE THE CLOAK THAT I AM WEARING THEN GO NORTH
>
>I only understood you as far as '>REMOVE THE CLOAK'.

Or what about

"I didn't understand 'THAT I AM WEARING THEN GO NORTH'" which tells
you exactly what the parser didn't understand?

Kodrik

unread,
Mar 11, 2002, 2:59:50 PM3/11/02
to
>>REMOVE THE CLOAK THAT I AM WEARING
> (Assuming you mean: >REMOVE THE CLOAK)
>
> You take off the cloak.

That's a very good idea and I think I have an easy way to implement it.

The engine displays the last 5 commands entered
>go north->look at troll->grab the sword->run the sword through the troll

Instead it could display the last 5 pattern matches
->go north->look troll->grab sword->sword troll

It will better because 5 long commands screw up the layout and it will give
the feedback you suggest.

David Thornley

unread,
Mar 11, 2002, 3:05:46 PM3/11/02
to
In article <a6h1dq$7h$1...@news.fsf.net>, Adam Thornton <ad...@fsf.net> wrote:
>In article <29Mi8.18479$N7.41...@ruti.visi.com>,

>
>And, let's face it, this is a limitation with real life. If I have
>three identical glasses, I probably mean to treat them as a set. And if
>I leave one in the living room and one in the kitchen, and then they
>each get moved four or five times, and then I stick them in the
>dishwasher, I'm no longer going to know when I get them out which one
>came from the kitchen and which from the living room. Fortunately for
>me, I don't care.
>
In real life, there sometimes are special circumstances in which one
would care, and then one would make some extra differentiation.

For example (according to years of reading murder mysteries and such),
at a crime scene the police would want to know that this glass was
on the table near the corpse, while that one was on the other table.
In that case, they'd pour out any contents into separate containers,
check the glasses individually for fingerprints, and then put everything
into appropriately marked bags.

>GET GLASS
Which glass, the one in bag 32 or the one in bag 86?
>LOOK UP 86 IN CRIME SCENE REPORT
Bag 86: One glass, containing remnants of cocktail (see bag 121),
found on SE end table, near corpse.
>GET GLASS 32
You take bag 32.


--
David H. Thornley | If you want my opinion, ask.
da...@thornley.net | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-

Lewis Raszewski

unread,
Mar 11, 2002, 4:37:42 PM3/11/02
to

The trouble is that you're fast approaching the natural language
problem. When you start accepting words you don't understand, you run
the risk that:

>TAKE THE POTS, IGNORING THOSE INSIDE THE HORRIBLE TRAP

[Matched: 'take' 'pots' 'inside' 'trap']

You spring the horrible trap, and are trapped, horribly.


--
L. Ross Raszewski
The Johns Hopkins University
Wyman Park 407

"Time is an illusion. Lunchtime, doubly so." -- Douglas Adams, The
Hitch-Hiker's guide to the Galaxy, episode 1

Kodrik

unread,
Mar 11, 2002, 4:53:00 PM3/11/02
to
> The trouble is that you're fast approaching the natural language
> problem. When you start accepting words you don't understand, you run
> the risk that:
>
>>TAKE THE POTS, IGNORING THOSE INSIDE THE HORRIBLE TRAP
>
> [Matched: 'take' 'pots' 'inside' 'trap']
>
> You spring the horrible trap, and are trapped, horribly.

The goal for the parser is to support the honest player that is playing
your game in his word.

If you play a game without the purpose to beat the parser, you'll see that
this will be a very rare occurrence.

The player who speaks english usually insert useless speach:
"Read the message in the sawdust." (it's the only message so the player
doesn't need to specify the location, but he does anyway)

If there are two messages: wall & sawdust then the author must
differientiate between them with these words.

Of course, if the player says:
Read the message that is not on the wall, it will read the message on the
wall instead of the sawdust.

But an honest player who is not trying to play beat the parser will say
"read the message that is written in the sawdust".

The player has to be straight forward in his commands, which an honest
player is, but should not have to be restricted on his choice of words for
this command.

EPerson

unread,
Mar 11, 2002, 5:51:07 PM3/11/02