Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Making a parser - what are the minimal requirements?

1,792 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
to
> 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.

So is there going to be an "assuming you mean" message every time
there is thrown-out input? This "natural English parser" has to tell
the player that it made an assumption every time it gets natural
English. I, for one, do not want a parser to assume something on 90%
of all input.

Lucian P. Smith

unread,
Mar 11, 2002, 5:54:41 PM3/11/02
to
Magnus Olsson <m...@df.lth.se> wrote in <a6ii3p$66f$1...@news.lth.se>:
: In article <a6iep8$os4$1...@joe.rice.edu>,

: Lucian P. Smith <lps...@rice.edu> wrote:

:>>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?

I'm inclined to think that repeating the bit that the player got right is
better than repeating the bit that the player got wrong. You are,
essentially, teaching the player how to speak parser-ese. I'm pretty sure
it's been established that people respond better to being told what they
got right than being told where they messed up. You'd need to do some
user testing to say for certain, though.

Anyone up for posting an Inform library patch that does this? Or
hey--Michael, if you're listening, what's the T3 library going to say in
this situation?

-Lucian

Kodrik

unread,
Mar 11, 2002, 6:34:55 PM3/11/02
to
> So is there going to be an "assuming you mean" message every time
> there is thrown-out input? This "natural English parser" has to tell
> the player that it made an assumption every time it gets natural
> English. I, for one, do not want a parser to assume something on 90%
> of all input.

But it is very unusual for the parser to assume something wrong. Most of
the time, it will accurately respond or respond ni a guinding way:

You see bananas on the table
>take one banana
>you take all the bananas

You didn't do what you want but for the game proper development, you need
to take all the bananas.

Would you rather an error message
"You cannot take only one banana"
or
"You need to take all the bananas"
on your requests

I have purposely made wide interpretation in my game to guide the player in
a nice manner to follow the path of the game..

Authors don't code every possible actions and do have to guide you through
their story, this is a nice way of doing it.

And if you're not playing beat the parser, it will be extremelly rare for
the parser to assume an action to your detriment, and it wil usually be
because the author's design.

wo...@one.net

unread,
Mar 11, 2002, 7:16:25 PM3/11/02
to

Hi Kodrik,

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

{snip}

>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.

I think this is a dangerous assumption for a game author to make. Not
because players delight in tricking the parser but because the author
is going to make assumptions, the parser is going to make assumptions,
and the player will traipse innocently into disaster.

There is another danger. Once the player realizes the parser doesn't
"really" understand what they type their sense of memesis is going to
suffer. Sort of like:

"This room contains an a statue. There's an exit to the north and
west."

> Take Statue

"I don't see a statue here."

See? Once a player discovers the parser will ignore just about
anything they say, they're going to lose faith in it. I remember
coming off Advent and into Dungeo (Zork) for the PDP-11. The sense of
delight the parser generated was wonderful! It *understood me*.

That thrill is still there for new players. Let them discover the
parser doesn't "really" understand and they're going to be
disillusioned--and somewhat disappointed.

On the other hand there's nothing wrong with *selectively* ignoring
words. "A", "an", and "the" are generally safe to ignore. But ignoring
things wholesale just begs for the players not to ignore that man
behind the curtain...


Respectfully,

Wolf

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

Kodrik

unread,
Mar 11, 2002, 8:22:21 PM3/11/02
to
> "This room contains an a statue. There's an exit to the north and
> west."
>
>> Take Statue
>
> "I don't see a statue here."
>
> See? Once a player discovers the parser will ignore just about
> anything they say, they're going to lose faith in it. I remember
> coming off Advent and into Dungeo (Zork) for the PDP-11. The sense of
> delight the parser generated was wonderful! It *understood me*.

Why would it say, "I don't see a statue here", regardless of parser.
It should say "you can't take it" or something along those lines.

You can trick a parser, regardless of the parser, and it can lead to
disaster, my example with inform's COD is a perfect one.

But these are rare cases and it is the same with structure parsing. It's on
the dot most of the time, when it mistakes, it's usually in a good way and
puts you back on the path.

When it errs with negative consequences, it is extremelly rare and if it
happens, it is often due to an authors mistake.
I can honestly say that I haven't yet encountered a misintepretation with
negative consequences in playing a completed game done with my engine,
neither have the people testing them so far. That doesn't mean that there
aren't any, but these instances are so few and rare that they don't
discredit the parser. Most people played Inform's COD without encountering
the problem I had.

I can site a 100 examples where Inform's parser understanding will have
negative consequences, but in real games I will propbably never encounter
any of them if I am playing a well designed adventure honestly.

A structure parser will not have more likely hood of catastrophic result on
your gameplay. I do think most veteran IF won't like it because, until the
librairies are developed, the error messages will be too weak compared to
current engines.

Branko Collin

unread,
Mar 11, 2002, 9:31:59 PM3/11/02
to
"Lucian P. Smith" <lps...@rice.edu>, you wrote on 11 Mar 2002
22:54:41 GMT:

>Magnus Olsson <m...@df.lth.se> wrote in <a6ii3p$66f$1...@news.lth.se>:
>: In article <a6iep8$os4$1...@joe.rice.edu>,
>: Lucian P. Smith <lps...@rice.edu> wrote:
>
>:>>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?
>
>I'm inclined to think that repeating the bit that the player got right is
>better than repeating the bit that the player got wrong.

How do you do that without the player filling in the "THAT I AM
WEARING" bit himherself?

Magnus' solution has the advantage that the bit that was not
understood is faulty English. It sticks out.

--
branko collin
Volk van San Theodoros, ik heb U begrepen.

Lucian P. Smith

unread,
Mar 11, 2002, 11:04:12 PM3/11/02
to
I wrote:

:> >REMOVE THE CLOAK THAT I AM WEARING


:> (Assuming you mean: >REMOVE THE CLOAK)
:>
:> You take off the cloak.

EPerson <esch...@safeaccess.com> wrote in <6e5fc465.02031...@posting.google.com>:
: So is there going to be an "assuming you mean" message every time


: there is thrown-out input? This "natural English parser" has to tell
: the player that it made an assumption every time it gets natural
: English. I, for one, do not want a parser to assume something on 90%
: of all input.

Do you not want the parser assuming something, or do you not want the
parser *telling* you it has assumed something? This is an honest
question--I'm not sure which your mean (unless you mean both).

If the parser is making assumptions, I personally want to know about
it. Once I get the hang of it, I might want to be able to turn it off,
but I consider it an essential default.

-Lucian

Lucian P. Smith

unread,
Mar 11, 2002, 11:12:40 PM3/11/02
to
Branko Collin <col...@xs4all.nl> wrote in <3c8d65b5...@news.xs4all.nl>:
: "Lucian P. Smith" <lps...@rice.edu>, you wrote on 11 Mar 2002

:>: Or what about

Magnus' solution may well work better. But my instinct tells me that
reinforcing good behavior ('Remove the cloak' is good! I understood
that! Keep going!) is better than punishing bad behavior ('that I am
wearing'? Huh?). I just think the player is more likely to hit upon
recognized grammar more quickly more consistently while being told what
recognized grammar looks like than while being told what unrecognized
grammar looks like.

User testing, again, would tell us the answer.

-Lucian

Magnus Olsson

unread,
Mar 12, 2002, 5:08:39 AM3/12/02
to
In article <a6jv7o$7p3$2...@joe.rice.edu>,

The problem is that the parser may very well understand "that I am
wearing", but be stumped by "that I am wearing then go north".

Lucian P. Smith

unread,
Mar 12, 2002, 8:54:55 AM3/12/02
to
Magnus Olsson <m...@df.lth.se> wrote in <a6kk37$ktm$2...@news.lth.se>:
:>:>Magnus Olsson <m...@df.lth.se> wrote in <a6ii3p$66f$1...@news.lth.se>:

:>:>: In article <a6iep8$os4$1...@joe.rice.edu>,
:>:>: Lucian P. Smith <lps...@rice.edu> wrote:


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

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

vs.

:>:>: "I didn't understand 'THAT I AM WEARING THEN GO NORTH'"


: The problem is that the parser may very well understand "that I am


: wearing", but be stumped by "that I am wearing then go north".

*scratch head* You seem to be making my point for me. If the parser
can't work out which part of the mystery bit it doesn't understand, surely
it's safer to tell the player what it *does* understand than imply that it
doesn't understand any of the latter?

"I only understood you as far as '>REMOVE THE CLOAK'" implies "You
confused me in the second part. I understand this much--you can try just
that if you want." If it turns out that more clarification is needed,
just typing 'REMOVE THE CLOAK' will cause the parser to ask what it needs
("which do you mean, the cloak you're wearing or the one you have wrapped
around your head like a turban?")

""I didn't understand 'THAT I AM WEARING THEN GO NORTH'" implies "You
confused me in this second part. Try to rework it until I understand."
There's little to no guidance here, just "Wrong. Try again."

-Lucian

Lewis Raszewski

unread,
Mar 12, 2002, 3:29:51 PM3/12/02
to

Now, I'm not sure I understand why a newbie would type something like
this.

The claim has been made that newbies expect the parser to handle full
sentences in conversational english, and are confused when this doesn't
work. I find this a little hard to accept; I don't think anyone really
wants to use natural language with their game -- even if the parser
would accept it, I'd never type "pick up the brown box that's over there
on the table; my attention was drawn to it by the fact that it was
described in such detail in the room description" -- not because I'm
used to the telegraphic style of IF commands, but because it's a waste
of my time. I would think that even a newbie, when playing IF, would
want to communicate as briefly as possible, partly because typing is
some level of effort, partly because people are, by now, used to
computers not being able to understand natural language, but mostly
because there's no benefit to it.

The newbies I've introduced to IF recently did *not* try to say things
too complex for the parser to understand -- on the contrary, they tried
things too *simple*, issuing commands like "box" for the statement
above, for example.

(To qualify, I'll describe the two people I've most recently shown IF
to. The game, in both cases, was 'Moments out of Time' (the reason I
showed it to them being that they wanted to see this game I'd allegedly
written). The first was my mother, who had played IF before, but that
was fifteen years ago, well before the span of her memory, who is pretty
well computer illiterate. The other was a graduate student in computer
science with a very strong background in programming and computer
graphics. I was a little surprised that both approached the parser the
same way. I'm sort of curious how someone whose background was in
natural language processing would approach it -- I suspect that they'd
make the same kind of statements, "knowing better" than to expect the
game to respond to a conversational statement.)


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

"If I whisper, they will know; I'll just turn around and go; you will
never
know my sin." -- Melissa Etheridge, Angels Would Fall

Magnus Olsson

unread,
Mar 12, 2002, 4:13:21 PM3/12/02
to
In article <a6l1bf$6u2$2...@joe.rice.edu>,

Lucian P. Smith <lps...@rice.edu> wrote:
>Magnus Olsson <m...@df.lth.se> wrote in <a6kk37$ktm$2...@news.lth.se>:
>:>:>Magnus Olsson <m...@df.lth.se> wrote in <a6ii3p$66f$1...@news.lth.se>:
>:>:>: In article <a6iep8$os4$1...@joe.rice.edu>,
>:>:>: Lucian P. Smith <lps...@rice.edu> wrote:
>
>
>:>:>:>>REMOVE THE CLOAK THAT I AM WEARING THEN GO NORTH
>
>:>:>:>I only understood you as far as '>REMOVE THE CLOAK'.
>
>vs.
>
>:>:>: "I didn't understand 'THAT I AM WEARING THEN GO NORTH'"
>
>
>: The problem is that the parser may very well understand "that I am
>: wearing", but be stumped by "that I am wearing then go north".
>
>*scratch head* You seem to be making my point for me. If the parser
>can't work out which part of the mystery bit it doesn't understand, surely
>it's safer to tell the player what it *does* understand than imply that it
>doesn't understand any of the latter?

On second thought, I think this may be a matter of taste.

>"I only understood you as far as '>REMOVE THE CLOAK'" implies "You
>confused me in the second part. I understand this much--you can try just
>that if you want."

(...)

>""I didn't understand 'THAT I AM WEARING THEN GO NORTH'" implies "You
>confused me in this second part. Try to rework it until I understand."
>There's little to no guidance here, just "Wrong. Try again."

That's one way of seeing it. I'm not sure how actual users would
react. YMMV, I suppose.

What I don't like, however, is Inform's "I only understood you as
far as wanting to remove the cloak", i.e. a rewording of the original
command. In this case, it's pretty harmless, but I've seen cases
where it's been very confusing - "How could it possibly interpret
my command as wanting to do *that*?" - and it took me some reasoning
to understand that if the command is terminated at a certain
place, it can indeed be interpreted that way.

Kodrik

unread,
Mar 12, 2002, 4:13:06 PM3/12/02
to
> The claim has been made that newbies expect the parser to handle full
> sentences in conversational english, and are confused when this doesn't
> work. I find this a little hard to accept; I don't think anyone really
> wants to use natural language with their game -- even if the parser
> would accept it, I'd never type "pick up the brown box that's over there
> on the table; my attention was drawn to it by the fact that it was
> described in such detail in the room description" -- not because I'm
> used to the telegraphic style of IF commands, but because it's a waste
> of my time. I would think that even a newbie, when playing IF, would
> want to communicate as briefly as possible, partly because typing is
> some level of effort, partly because people are, by now, used to
> computers not being able to understand natural language, but mostly
> because there's no benefit to it.

Many times, I have to reword my sentence for the parser to understand, and
I'm sure it happen to you too.
For newbies or computer illiterate people, this is greatly amplified and
the more the parser understands, the better their playing experience.

I agree that most examples here are not what someone will type in a game
and that's why I've said I am not interested in supporting those inputs:
"Don't hit the troll with the cake, use the sword instead"

But I am interested in supporting inputs that someone is likely to type:
"Read the message from the sawdust"
and get the content of the message that tells me I win instead of:

>read message from the sawdust
(in the scrawled message)
You discover nothing of interest in the scrawled message.

This example is not that good because on most occasions Inform will give an
appropriate error message and that is not the point I am trying to make.
The point is that a request that makes sense doesn't activate the action it
should to make the game advance and the player doesn't advance in the game
as fast as he should.


Magnus Olsson

unread,
Mar 12, 2002, 4:20:03 PM3/12/02
to
In article <3C8E653F...@hotmail.com>,
Lewis Raszewski <rras...@hotmail.com> wrote:

>Magnus Olsson wrote:
>> >>REMOVE THE CLOAK THAT I AM WEARING THEN GO NORTH

(...)

>Now, I'm not sure I understand why a newbie would type something like
>this.

They probably wouldn't; the example is a bit contrived, I think, and
Kodrik has a point when he says that we shouldn't really expect the
players to type that kind of commands.

>The claim has been made that newbies expect the parser to handle full
>sentences in conversational english, and are confused when this doesn't
>work. I find this a little hard to accept; I don't think anyone really
>wants to use natural language with their game

IIRC, it was Kodrik who claimed that he'd seen people do this, and
that's what motivated him to design a different kind of parser.

Personally, I think new players rather quickly fall into a
"telegraphic" mode, but they can still be likely to be stumped by the
parser, perhaps not so much because they type long, complicated
sentences, but because they haven't seen the pattern in what the
game accepts.

I think a good example is "go to the kitchen" - most games simply
don't support this kind of command, even though it's easy to
parse. And even veteran players sometimes get frustrated because they
can't "ask detective who killed roger ackroyd".

So, yes, you have a point: the killer is not that the parser can't
parse very complicated sentences, but that the game only accepts
certain types of commands.

Lewis Raszewski

unread,
Mar 12, 2002, 5:00:58 PM3/12/02
to

As in
>TAKE UP SMOKING

I only understood you as far as wanting to take the ceiling.


--
L. Ross Raszewski
The Johns Hopkins University

Wyman Park 407> --

"A V.I.L.E. henchman -- You must be on the right track!" -- Where in the
World
is Carmen Sandiego?

EPerson

unread,
Mar 12, 2002, 6:10:57 PM3/12/02
to
"Lucian P. Smith" <lps...@rice.edu> wrote in message news:<a6juns$7p3$1...@joe.rice.edu>...

Both are fine, as long as they don't occur too often. I definately
would want to be told about assumptions. One problem with this kind of
business is that once the player realizes the parser ignores all those
extra phrases and clauses, he won't bother to add them in, the same as
if the parser said things like, "I only understood 'TAKE THE CLOAK'."
Perhaps a resolution is to allow the parser to understand descriptors
like "wearing" and "worn." If it encounters them, it tries to match it
to the objects refered to too. (Except, from what I can tell, there
are no object references, just certain words in certain orders causing
certain code to be run.")

Eric Schmidt, The F-iest

Daryl McCullough

unread,
Mar 12, 2002, 6:10:14 PM3/12/02
to
Lewis says...

>>TAKE UP SMOKING
>
>I only understood you as far as wanting to take the ceiling.

Something that's more likely to come up (I typed
it once in a Zarf game):

>give up
(to yourself)
(first taking the ceiling)
That isn't available.

--
Daryl McCullough
CoGenTex, Inc.
Ithaca, NY

Mike Roberts

unread,
Mar 12, 2002, 6:42:18 PM3/12/02
to
Magnus Olsson <m...@df.lth.se> wrote:
> So, yes, you have a point: the killer is not that the parser
> can't parse very complicated sentences, but that the game
> only accepts certain types of commands.

I quite agree - and this can't be solved by adding more commands. It always
seems like a red herring to me when people argue about how "natural" the
command language ought to be, because in my experience, what really seems to
trip up novice players isn't the parser but the idiosyncratic, and fairly
shallow, world model.

I'm sure that experienced players benefit from familiarity with the
relatively consistent parsing conventions that modern games use, but I think
they benefit even more from having internalized the world model conventions:
the world is a graph of location nodes, the only spatial relationship among
objects is containment, objects are discrete and indivisible except where
otherwise noted, many things are not modeled at all or are modeled only as
scenery, keys made of a particular kind of metal unlock doors made of the
same type of metal (wait, I think I'm straying from conventions into
cliches). These conventions are pretty unnatural to the uninitiated, who
want to envision scenes in 3-space, move around within a room, move things
around within a room, manipulate the parts of things that would always be
there in the real world, and have actual conversations with NPC's.

The mismatch between the novice player's expectations of the world model and
the actual world model cannot be addressed with parsing. A fully
human-level AI parser could help explain things to a novice player the same
way the author can when sitting next to the player watching the game, by
understanding how the player is misconceiving the simulation and describing
the actual world model; but if we could create a parser that understood
things this well, we'd surely also be able to create a more natural world
model, and we wouldn't relegate the parser to training the user on the one
we use now.

I think this level of AI is (1) theoretically possible, and (2) not remotely
within my technical abilities to create. I am skeptical to the point of
being dismissive of claims for "simulated AI" that uses smoke and mirrors to
fool people into thinking that a machine is smart, because I've seen this
claim so incredibly many times, and every time it's just junk. I'm even
more dismissive when someone says, sure, it can't fool you smart programmer
types, but it can fool the computer-illiterate, because it is my experience
that the computer-illiterate are the harshest judges of machine
intelligence.

This is why I think it's more important, if you care about novice players,
to make the parser simpler, not more complicated. I think a novice player
is going to have a much more satisfying experience if you can hand him or
her a short list of all of the command phrasing that they could possibly
need to play the game, and tell them that if they get stuck, they should
just remember that they never need any commands but those on the list. All
of the fancy stuff that modern parsers do is for the benefit of experienced
players, to save them keystrokes.

--Mike

Kodrik

unread,
Mar 12, 2002, 6:57:11 PM3/12/02
to
> (Except, from what I can tell, there
> are no object references, just certain words in certain orders causing
> certain code to be run.")

Whether or not the keys are listening depends on the state of the game.

If player has cloak:
1: "x" "cloak" -> It's a pretty black cloak
100: "cloak" -> what about the cloak?
1000: "" -> "Sorry, I don't understand"

If cloak is worn:
1: "wear" "cloak" -> You already have it on
1: "remove" "cloak" -> You remove the cloak
1: "drop" "cloak" -> You need to remove it first

IF cloak is in possession
10: "wear cloak" -> you wear the cloak
10: "remove" "cloak" -> You already have the cloak
10: "drop" "cloak" -> You drop the cloak

The numbers in front are for ordering the matches. When the cloak is worn,
it is equiped. We could make the last keys requirement "when equiped and
not worn" but ordering them after the worn keys is enough since the other
ones will have precedence.

When I they will be a library clothing, you import the shirt in your game,
rename it to cloak, associate synonyms to your new names if any, and voila,
all the keys will work.
If you want your shirt to be part of game specific actions, you'll just add
a command "cloak" "hook" to hand the cloak when in the cloakroom, equiped
but not worn.

So there are more than object references, whether a key is accounted by the
parser can depend on the state of almost anything in the game or any
combination of states.

Kodrik

unread,
Mar 12, 2002, 7:20:56 PM3/12/02
to
> This is why I think it's more important, if you care about novice players,
> to make the parser simpler, not more complicated.  I think a novice player
> is going to have a much more satisfying experience if you can hand him or
> her a short list of all of the command phrasing that they could possibly
> need to play the game, and tell them that if they get stuck, they should
> just remember that they never need any commands but those on the list

I agree and current parsers handle it fine and so does mine (although
without good librairies, it will not).

The reasons I chose this route for my parser are not because of faults I
saw in current parsers.

It was important to me to have the following features:
* User can type his commands and activate a key.
* For some interfaces, the user can build his orders from pop-up menus
instead of typing them.
* For some interfaces, the user is able to navigate the game by
clicking on the various commands available.
* The parser can easily handle voice recognition for user input.
All this without asking the author to customize the way he creates his
adventures for different interfaces.

So naturally, I went with structure pasrsing. When I started, there was no
question it would be weaker than grammar parsing but these goal were very
important for the purpose of my engine.

After I put a very basic structure parser and a few rooms together to
explore, I asked my wife who can't stand Zork to try it. To my suprise, she
was very comfortable with it and the parser responded beyond my
expectations. I have improved upon it greatly and as you can see from our
discussion here, there is still a lot of room for realistic imporvements.

Now, I am convinced that a structure parser will not negatively affect the
playing of the average player and it will not be a criteria of good/bad
game. It has its advantages and disadvantages, like grammar parsers, but
like grammar parsers, it does its job well enough for good gameplay.

Branko Collin

unread,
Mar 12, 2002, 8:33:32 PM3/12/02
to
Lewis Raszewski <rras...@hotmail.com>, you wrote on Tue, 12 Mar 2002
15:29:51 -0500:

[full elaborate sentences]


>Now, I'm not sure I understand why a newbie would type something like
>this.
>
>The claim has been made that newbies expect the parser to handle full
>sentences in conversational english, and are confused when this doesn't
>work. I find this a little hard to accept; I don't think anyone really
>wants to use natural language with their game

Are you referring to message <u8m20ls...@corp.supernews.com>?

In this Kodrik writes:

: 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 read this as "my wife actually tried this", not as "she wants to,
but some magic force stopped her from typing such elaborate
sentences".

My assumption seems to be corroborated further on:

: 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.

>-- even if the parser would accept it, I'd never type "pick up the
>brown box that's over there on the table; my attention was drawn
>to it by the fact that it was described in such detail in the room
>description" -- not because I'm used to the telegraphic style of
>IF commands, but because it's a waste of my time.

Ah, but what you have gathered there is introspective data.
Introspection can be useful, but not for backing up statements such
as:

>I would think that even a newbie, when playing IF, would
>want to communicate as briefly as possible, partly because typing is
>some level of effort, partly because people are, by now, used to
>computers not being able to understand natural language, but mostly
>because there's no benefit to it.
>
>The newbies I've introduced to IF recently did *not* try to say things
>too complex for the parser to understand -- on the contrary, they tried
>things too *simple*, issuing commands like "box" for the statement
>above, for example.

Could it be you coached them? Of course, that is very useful. Kodrik
is dealing with web players, who have the patience of the average
fruit fly, so even if he put up a manual (I only glanced at <>),
there's a chance not many people would actually read it.

>(To qualify, I'll describe the two people I've most recently shown IF
>to. The game, in both cases, was 'Moments out of Time' (the reason I
>showed it to them being that they wanted to see this game I'd allegedly
>written). The first was my mother, who had played IF before, but that
>was fifteen years ago, well before the span of her memory, who is pretty
>well computer illiterate. The other was a graduate student in computer
>science with a very strong background in programming and computer
>graphics. I was a little surprised that both approached the parser the
>same way. I'm sort of curious how someone whose background was in
>natural language processing would approach it -- I suspect that they'd
>make the same kind of statements, "knowing better" than to expect the
>game to respond to a conversational statement.)

Hm, I do have a background in natural language processing, but I
played my first adventure game (Pirate's Cove) seven years before I
started studying computer linguistics, so I cannot help you there. :-)

Magnus Olsson

unread,
Mar 13, 2002, 4:06:28 AM3/13/02
to
In article <ulwj8.5$0Q4...@inet-nntp1.oracle.com>,

Mike Roberts <mjr-S...@hotmail.com> wrote:
>Magnus Olsson <m...@df.lth.se> wrote:
>> So, yes, you have a point: the killer is not that the parser
>> can't parse very complicated sentences, but that the game
>> only accepts certain types of commands.
>
>I quite agree - and this can't be solved by adding more commands. It always
>seems like a red herring to me when people argue about how "natural" the
>command language ought to be, because in my experience, what really seems to
>trip up novice players isn't the parser but the idiosyncratic, and fairly
>shallow, world model.

What he said.

I think Kodrik's goal - to have a parser that accepts a wider, more
"natural", range of inputs - is laudable, but such a parser must be
accompanied by an improved world model.

>This is why I think it's more important, if you care about novice players,
>to make the parser simpler, not more complicated.

I think that in some ways at least, the two-word parser of ADVENT was
more newbie-friendly than the Inform parser, because its limitations
were so obvious. The downside is that a strict two-word parser simply
doesn't allow some things which modern players have come to regard as
essential - such as choosing with *which* weapon to attack the
troll. "Kill troll with flamethrower" is likely to be more effective
than "kill troll with paperknife". So I'm not advocating a return to
two-word parsers, just pointing out that things were easier back then.

>I think a novice player
>is going to have a much more satisfying experience if you can hand him or
>her a short list of all of the command phrasing that they could possibly
>need to play the game, and tell them that if they get stuck, they should
>just remember that they never need any commands but those on the list.

I used to be against this, on the grounds that it takes away the
illusion of freedom, and that it can spoil some puzzles, but I'm
beginning to change my mind. The game shouldn't shove the verb list in
the player's face, but it may be a good idea to have it available to
help new players. And if revealing the existance of a certain verb
spoils a puzzle, I think it's a good solution to list all the other
verbs, and then add "There are some other verbs that may be useful in
some situations, but revelaing them now would give away too much". I've
seen this done, and it seemed fair at the time.

>All
>of the fancy stuff that modern parsers do is for the benefit of experienced
>players, to save them keystrokes.

That's perhaps putting it a bit strongly. The parser should at least
support the world model, and a two-word parser can't support Inform's
or TADS's world model. But perhaps by "fancy" you mean things beyond
that.

Plugh!

unread,
Mar 13, 2002, 5:55:25 AM3/13/02
to
hi Kodrik,

you appear to have posted :

: 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.

I would be *very* interested in seeing the log, or at least some
intertesting examples from it. Can you post something here, or give a
URL?

Kodrik

unread,
Mar 13, 2002, 6:52:22 AM3/13/02
to
> I would be *very* interested in seeing the log, or at least some
> intertesting examples from it. Can you post something here, or give a
> URL?

you log in to phpZork and type "message"
It will pull 20 messages randomly, it might take a few seconds because this
is not optimized at all.

It was much clearer the first month because all players were starting the
game and most inputs were still out of the house. The newbies were not
outbalanced by the IF payers.
Now, there is over half a million entries and large majority of them are
from users who have percevered or adapted to the parser, so the newbie
input are probably less than 1% of the total inputs

I have an input log coded for the game I am putting up at the IF-lib comp,
and this one keep track of which rooms the inputs were typed and which
inputs were not recognized by the parser. I did this so the author can
enhance his games with new possibilities and I can enhance the parser to
recognize more inputs.

No login will be required so there will be much more players than phpzork,
a lot of them newbie to IF.
Also, the parser not being as strict, they will type more the way they feel
they should type naturally in that sort of game.
The result from the inputs of this game should be most interesting.

David Thornley

unread,
Mar 13, 2002, 12:42:40 PM3/13/02
to
In article <u8qa3uj...@corp.supernews.com>, Kodrik <kod...@zc8.net> wrote:
>> 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.
>
Yes. This could certainly be an honest player.

Modern parsers do generally support an "all but" or "all except"
construct, and this isn't much of a stretch from there. Instead
of taking "ignoring" to be "except", the parser is disregarding
the word.

Suppose the blue and red pots are in the horrible trap. The player
might say
>TAKE ALL EXCEPT BLUE POT AND RED POT
and have it work. There's also the possible command
>TAKE ALL ECXEPT BLUE POT AND RED POT
and in this case you really want the parser to tell you it doesn't
know that "ECXEPT" means rather than deciding that you want to
take everything in addition to the blue pot and the red pot. Of
course, the player could type a word the parser doesn't recognize
instead of misspelling a word it does, so
>TAKE ALL IGNORING BLUE POT AND RED POT
and we can continue along the continuum until we get to the command
above.

It is not safe to ignore words the parser doesn't recognize. It's
OK to have a list of words that are safe to ignore, but that
isn't the same thing.

>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)
>

Again,
>READ THE MESSAGE
>READ THE MESSAGE THROUGH THE MAGNIFYING GLASS
>READ THE MESSAGE THROUGH THE MGNIFYING GLASS
is a logical progression. If there is any harm in reading the
message without using the magnifying glass it is unsafe to
disregard the following words. (For that matter, having a
reply like "You can't read it" for trying to read the message
without the magnifier would be really misleading, as it would
lead the player to think that the message can't be read
even with it.)

Something like
>EXAMINE THE WELDING ARC THROUGH THE DARK GALSS
comes to mind.

>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.

Except where words in that position might be significant.

--
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 13, 2002, 5:31:28 PM3/13/02
to


See, it hasn't been my experience (or perhaps "has ~been my experience")
that a newbie, or indeed me, would type even that; I suggest that a
newbie would be more liable to type
>READ MESSAGE


Now, that said, where I *do* think the standard parsers could do with
some help is in how they *help themselves* --
Like I said, I don't think newbies are liable to type things too complex
for the parser, but, I do think (and this *has* been my experience) that
they tend to interpret the parser as asking for clarification;

In most standard parsers, if "message" wasn't precise enough, the parser
would indeed ask: Which do you mean?, and want an answer.

On the other hand, when the parser gets into a level of trouble
prompting it to tell you "I didn't understand you after 'x'", the newbie
thinks that the parser wants him to help. Of course, the parser really
wants the user to try again in something closer to its own language.

But maybe it should; SUppose:

>INTERACTIVE PARSING

(So that people don't say "Boy it would annoy me if a game forced me to
go through this, because I'm not a newbie and would know how to deal
with these errors")

Okay.

>TAKE THE BROWN PEN AND USE IT TO WRITE MY NAME

I only understood you as far as wanting to take the brown pen. Is that
right?
> Y

It looks like you want to also take something else. Is that right?
>N

Okay. I'll try to interpret the rest of what you typed as a separate
command.

"Use" isn't a verb I recognize. Do you want to try a synonym?

>N

Okay. I understood "TAKE BROWN PEN," and didn't understand "AND USE IT
TO WRITE MY NAME." I'm going to do as much as I understood, and throw
away the rest. Is that okay?

>Y

Pen: Taken.


Granted, this might be a little silly, and it's probably not a good
example, but look at what it does: it walks the player through what the
parser is "thinking". The player might have been able to salvage the
input completely, *and* the player ends up knowing *why* what he tried
didn't work.


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

"I'll start with who, what, where, and when, followed by whither,
whether,
wherefore and whence, and follow that up with a big side-order of 'why'"
--
Douglas Adams, The Hitch-Hiker's Guide to the Galaxy, episode 11

EPerson

unread,
Mar 13, 2002, 5:49:16 PM3/13/02
to
Kodrik <kod...@zc8.net> wrote in message news:<u8t5olm...@corp.supernews.com>...

This doesn't exactly address my main point, which was to have the
parser recognize descriptors *within* the input text. ("Burn the cloak
that I am wearing" to only activate a key for a worn cloak, not
another.) How exactly could a new shirt suddenly have all this
working. I had the impression keys had to be manually done for each
object.

Eric Schmidt, The F-iest

Kodrik

unread,
Mar 13, 2002, 7:31:42 PM3/13/02
to
> This doesn't exactly address my main point, which was to have the
> parser recognize descriptors *within* the input text. ("Burn the cloak
> that I am wearing" to only activate a key for a worn cloak, not
> another.) How exactly could a new shirt suddenly have all this
> working. I had the impression keys had to be manually done for each
> object.

I'm not sure which of two questions you aks so I will anwer to them both:

1:

When you define a key you don't type the matches to be recognized, you
select them from pop-up menus that are links to words that are in tables.

So let's say you have:
"take" "cloak", in reality it stores an id to the verb take and an idea to
the object "cloak".
When it builds the sentences, it combine those words and all the associate
synonyms.

So if you change the name of your clock to "jacket" with a "coat" a a
synonym, all the keys will now be activated by the commands:
"take" "jacket"
"take" "shirt"
"grab" "jacket"
"grab" "shirt"
"get" "jacket"
"get" "shirt"
This makes it creating a library of object very possible, once the authors
imports the object, he changes it's names and synonyms and all the keys set
for that object will be set except game specific keys like "hang" "jacket"
"cloak".
So if in a game for example, you realize from the user inputs that they
refer to an object in a way you didn't anticipate, you just add a synonym
to the object and all the keys will now use it for their object match.

2:

Keys are triggers that activate specific chains of sequences to them. You
ca set a key to do this and that when a counter reaches 5 or when a match
is made in a command.
For a key to be listening to an input or an environment change, it must in
scope. That mean a key associated to an item in a box will only listen if
the box is open. An key for an equipement will only be active if itis is
currently in the players inventory.
Keys can be organized into combo, so you can set the "open door" key to
listen only after the "unlock door" key has been succesfully past.
Finally, keys have requirements, the key "unlock door" will only be
listening if the player has the item key in inventory.
So keys can be extremelly linked to the status of objects and the game in
general and when actvated they can modify the state of anything in the game
and any number of things.


Kodrik

unread,
Mar 13, 2002, 7:43:03 PM3/13/02
to
> See, it hasn't been my experience (or perhaps "has ~been my experience")
> that a newbie, or indeed me, would type even that;  I suggest that a
> newbie would be more liable to type
>>READ MESSAGE
>
> Now, that said, where I do think the standard parsers could do with

> some help is in how they *help themselves* --
> Like I said, I don't think newbies are liable to type things too complex
> for the parser, but, I do think (and this has been my experience) that

> they tend to interpret the parser as asking for clarification;
>
> In most standard parsers, if "message" wasn't precise enough, the parser
> would indeed ask: Which do you mean?, and want an answer.

Many times you have to precise your object: "Read message in sawdust" and
you get your valid reply. IF you would put "Read message" it might prompt
you which message.
In case of COD, if you say read message, you win and if you say "read
message in saydust" it really screws you up.

So you might formulate it one way or the other, and might get error on
either way depending on the game.

Are you saying that you rarely have to reformulate your sentence for the
game to recognize it? This might be a quality of veteran IFers but not the
mass.

We will be able to read the inputs for the game in a week or so.

Carl von Hållplatz

unread,
Mar 14, 2002, 7:19:07 AM3/14/02
to
Kodrik

> Earlier in my life, I have experience [sic] some failure publishing and
> distributing software.

And like many other failed dilettantes you chose IF as the arena on
which to exhibit your mediocrity. Welcome to the club!

Adrian McCarthy

unread,
Mar 14, 2002, 3:17:53 PM3/14/02
to

Magnus Olsson <m...@df.lth.se> wrote in message
news:a6n4qk$a7n$1...@news.lth.se...

> In article <ulwj8.5$0Q4...@inet-nntp1.oracle.com>,
> Mike Roberts <mjr-S...@hotmail.com> wrote:
> >Magnus Olsson <m...@df.lth.se> wrote:
> ....

> I think that in some ways at least, the two-word parser of ADVENT was
> more newbie-friendly than the Inform parser, because its limitations
> were so obvious.

Yes, the Advent parser was *very* newbie friendly. But this wasn't just
because of the two-word limitations. In the original game, the parser
offered
all sorts of conveniences that many newer games don't offer.

If I recall correctly, the first time I played, I succesfully navigated into
the
cave without the use of compass navigation. "GO HOUSE", "ENTER",
"EXIT", "GO DOWNSTREAM", etc. (Some of these conveniences were
lost when Advent was ported to other systems.) Once you were inside the
cave, the program politely suggested using compass directions to get
about. That was a magical interactive experience with a computer. It
still is. Like many people, I was sucked into the game. I don't recall any
moments of immense frustration or disappointment with the parser.
Admittedly, however, the limitations of the game model did grow old by
the end of the game.

With Zork, I was immediately excited by the enhanced parser, and quickly
learned that it embodied a more complext world model (containment,
distinguishing between similar objects, etc.). Of course, I did have a few
nasty problems getting the parser to understand me, and a few
disappointments with the limitations of the world model. I got through
Zork, but it didn't suck me in the same way the Advent did.

Now I'm trying some of the more modern games. At times, they are
immensely playable. At other times, I can't get through a puzzle simply
because I can't get the parser to understand (even while cribbing from the
walkthrough!). In many cases, it seems the author had to stretch the parser
to handle the solution he had in mind, and once you've gone beyond what
the parser was originally built to handle, it becomes much more fragile.

I'm not sure what the answer is. I want the magic of Advent with a Zork
level of simulation (as a minimum), and the quality of stories that appear
in the new crop of IF. I can dream, can't I?

> >I think a novice player
> >is going to have a much more satisfying experience if you can hand him or
> >her a short list of all of the command phrasing that they could possibly
> >need to play the game, and tell them that if they get stuck, they should
> >just remember that they never need any commands but those on the list.
>
> I used to be against this, on the grounds that it takes away the
> illusion of freedom, and that it can spoil some puzzles, but I'm
> beginning to change my mind.

It would take a lot to change my mind. I'm drawn to IF by the illusion, and
I crave to make the illusion more robust.

Aid.

Kodrik

unread,
Mar 14, 2002, 3:56:23 PM3/14/02
to
Carl von Hållplatz wrote:

> And like many other failed dilettantes you chose IF as the arena on
> which to exhibit your mediocrity. Welcome to the club!

I'm not really sure what you mean by failed dilettantes, do we fail to
appreciate art, or do we fail in being amateurs? Either way, it doesn't
make much sense to me.

Regardless, from your quote, I would think you imply that because one has
failed, he lacks in experience versus one who has never failed. Are you
serious? Very succesful people have often encountered many failures,
learned from them and made a success.

If you are relating to personal experiences where you gave up and label
yourself as a looser after each failure, I agree you will never succeed.
But it's not because you failed when you tried, but because you gave up.
You can learn more from your mistakes than from your successes and in the
long run it is through the experience of your failures that you will be
successful. Having a defeatist attitude will not help you in your life.

I've had failures, I've had successes. I would not have had my successes if
not from what I learned from my failures. So my advice to you: persevere
and never stop learning.


Fredrik Ramsberg

unread,
Mar 15, 2002, 11:05:00 AM3/15/02
to
Kodrik <kod...@zc8.net> wrote in message news:<u923u81...@corp.supernews.com>...

> Carl von Hållplatz wrote:
>
> > And like many other failed dilettantes you chose IF as the arena on
> > which to exhibit your mediocrity. Welcome to the club!
>
> I'm not really sure what you mean by failed dilettantes, do we fail to
> appreciate art, or do we fail in being amateurs? Either way, it doesn't
> make much sense to me.

Couldn't you see the ugly tail and smell the foul breath? He's a troll.

His name means bus stop in Swedish. Few people have that name. None, actually.

/Fredrik

Adam Thornton

unread,
Mar 15, 2002, 10:59:44 AM3/15/02
to
In article <ab01df60.02031...@posting.google.com>,

Fredrik Ramsberg <f...@mail.com> wrote:
>Couldn't you see the ugly tail and smell the foul breath? He's a troll.

Oh, that scary old breath of brandy and death? And the tail dragging in
the sea?

Are you sure he's not Leonard Cohen?

Adam

Mike Roberts

unread,
Mar 16, 2002, 3:23:34 PM3/16/02
to
"Magnus Olsson" <m...@df.lth.se> wrote:

>Mike Roberts wrote:
> >All of the fancy stuff that modern parsers do is for the
> >benefit of experienced players, to save them keystrokes.
>
> That's perhaps putting it a bit strongly. The parser should
> at least support the world model, and a two-word parser
> can't support Inform's or TADS's world model. But perhaps
> by "fancy" you mean things beyond that.

Right - I was just talking about pronouns, noun lists, ALL, ALL BUT, command
lists, and so on. Now, I'm not saying I'd give up those things; I'm just
saying that they're important more as shortcuts for experienced players than
as natural language enhancements for novice players.

--Mike

Mike Roberts

unread,
Mar 16, 2002, 4:11:22 PM3/16/02
to
"Adrian McCarthy" <sp...@aidtopia.com> wrote:
> Magnus Olsson wrote in message

> > Mike Roberts wrote:
> > >I think a novice player is going to have a much more
> > >satisfying experience if you can hand him or her a short list
> > >of all of the command phrasings [...]

> >
> > I used to be against this, on the grounds that it takes away the
> > illusion of freedom, and that it can spoil some puzzles, but I'm
> > beginning to change my mind.
>
> It would take a lot to change my mind. I'm drawn to IF by the
> illusion, and I crave to make the illusion more robust.

I completely agree with the goal; it's just that I think there are better
ways to pursue it than by trying to convince novice users that the parser
actually understands natural language, because I think that's a fool's
errand with current technology.

One key to a successful illusion, I think, is to get the observer to buy in
to the boundaries of the illusion. When you're watching a movie, it would
never occur to you to reach out and try to touch one of the images being
projected, or to try to have a conversation with one of the characters. Or,
to take a more immersive example, if you go on a motion simulator ride at an
amusement park, you know to not to look at the edges of the projection
screen, because doing so would destroy the illusion - you, the observer, are
a willing participant in the illusion. It would be cool if we could create
holodecks that convincingly fooled all of the senses without any
constraints; but until we can, there are lots of lesser technologies that
create satisfying experiences despite their limitations.

This is why I think it's useful in IF to design the parser so that you can
give the player a complete list of commands and phrasings. If you can hand
a novice player that list, and tell the player that they'll never need
anything beyond the list, I think most players will willingly - happily -
stay within the boundaries of the simulation, and that, paradoxically,
they'll stop noticing the boundaries specifically because they won't run
into them as often. In fact, I'd say this is exactly what experienced
players have learned to do: they've internalized the world model and learned
the parsing conventions, so they can actively participate in maintaining the
illusion.

--Mike

Gary Shannon

unread,
Mar 16, 2002, 5:26:53 PM3/16/02
to

"Mike Roberts" <mjr-und...@hotmail.com> wrote in message
news:_xOk8.8604$7C2.3343315128@newssvr21.news.prodigy.com...

<snip>


>
> This is why I think it's useful in IF to design the parser so that you can
> give the player a complete list of commands and phrasings. If you can
hand
> a novice player that list, and tell the player that they'll never need
> anything beyond the list, I think most players will willingly - happily -
> stay within the boundaries of the simulation, and that, paradoxically,
> they'll stop noticing the boundaries specifically because they won't run
> into them as often. In fact, I'd say this is exactly what experienced
> players have learned to do: they've internalized the world model and
learned
> the parsing conventions, so they can actively participate in maintaining
the
> illusion.
>
> --Mike

Well put, and I agree completely. My only concern is that experienced
players who know the boundries may never venture beyond those boundries even
when the author has provided things outside them. I am returning to IF
after many years of absence and I still tend to use the two word command
format I learned back in the Infocom days. I've gotten stuck more than once
in modern games by assuming, without even questioning that assumption, that
the parser simply wouldn't understand anything beyond <verb> <noun>. The
convention is so well drilled into my head that it never even occurs to me
to think outside that box unless I remind myself to do so.

The conventions, therefore, tend to define the box in which the current
generation of games resides. But if we are not careful the box becomes so
invisible to us that we never think to challenge it.

--gary


Mike Roberts

unread,
Mar 16, 2002, 11:38:36 PM3/16/02
to
"Gary Shannon" <fiz...@starband.net> wrote:
> The conventions [of modern IF], therefore, tend to define the

> box in which the current generation of games resides. But if we
> are not careful the box becomes so invisible to us that we never
> think to challenge it.

Definitely. Fortunately, it seems like IF attracts a good number of authors
who especially enjoy challenging the conventions of the medium, so it'll
probably be a long time before we're too boxed in.

--Mike

0 new messages