The pitfalls of skipping words in parsing [was Re: Making a parser - what are the minimal requirements?

85 views
Skip to first unread message

Kevin Forchione

unread,
Mar 10, 2002, 10:42:54 AM3/10/02
to
Heh. Game commands are just like any other user interface, there are
conventions to be followed and, like any other UI, the user must
understand the rules of engagement. Otherwise we're left with that
comical scene from Star Trek IV, where Scotty attempts to talk to the
computer, then attempts to talk to it via the mouse.

There are some obvious parsing errors that can result from the Kodrick
parser. For instance:

1. The conversation with nobody:

>KODRICK, PUT THE APPLE ON THE TABLE
DONE
>KODRICK, TAKE THE APPLE
DONE

If Kodrick isn't in the game, you've suddenly got the apple in your
inventory.

2. Multiple commands being handled as a single command. (I realize
your parser design, doesn't allow for multiple commands on a line, but
the following erroroneous action is still possible).

>TAKE THE BOOK AND FROTZ THE CANDLE.

If Frotz isn't a word in the KEYS of the game the player simply takes
both the book and candle.

3. The mispelled word.

YOU SEE A GRAY CAT AND A WHITE CAT HERE
>TAKE THE GREY CAT
WHICH CAT DO YOU MEAN, THE GRAY ONE OR THE WHITE ONE?
>GREY
WHICH CAT DO YOU MEAN, THE GRAY ONE OR THE WHITE ONE?

These are just 3 cases that come to mind immediately. These, and
others, are reasons why this community rejected the approach the
Kodrick parser takes. It's not that the wealth of experience of
players and system authors simply thumbed their nose at the newcomer,
but that this kind of approach was seen to be inadequate for a
satisfying dialogue with the game.

Every *player* knows, if you're going to play the game, you've got to
learn the rules, whether it's Interactive Fiction, chess, or pitching
stories to Hollywood.

--Kevin

Kodrik

unread,
Mar 10, 2002, 2:28:02 PM3/10/02
to
> There are some obvious parsing errors that can result from the Kodrick
> parser. For instance:
>
> 1. The conversation with nobody:
>
>>KODRICK, PUT THE APPLE ON THE TABLE
> DONE
>>KODRICK, TAKE THE APPLE
> DONE
>
> If Kodrick isn't in the game, you've suddenly got the apple in your
> inventory.

No, because keys are conditional to the game environment. If there is a
possibility for an NPC Kodrik or you to take the apple, both should be
planned by the author and the appropriate action will be taken.
You have some points later, but this one isn't because keys have conditions
and are ordered.


> 2. Multiple commands being handled as a single command. (I realize
> your parser design, doesn't allow for multiple commands on a line, but
> the following erroroneous action is still possible).
>
>>TAKE THE BOOK AND FROTZ THE CANDLE.
>
> If Frotz isn't a word in the KEYS of the game the player simply takes
> both the book and candle.

Exactly, and it will tell you it did:
You take the book and the command
But so far, this hasn't affected gamplay negatively in any well designed
adventure.



> 3. The mispelled word.
>
> YOU SEE A GRAY CAT AND A WHITE CAT HERE
>>TAKE THE GREY CAT
> WHICH CAT DO YOU MEAN, THE GRAY ONE OR THE WHITE ONE?
>>GREY
> WHICH CAT DO YOU MEAN, THE GRAY ONE OR THE WHITE ONE?

No, actually this would work fine. I don't see why it would be a problem
either.

> Every *player* knows, if you're going to play the game, you've got to
> learn the rules, whether it's Interactive Fiction, chess, or pitching
> stories to Hollywood.

Yes, but for some people the attraction woudl have is to "dialog" with it,
limitation and speech makes it too frustrating for them to play.
You can say, comply or don't play. We ca make an effort on our side too.
E ngine authors are always improving on the parser tomake it more powerful
for a reason.

Jim Nelson

unread,
Mar 10, 2002, 4:17:21 PM3/10/02
to
Kodrik (kod...@zc8.net) says ...

>
> Yes, but for some people the attraction woudl have is to "dialog" with it,
> limitation and speech makes it too frustrating for them to play.
> You can say, comply or don't play. We ca make an effort on our side too.
> E ngine authors are always improving on the parser tomake it more powerful
> for a reason.

I suppose I see the logic of your wife wanting to "talk" to the computer.
It reminds me of Eliza, in the sense that the program's real magic lay
nowhere in the code itself, but in the user who anthromorphizes the
output. We're drawn further and further into the attractive idea of
talking to someone who seems so darn interested in everything we say.

But:

I recently had a nice lesson in TADS' indirect object handling coding
a handgun. In your parser, SHOOT GUN AT WINDOW reduces to SHOOT GUN
WINDOW, which can be keyed appropriately. But what about SHOOT WINDOW
WITH GUN (reducing to SHOOT WINDOW GUN)?

TADS handles this situation nicely:

SHOOT GUN AT WINDOW works.
SHOOT WINDOW AT GUN fails.
SHOOT GUN WITH WINDOW fails.
SHOOT WINDOW WITH GUN works.

In your parser, either they all work or one valid sentence results in
"The window doesn't fire bullets!"

What about these situations?

(Object described but not coded.)
PUT CLOAK IN SINK -> PUT CLOAK
"Where do you want to put the cloak?"

(Containment issues.)
PUT CLOAK ON DISHWASHER -> PUT CLOAK DISHWASHER
"You put the cloak in the dishwasher."

NO, PUT CLOAK ON THE DISHWASHER -> PUT CLOAK DISHWASHER
"You don't have the cloak." (or, just as frustrating, "The cloak's
already in the dishwasher.")

(Compound commands.)
GET THE DAMN CLOAK AND PUT IT ON THE DISHWASHER -> GET CLOAK; PUT
DISHWASHER
"You get the cloak."
"Where do you want to put the dishwasher?"

(Talky players -- this is what you're trying to solve, right?)
"You see a wizard here."
I'D LIKE TO KNOW MORE ABOUT THE CLOAK -> CLOAK
"What would you like to do with the cloak?"
I HOLD THE CLOAK UP FOR THE WIZARD TO SEE -> CLOAK
"What would you like to do with the cloak?"

Frankly, I see what you're describing as a modified two-or-three-word
parser, with the added bonus of associating adjectives with nouns. I'm
not sure this is a leap forward.

--
Jim Nelson
jim_n...@mindspring.com

Kodrik

unread,
Mar 10, 2002, 4:51:38 PM3/10/02
to
> SHOOT GUN AT WINDOW works.
> SHOOT WINDOW AT GUN fails.
> SHOOT GUN WITH WINDOW fails.
> SHOOT WINDOW WITH GUN works.
>
> In your parser, either they all work or one valid sentence results in
> "The window doesn't fire bullets!"

No, you can associate mutliple keys with prepositions, order the words and
the keys.

"shoot" "gun" "at" "window"
"shoot" "window" "with" "gun"

Then you can type:
Shoot the window with the gun in my hand ->success
Shoot the window at the gun -> fails

Personnally, I would not bother with the preposition and handle all the
above as true because a player has no reason to "shoot the gun with the
window". If he does this, he is playing beat the parser instead of playing
the game, so I wouldn't bother covering these cases.
But I do make an effort to cover all cases that make sense.


>
> What about these situations?
>
> (Object described but not coded.)
> PUT CLOAK IN SINK -> PUT CLOAK
> "Where do you want to put the cloak?"

The default answer for "put" would more likely be, "You can't put it there".
This is more the doing of the author than the engine.

> (Containment issues.)
> PUT CLOAK ON DISHWASHER -> PUT CLOAK DISHWASHER
> "You put the cloak in the dishwasher."

The author just has to use the preposition "on" for one key and "in" for
the other and describe what happens when it you put the cloak on the
dishwasher and in the dishwaser. If he just specifes one, you'll get the
defaut "put" reply, "you can'y put it there".
If it can be one and the author did his job right, the appopriate actions
will be take, on/in/under.

> (Compound commands.)
> GET THE DAMN CLOAK AND PUT IT ON THE DISHWASHER -> GET CLOAK; PUT
> DISHWASHER
> "You get the cloak."
> "Where do you want to put the dishwasher?"

You can't queue commands. The authors can design complex key to plan for
compoud commands but I don't think it will be worth the effore for most of
them

> (Talky players -- this is what you're trying to solve, right?)
> "You see a wizard here."
> I'D LIKE TO KNOW MORE ABOUT THE CLOAK -> CLOAK
> "What would you like to do with the cloak?"
> I HOLD THE CLOAK UP FOR THE WIZARD TO SEE -> CLOAK
> "What would you like to do with the cloak?"

This is again an author issue, he has to plan for better answers based on
environment.

> Frankly, I see what you're describing as a modified two-or-three-word
> parser, with the added bonus of associating adjectives with nouns. I'm
> not sure this is a leap forward.

I'm not saying it is better than grammar parsing, it is different with its
strengh and weaknesses.
But I don't think it will depreciate a game because they use a structure
parser versus a grammar parser for most players.

A good parser can be made structure based.

CardinalT

unread,
Mar 10, 2002, 5:49:28 PM3/10/02
to

"Jim Nelson" <jim_n...@mindspring.com> wrote in message
news:MPG.16f56d3a3...@news.mindspring.com...

> Frankly, I see what you're describing as a modified two-or-three-word
> parser, with the added bonus of associating adjectives with nouns. I'm
> not sure this is a leap forward.

I think you're misunderstanding his parser. Kodrik's parser is absolutely
capable of handling any input you want it to handle. This is because it
works essentially like the parser in that BASIC game so many people coded
back in '80's. The designer simply makes a list of all the word combinations
that will result in a successful action. Thus, for shooting the gun at the
window, you'd simply define "shoot" + "gun"+"window", while for shooting the
window with the gun you'd do "shoot"+"window"+"gun". You could continue on
with any and all the other combinations that you wanted to work; e.g.
"shoot"+ "window". In this respect, the parser is completely flexible and
adaptable. It doesn't depend upon grammar tables like Inform does because
it's not doing grammar parsing. It's simply matching a sequence of symbols
it finds in the input line against the symbol sequences it has stored in its
"library" (i.e. the ones you told it to understand). If it finds a match,
bingo. Successful action.

Incidentally, I don't think there's any limit (beyond memory restrictions)
on the number of symbols in one of Kodrik's keys. His parser can, in
principle, understand an input line with, say, a hundred significant words
(symbols) in it, whereas Inform's or Hugo's or TADS' grammar parsers can
only understand lines with a few. However, the big drawback to all of this
is that every one of your keys has to be individually and specifically coded
into the game for each and every object it will apply to, just as in the
BASIC game. There's no default library behavior (at least not yet), nor can
two objects share the same grammar.


Kodrik

unread,
Mar 10, 2002, 5:58:27 PM3/10/02
to
> There's no default library behavior (at least not yet)

And that might take a long time, it depends on competent and meticuouls
authors developing a default library for their game and letting other
people ue it.

> nor can two objects share the same grammar.

Everything you said is true except this last point. Two objects can share
the same grammar, which one is taken will be decided upon it's position
when processed by the parser. That's why positionning the order in which
the parser processes inputs is crucial.

1/ "take blue ball" -> (if blue ball) take blue ball
2/ "take red ball" -> (if red ball) take red ball
3/ "take ball" -> (if both) what ball?
4/ "take ball" -> (if blue ball) take blue ball
5/ "take ball" -> (if red ball) take red ball

So you will take the first ball by saying "take color ball" and the second
ball by saying "take ball".


Kodrik

unread,
Mar 10, 2002, 6:52:53 PM3/10/02
to
> Frankly, I see what you're describing as a modified two-or-three-word
> parser, with the added bonus of associating adjectives with nouns. I'm
> not sure this is a leap forward.

I think this might help you understand how it works:

This is the SQL query to get the keys (combos) that can answer to a user
input:

("select distinct gamecombos.id as currentcomboid, command.id as commandid,
gamecombos.comboid as comboid,
command.command, command.clefid, command.type
from gamecombos
left join gameelems on gamecombos.gameelemid=gameelems.id and
gameelems.gameid=$gameid
left join command on gamecombos.clefid=command.clefid
where (gamecombos.gameroomid=$roomid or gamecombos.gameroomid=0)
and gamecombos.gameid=$gameid
and gamecombos.status=7
and command.clefid>0
and (gamecombos.gameelemid=0 or
((gameelems.status=7 or gameelems.status=8 or gameelems.status=6) and
gameelems.hidden=0))
order by command.position asc");

It means get the keys (combos) that are in this room or global (roomid=0)
and where the keys are active (status=7) and either no element are
associated to it (id=0), the element associated to the key is in scope
(status=7), is not hidden from play (hidden=0), is in inventory (status=6)
or has been dropped or moved to this room (status=8), order the keys by
their parsing position.

This is a faily simple query and it can be processed on tables with
100,000s of rows in a tenth of a second.

Then we:
* loop through the keys
* Check if the requirements of the keys are met (it is snowing, stove is
on...), if they are, proceed with this key. This is the most time consuming
part.
* Make every possible combinations using all the synonyms for the words
used by this key.
* Use regular expression to match these word combinations in the user input
* If match, activate key, stop.
* else try with next key

This too is fairly simple processing wise and testing a 1000 keys can be
done in no time.

Rememeber, my engine is server based so the equipment of the user is of no
issue performance-wise to the processsing of their commands.


Jim Nelson

unread,
Mar 10, 2002, 10:16:13 PM3/10/02
to
Kodrik (kod...@zc8.net) says ...

>
> No, you can associate mutliple keys with prepositions, order the words and
> the keys.
>
> "shoot" "gun" "at" "window"
> "shoot" "window" "with" "gun"

Ah. I wasn't following the other thread closely enough.

> Personnally, I would not bother with the preposition and handle all the
> above as true because a player has no reason to "shoot the gun with the
> window". If he does this, he is playing beat the parser instead of playing
> the game, so I wouldn't bother covering these cases.
> But I do make an effort to cover all cases that make sense.

The example was contrived, but the problem is not. Windows don't shoot,
but if the player wanted to shoot a camera (or shoot the gun with the
camera) the problem is more apparent.

> > (Compound commands.)
> > GET THE DAMN CLOAK AND PUT IT ON THE DISHWASHER -> GET CLOAK; PUT
> > DISHWASHER
> > "You get the cloak."
> > "Where do you want to put the dishwasher?"
>
> You can't queue commands. The authors can design complex key to plan for
> compoud commands but I don't think it will be worth the effore for most of
> them

Doesn't this violate your requirement for making the parser more user
friendly? Aren't normal people going to do this? What will the parser
display in the above example if it doesn't recognize "AND"?

> I'm not saying it is better than grammar parsing, it is different with its
> strengh and weaknesses.
> But I don't think it will depreciate a game because they use a structure
> parser versus a grammar parser for most players.
>
> A good parser can be made structure based.

From the other thread, I was under the distinct impression you felt your
parser would be better than the current crop.

--
Jim Nelson
jim_n...@mindspring.com

Jim Nelson

unread,
Mar 10, 2002, 10:16:25 PM3/10/02
to
CardinalT (card...@helpmejebus.com) says ...
>
> "Jim Nelson" <jim_n...@mindspring.com> wrote ...

> > Frankly, I see what you're describing as a modified two-or-three-word
> > parser, with the added bonus of associating adjectives with nouns. I'm
> > not sure this is a leap forward.
>
> I think you're misunderstanding his parser. Kodrik's parser is absolutely
> capable of handling any input you want it to handle.

I realized this was the case when I posted. I just think that, in
practical terms, it boils down to a two-or-three-word parser. Yes,
programmers can string together long lists of significant tokenage and
achieve some desired result. I suspect, in practical terms, anything
beyond three or four tokens turns into an ugly mutation of guess-the-
verb: guess-the-token-order.

--
Jim Nelson
jim_n...@mindspring.com

Kodrik

unread,
Mar 10, 2002, 11:25:09 PM3/10/02
to
> Doesn't this violate your requirement for making the parser more user
> friendly? Aren't normal people going to do this? What will the parser
> display in the above example if it doesn't recognize "AND"?

Yes are absolutely right. I discarded queuing of commands because I viewed
it as unecessary gadgets that allows you to bypass the game experience:
n,s,s-w,take sword, kill troll with sword, take troll head

But I see know there are other uses, very real.
Open door and go in
Take red and blue balls

Fortunately, this will not be a challenge to incorporate:

If there is a , or a "and", break up the sentences in sub-sentences (as
many as necessary.

Start by the first exploded sentence, extract the verb, check for match.
Go to second exploded sentence
check as is,
if no match and no verb, try with extracted verb form previous sentence
as well.
if verb, extract verb and replace current extracted verb
Go to third exploded sentence...

This would work pretty well, the parser function would loop until the all
the parts of the exploded sentence are parsed. Then all the activation keys
will be shown and your current environment.

So you could say:
Take blue key and green key, unlock green lock with green key, blue lock
with blue key, open the door and go to the next room.

The screen will then show:
You take the blue key
You take the green key
you unlock the green lock with the green key
you unlock the blue lock with the blue key
you open the door
you leave the room

You are standing outside the house.

This should work pretty well


> From the other thread, I was under the distinct impression you felt your
> parser would be better than the current crop.

A lot of comments form the other thread implied that structure parsing
couldn't handle enough to be decent compared to grammar parsing (this
thread has been renamed "The pitfalls of skipping words in parsing").
I was trying to point out that grammar parsing has it advantages and
disadvantages, just like structure parsing but they are both capable of
decent story playing.

Yes, structure parsing can't do everything, but it sure can do enough to be
at a similar level than grammar parsing for player satisfaction.

Kodrik

unread,
Mar 11, 2002, 12:25:33 AM3/11/02
to
>> "shoot" "gun" "at" "window"
>> "shoot" "window" "with" "gun"

> The example was contrived, but the problem is not. Windows don't shoot,


> but if the player wanted to shoot a camera (or shoot the gun with the
> camera) the problem is more apparent.

No, it will be refused, these words are not present in the same orders as
in the combination for the keys in the example we use.
But utlimately, I am not interested as an author to give appropriate
answers for players who want to beat the parser by ordering impossible
things, this is not it's purpose.
But I do want to cover all possibilities for genuine players who are
playing my story, and I also want to understand as much as I can with as
few resctrictions as I can on their player's inputs.

CardinalT

unread,
Mar 11, 2002, 2:01:55 AM3/11/02
to
Kodrik wrote:

>> nor can two objects share the same grammar.
>
> Everything you said is true except this last point. Two objects can share
> the same grammar, which one is taken will be decided upon it's position
> when processed by the parser. That's why positionning the order in which
> the parser processes inputs is crucial.

Sorry, I worded this badly. What I meant to say is that one object can't
use the already constructed grammar of another object. The designer has to
supply a complete grammar for every object.

In Hugo (or Inform or TADS), grammar is universal. If I construct a grammar
for my new object, pistol, I can then use that same grammar for another,
similar item, rifle, without having to rewrite the whole thing from
scratch.

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

CardinalT

unread,
Mar 11, 2002, 2:10:55 AM3/11/02
to
Kodrik wrote:

> A lot of comments form the other thread implied that structure parsing
> couldn't handle enough to be decent compared to grammar parsing (this
> thread has been renamed "The pitfalls of skipping words in parsing").
> I was trying to point out that grammar parsing has it advantages and
> disadvantages, just like structure parsing but they are both capable of
> decent story playing.
>
> Yes, structure parsing can't do everything, but it sure can do enough to
> be at a similar level than grammar parsing for player satisfaction.

I think you're missing the point of the criticism. It's not that your
system can't do enough. It's that in some ways it does too much.

Nevertheless, my only really serious problem with it at this point is its
lack of default error messages for unsuccessful actions. Lacking these, the
amount of work required to implement even a moderately competent parser is
kind of prohibitive.

Kodrik

unread,
Mar 11, 2002, 2:29:42 AM3/11/02
to
> Sorry, I worded this badly. What I meant to say is that one object can't
> use the already constructed grammar of another object. The designer has to
> supply a complete grammar for every object.
>
> In Hugo (or Inform or TADS), grammar is universal. If I construct a
> grammar for my new object, pistol, I can then use that same grammar for
> another, similar item, rifle, without having to rewrite the whole thing
> from scratch.

The ability to copy keys and create librairies of keys is on my important
to-do list.
But what you just said made me think of something else.

There might be a way to associate functions and logic to properties and
then associate properties to keys and elements.

I will need to finish the key copying first and then get concrete inputs
about such a system from authors who master the engine in order to
implement something like in a good way.

Example, you create a door and give it the property wood and a strengh.
You create a torch and give it the property light and burn.

Then all the behaviour and numeous keys of the properites are associate to
them.
The player can then burn the door down with the torch without the author
entering anything special than assigning these properties to those
elements; of course, the author should be able to edit the imported keys
and properties to custoize them. This is simple but if modular enough,
it could be very powerful and do much much more than I imagine now.

I think I'm going to seriously cogitate over this.

EPerson

unread,
Mar 11, 2002, 11:10:38 AM3/11/02
to
> > 2. Multiple commands being handled as a single command. (I realize
> > your parser design, doesn't allow for multiple commands on a line, but
> > the following erroroneous action is still possible).
> >
> >>TAKE THE BOOK AND FROTZ THE CANDLE.
> >
> > If Frotz isn't a word in the KEYS of the game the player simply takes
> > both the book and candle.
>
> Exactly, and it will tell you it did:
> You take the book and the command
> But so far, this hasn't affected gamplay negatively in any well designed
> adventure.

I don't think that's a good excuse. A player will become frustrated by
this if it happens often, more frustrated than if the parser just
printed an error message. Also, something like this most certainly
could effect negative results:

>TAKE THE GUN AND FIRE UPON THE SNAKE (-> TAKE GUN AND SNAKE)
You take the gun.
Whoops! As your hand approaches the snake, it bites you, and you cry
in pain
from the venom...

***YOU HAVE DIED***

Basically, your parsing system pretends to understand input when it
doesn't. Too often it fails.

>TALK TO THE MEMBERS OF THE COURT (-> COURT)
Whom do you want to court?

(I've never understand why Inform doesn't come with a "talk" verb that
at least says to use something else.)

Eric Schmidt, The F-iest

Kodrik

unread,
Mar 11, 2002, 2:49:46 PM3/11/02
to
> Basically, your parsing system pretends to understand input when it
> doesn't. Too often it fails.

Most of the example people write are things you won't in a game, "shoot the
gun with the duck", "kil the troll with a plastic sword"...
You will see that while playing a game, it will rarely fail and understand
what you mean in a very satisfying way.

Coumpound sentences is a problem that has to be solved (that is what you
used in your example) because I they are used. Luckily, I think we found an
easy solution to recognize those and break them apart.

Lewis Raszewski

unread,
Mar 11, 2002, 4:43:53 PM3/11/02
to
Kodrik wrote:
>
> > Sorry, I worded this badly. What I meant to say is that one object can't
> > use the already constructed grammar of another object. The designer has to
> > supply a complete grammar for every object.
> >
> > In Hugo (or Inform or TADS), grammar is universal. If I construct a
> > grammar for my new object, pistol, I can then use that same grammar for
> > another, similar item, rifle, without having to rewrite the whole thing
> > from scratch.
>
> The ability to copy keys and create librairies of keys is on my important
> to-do list.
> But what you just said made me think of something else.
>
This is a good start, but the basic problem is that language is at a
slight cross here with OO design; logicially, under an OO model, actions
associate to objects, so the grammar for using an object is something
that logically belongs as a part of the object -- which is the way your
system is oriented.

In real life, however, grammar is independent of content: It's correct
to say "Eat the water", even though water is not something which has the
quality of being something one can eat. (And, indeed, colorless green
sheep sleep furiously)
--
L. Ross Raszewski
The Johns Hopkins University
Wyman Park 407

"If this should be our final stand, we stand together with pride. We
will
honor the past, and fight to the last; it will be a good way to die." --
The
Newborn's song, Lexx 2.18: Brigadoom

Kodrik

unread,
Mar 11, 2002, 6:25:38 PM3/11/02
to
> This is a good start, but the basic problem is that language is at a
> slight cross here with OO design; logicially, under an OO model, actions
> associate to objects, so the grammar for using an object is something
> that logically belongs as a part of the object -- which is the way your
> system is oriented.

Well, in my system, actions belong to keys wich are linked to triggers and
objects. he grammar belongs to the keys.
Objects can have different keys with conflicting actions , properties and
grammar associated to them.

Mark Borok

unread,
Mar 11, 2002, 9:25:09 PM3/11/02
to

> > > (Compound commands.)
> > > GET THE DAMN CLOAK AND PUT IT ON THE DISHWASHER -> GET CLOAK; PUT
> > > DISHWASHER
> > > "You get the cloak."
> > > "Where do you want to put the dishwasher?"
> >
> > You can't queue commands. The authors can design complex key to plan for
> > compoud commands but I don't think it will be worth the effore for most of
> > them
>
> Doesn't this violate your requirement for making the parser more user
> friendly? Aren't normal people going to do this? What will the parser
> display in the above example if it doesn't recognize "AND"?
>
I would just like to say here that I never use multiple commands on the
same line when playing IF (I may have mentioned this before), and
here's why: the first time I tried this, I saw that the game responded
with two replies, exactly as if I had typed two commands seperately.
The end result it, I did about the same amount of typing for the same
outcome.

TAKE LAMP THEN ENTER TUNNEL

You take the lamp.
You are now in the tunnel.

I just end up typing an extra "then" and have to read a very
moronic-looking response that dispels the impression that I am talking
to a real person.

Just my 2 cents.

--Mark

Mark W

unread,
Mar 11, 2002, 10:43:05 PM3/11/02
to
I may be putting my foot in a less than tasty place, but is it possible to
find some middle ground between "parser accepts anything by ignoring what
it doesn't understand" and "parser only accepts input in something
resembling C++"

What if the parser:

1) had a list of adjectives and adverbs (there may be an easy way to get
them online) and ignored them
2) had a list of other kind of words (negations, prepositions and such) and
tried to figure out what they meant
3) asked for confirmation whenever there was some doubt as to what it was
asking you to do:

> Frob smelly fish with the very rancid smelling cheesecake that my
grandmother gave me for my birthday.

Parser sees: Frob (adj) fish with (art) (adv) (adj) (adj) cheesecake (prep)

Parser returns: Are you sure you want to Frob the fish with the cheesecake?

>Yes

>Don't tell me what the fish looks like now

Parser sees: (negation) tell (player) what (art) fish looks like now.

Parser returns: Are you sure you do not want to be told what the fish looks
like?

>No

Then you want to be told?

>Yes

You don't want to know.

Mark

PS I thought *we* were on the cutting edge of AI ;) Nevermind those guys at
MIT and the fact that Zork is creeping towards the quarter century mark.

Kodrik

unread,
Mar 11, 2002, 11:46:38 PM3/11/02
to
> Parser returns: Are you sure you want to Frob the fish with the
> cheesecake?

That may be annoying or good depending how oftend it happens with parsers,
it mean two inputs instead of one.
A neophyte will see it all the time but it will teach him good input
manners, which is pretty good.

>>Don't tell me what the fish looks like now

I don't see the point in supporting sentences the user shoudn't write. An
honest user will not type something like this in an adventure unless it is
to try and trick the parser. Most input examples posted here are of that
type but it isn't what we need to support.

If a user is meant to typ something like this because of the contextof the
story, the author should plan for it and it will de accepted.

> PS I thought *we* were on the cutting edge of AI ;) Nevermind those guys
> at MIT and the fact that Zork is creeping towards the quarter century
> mark.

I don't see us as having to do AI, but matching input with actions in the
game. And I agree there is improvement to make, whether the grammar or
structure road (more improvement in the structure road I conceed).

But to give credit to current engines, they haven't stopped bettering their
parsers, they are a long way from the dungeon parser.

Magnus Olsson

unread,
Mar 12, 2002, 4:40:32 AM3/12/02
to
In article <u8r2bg9...@corp.supernews.com>, Kodrik <kod...@zc8.net> wrote:
>>>Don't tell me what the fish looks like now
>
>I don't see the point in supporting sentences the user shoudn't write. An
>honest user will not type something like this in an adventure unless it is
>to try and trick the parser. Most input examples posted here are of that
>type but it isn't what we need to support.
>
>If a user is meant to typ something like this because of the contextof the
>story, the author should plan for it and it will de accepted.

The problem is: how can you know in advance what commands an "honest"
user will or will not give? I think the problem you quoted with reading
the message in "Cloak of Darkness" is due to failing to anticipate what
the user will type.

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

DarrenH

unread,
Mar 12, 2002, 9:48:23 AM3/12/02
to
Kodrik, is your game ready? I for one would like to try it before making
any blanket pronouncements.....

Thanks,
D

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

John W. Kennedy

unread,
Mar 12, 2002, 11:49:15 AM3/12/02
to
Mark W wrote:
>
> I may be putting my foot in a less than tasty place, but is it possible to
> find some middle ground between "parser accepts anything by ignoring what
> it doesn't understand" and "parser only accepts input in something
> resembling C++"
>
> What if the parser:
>
> 1) had a list of adjectives and adverbs (there may be an easy way to get
> them online) and ignored them
> 2) had a list of other kind of words (negations, prepositions and such) and
> tried to figure out what they meant
> 3) asked for confirmation whenever there was some doubt as to what it was
> asking you to do:

This stuff is intrinsically hard:

Time flies like an arrow.

It's a pretty little girls school.

--
John W. Kennedy
Read the remains of Shakespeare's lost play, now annotated!
http://pws.prserv.net/jwkennedy/Double%20Falshood.html

Kodrik

unread,
Mar 12, 2002, 12:03:38 PM3/12/02
to
> Kodrik, is your game ready? I for one would like to try it before making
> any blanket pronouncements.....

It's already at a state where you can write a quite decent game. But it
might take years to have enough librairies and features to be at the same
level as TADS or Inform.
So depending on what you want to do, it's ready or it's years away.

Kodrik

unread,
Mar 12, 2002, 12:07:48 PM3/12/02
to
> The problem is: how can you know in advance what commands an "honest"
> user will or will not give? I think the problem you quoted with reading
> the message in "Cloak of Darkness" is due to failing to anticipate what
> the user will type.

I think good testing is important before releasing a story. Have people
play it from their own perspective and communicate with them to see what
problems they encounter.

You can't think of everything, but you can cover enough to have a good and
enjoyable adventure.

There will always be faults for those who look hard for them, regardless of
the parser.

Kodrik

unread,
Mar 12, 2002, 12:44:36 PM3/12/02
to
> Kodrik, is your game ready? I for one would like to try it before making
> any blanket pronouncements.....

I made an entry for the IF-lib Comp. The story of how this game was made is
pretty interesting I think, the testers how has much to do with its quality
and maybe more than the author. I might write something up next week with
the story of the making.
The result is a much better piece of IF that I would have written myself so
the credits should not go exclusively to me.
I had entered it in the competition to show that my engine is capable of
producing good IF but there are very good and exprienced writers in the
competition so I I'll be surprised if it is a winner.

I reviewed the rules and discovered two things that change my planning a
litlle:
* It will be public tested starting Saturday so I guess I will have to
release my engine at the same time. Using my engine at this point is
extremelly hard, there are virtually no documentation or librairies. So
I would suggest most people to wait until these are sufficient before
attempting to use it.
* The testers having taking an active part in developing the story, the
rules invalid them as testers so I need more testers. The adventure is
pretty short so testing does not take long. Anybody interested email me and
I'll give them access to test it.

Kevin Forchione

unread,
Mar 12, 2002, 6:04:17 PM3/12/02
to
Kodrik <kod...@zc8.net> wrote in message news:<u8r2bg9...@corp.supernews.com>...


> I don't see the point in supporting sentences the user shoudn't write. An
> honest user will not type something like this in an adventure unless it is
> to try and trick the parser.

And if yours is the most sincere parser in the community then The
Great Parser will swoop down and leave you with a bag of treats.

One of the fun things about IF is trying quirky things with the game
world. Look at HHGG for instance. If your engine is used to develop
strictly literary IF then perhaps sincerity/honesty will be the rule,
but if you've got puzzles to solve, then nearly anthing goes. This is
because authors are actually more twisted than players. :)

--Kevin

Kodrik

unread,
Mar 12, 2002, 6:44:16 PM3/12/02
to
> And if yours is the most sincere parser in the community then The
> Great Parser will swoop down and leave you with a bag of treats.

It's not the parser who is sincere, its the user. Grammar parsing puts some
pretty strict rules upon the player and if the users tries some fancy
stuff, he will be confronted with errors right away.
With structure parsing, he will more ofter get what he wanted.

> One of the fun things about IF is trying quirky things with the game
> world. Look at HHGG for instance. If your engine is used to develop
> strictly literary IF then perhaps sincerity/honesty will be the rule,
> but if you've got puzzles to solve, then nearly anthing goes. This is
> because authors are actually more twisted than players. :)

The commands are context sensitive. If you create a puzzle where weird
commands make sense than a structure parser is actually better equiped to
handle those inputs than a grammar parser. The author has full power to
recognize as many patterns in the structure of the user input to activate
different actions.

Earlier, you renamed the thread to the pitfall of structure parsing and
now you are reinforcing its value. I'm glad you are opening up to the idea.

Daniel Barkalow

unread,
Mar 13, 2002, 5:25:54 PM3/13/02
to
On Mon, 11 Mar 2002, Kodrik wrote:

> An honest user will not type something like this in an adventure unless
> it is to try and trick the parser. Most input examples posted here are
> of that type but it isn't what we need to support.

The real problem is that the author is unlikely to come up with every
single sentence that a player might type, because languages have a lot of
different constructions and a lot of different words. If the player knows
to try to action again with a different construction or different
vocabulary, this is fine (provided the player comes up with a suitable
phrasing before getting too annoyed). If the player gets an error message
which does not indicate that the parser misunderstood, it will seem like
the character tried something and failed. If the game does the wrong
thing, you'd better have a good "undo".

E.g.:

The butler is here. There is a poisonous snake on the table.

> TELL THE BUTLER TO TAKE THE SNAKE

The butler carefully picks up the snake with a barbeque fork.

vs.

> BUTLER, TAKE THE SNAKE

What do you want to do with the bulter?

You reach for the snake...

or

> SAY "BUTLER, TAKE THE SNAKE WITH A FORK"
(parser ignores 'SAY', '"BUTLER,', 'THE', 'WITH', 'A', 'FORK"', because
none of these are used, so far as the author has realized, in the game)

You reach for the snake...

It takes a little bit of work to make the game likely to do something bad,
but:

> THROW THE TIMEBOMB OUT THE WINDOW
(ignoring 'THE' 'TIMEBOMB' 'OUT' 'THE', author doesn't think of
"timebomb" as one word)

It is fixed in place. (or, worse, "You aren't holding it.")

-Iabervon
*This .sig unintentionally changed*

Kodrik

unread,
Mar 13, 2002, 6:16:47 PM3/13/02
to
> The real problem is that the author is unlikely to come up with every
> single sentence that a player might type.

You don't need to come up with sentences, just matches in the structure.
In COD, for example, I chose to have the match for hanging the cloak just"
"cloak" "hook" because there what else will the user want to do with the
vloak and the hook. Yes it will understand wrongly "destroy cloak with
hook", but a honest player has no reason to type this.
I could have mande my pattern more precise, by saying "cloak" "on" "cloak"
or "put" "cloak" "on" "hook", but I didn't felt it was needed.
What is there realisticly to do with a cloak and hook besides hanging it on
it? By setting it simply, the user can "trow the cloak on the hook", hand
the cloak no the hook"...

What you need to do is fnd the minimum patterns to cover most user request
form an action while recognizing user request for other actions.
The author can view a lot of them since he knows all the elements of the
game. But he will also need feedback from beta testers and read the user
inputs to account for other types of inputs.

Structure matching can be very precise or very loose, depending on the
environment of the action. I personallly try to make them as loose as I can
but it's a personal choice.

> > TELL THE BUTLER TO TAKE THE SNAKE
>
> The butler carefully picks up the snake with a barbeque fork.
>
> vs.
>
> > BUTLER, TAKE THE SNAKE
>
> What do you want to do with the bulter?
>
> You reach for the snake...
>
> or
>
> > SAY "BUTLER, TAKE THE SNAKE WITH A FORK"
> (parser ignores 'SAY', '"BUTLER,', 'THE', 'WITH', 'A', 'FORK"', because
> none of these are used, so far as the author has realized, in the game)
>
> You reach for the snake...

No, if there is a butler in the game that can be in presence of the snake
you will account for all these as follow:

1 "butler" "take" "snake" -> The butler carefully pciks up the snake
2 "take" "snake" -> you take the snake
This is all you need to handle your situations. If you want to add the fork
element:
3 "snake" -> What about the snake?
3 "take" -> Take what?

1 "butler" "takes" "snake" "fork"
-> The butler carefully picks up the snake with a barbeque fork.
2 "butler" "takes" "snake"
-> The butler carefully picks up the snake and gets bitten
3 "takes" "snake" "fork"
-> You carefully pick up the snake with a barbeque fork.
4 "takes" "snake"
-> You carefully take the snake and get bitten
5 "snake" -> What about the snake?
5 "take" -> Take what?

It's all how you define which sentences get matched first, from the most
complex to the smallest


Branko Collin

unread,
Mar 14, 2002, 3:25:37 PM3/14/02
to
Daniel Barkalow <iabe...@iabervon.org>, you wrote on Wed, 13 Mar 2002
17:25:54 -0500:

>It takes a little bit of work to make the game likely to do something bad,
>but:
>
> > THROW THE TIMEBOMB OUT THE WINDOW
> (ignoring 'THE' 'TIMEBOMB' 'OUT' 'THE', author doesn't think of
> "timebomb" as one word)
>
> It is fixed in place.

Not for long.

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

Daniel Barkalow

unread,
Mar 14, 2002, 10:03:22 PM3/14/02
to
On Wed, 13 Mar 2002, Kodrik wrote:

> > The real problem is that the author is unlikely to come up with every
> > single sentence that a player might type.
>
> You don't need to come up with sentences, just matches in the structure.
> In COD, for example, I chose to have the match for hanging the cloak just"
> "cloak" "hook" because there what else will the user want to do with the
> vloak and the hook. Yes it will understand wrongly "destroy cloak with
> hook", but a honest player has no reason to type this.

[hmm, maybe this hook will open a secret passage]

> PULL HOOK

It won't budge.

[maybe I need more leverage]

> PUT CLOAK ON HOOK

Okay.

> PULL ON CLOAK ON HOOK

It's there already.

[???]

> I could have mande my pattern more precise, by saying "cloak" "on" "cloak"
> or "put" "cloak" "on" "hook", but I didn't felt it was needed.
> What is there realisticly to do with a cloak and hook besides hanging it on
> it? By setting it simply, the user can "trow the cloak on the hook", hand
> the cloak no the hook"...
>
> What you need to do is fnd the minimum patterns to cover most user request
> form an action while recognizing user request for other actions.
> The author can view a lot of them since he knows all the elements of the
> game. But he will also need feedback from beta testers and read the user
> inputs to account for other types of inputs.

The problem is that players are likely to type unexpected things which
confounded by a puzzle (or by something they think is a puzzle), and
different players will think of different things. Players are also
particularly likely to try complicated and unusual actions if it seems
like the game understands complicated actions, or they will assume that
verbs are identical when they are treated the same most of the time.

(The latter is a common problem; if an Inform game wants the player to
"HOLD" anything, it had better make it clear that this verb is
implemented, because Inform players will generally not think of "HOLD
DOOR", since that is generally equivalent to "TAKE DOOR")

> Structure matching can be very precise or very loose, depending on the
> environment of the action. I personallly try to make them as loose as I can
> but it's a personal choice.
>
> > > TELL THE BUTLER TO TAKE THE SNAKE
> >
> > The butler carefully picks up the snake with a barbeque fork.
> >
> > vs.
> >
> > > BUTLER, TAKE THE SNAKE
> >
> > What do you want to do with the bulter?
> >
> > You reach for the snake...
> >
> > or
> >
> > > SAY "BUTLER, TAKE THE SNAKE WITH A FORK"
> > (parser ignores 'SAY', '"BUTLER,', 'THE', 'WITH', 'A', 'FORK"', because
> > none of these are used, so far as the author has realized, in the game)
> >
> > You reach for the snake...
>
> No, if there is a butler in the game that can be in presence of the snake
> you will account for all these as follow:

What if the player types 'SAY "TAKE THE SNAKE"', or 'SAY "TAKE THE
SNAKE" TO BUTLER', or calls the butler something the author hadn't
anticipated? It's going to be a lot of work to handle all of the different
circumlocations players might use (especially when faced with a puzzle).

Kodrik

unread,
Mar 14, 2002, 10:39:35 PM3/14/02
to
> What if the player types 'SAY "TAKE THE SNAKE"', or 'SAY "TAKE THE
> SNAKE" TO BUTLER', or calls the butler something the author hadn't
> anticipated? It's going to be a lot of work to handle all of the different
> circumlocations players might use (especially when faced with a puzzle).

You understand wel the problem.

I am not interested in supporting weird statements but it is important to
handle reasonable request. And just this is a huge challenge, in my
implementation of COD, I made it handle very little so far. Even in my
IF-lib comp entry, it doesn't handle half what it will handle after the
comp is finished and I can enhance it from the user input logs.

There are many combinations possible to make different things happen. How
many, I don't kow, can I forecast all of the ones that would sense to most
players? No.

The solution is to make your object, come up with as many keys as you want,
then read the user's inputs and their errors to adapt your game to handle
more. But this is much too much work for an author to specify on every
object of his game.

That is why the librairies will be so important, once a dedicated author
has coded the placement of an object on another one (like the cloak on the
hook), has designed keys from scratch and conducted sufficient testing with
enough people to enhanced his replies, he can save this in a library and
the next author wanting that kind of relation between two elements can
easily incorporate it.
It is the main reason why I say my engine is a long way for being an
efficient tool for authoring. It will take time to build all those
librairies and make the importation and exportation of objects as versatile
as possible. And without those librairies, it is just too much work to
create all these keys.

Magnus Olsson

unread,
Mar 15, 2002, 3:57:46 AM3/15/02
to
In article <u92rhk9...@corp.supernews.com>, Kodrik <kod...@zc8.net> wrote:
>I am not interested in supporting weird statements but it is important to
>handle reasonable request. And just this is a huge challenge,

Indeed.

One of the big problem with IF design in general is anticipating what
the player (an "honest" player) thinks is a reasonable request.
Because if the player makes what he thinks is a reasonable request,
but the parser treats it at a "weird statement", the player is going
to be annoyed.

Reply all
Reply to author
Forward
0 new messages