Making a parser - what are the minimal requirements?
Mark Borok
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
> 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
> 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
> 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
> 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
<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
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
> 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
> 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
> 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
> 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
> 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
> 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
>> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
> 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
>
>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
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.
>
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
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?
>
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
> 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
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
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
> 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
>
> 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.
"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