[General] IF parsers
Krister Fundin
parser in one of the popular IF systems, adding some things that I've been
missing in existing parsers, or which might be appreciated by newbies, or
which are completely useless but rather amusing anyway, like archaisms
and slang.
Having implemented much of what I could come up with on my own, I was
wondering if anyone else had any ideas: something you've always thought
that IF parsers should be able to understand or be smarter about, or
some issue that often shows up and deserves a general solution, or just
about any wild idea for that matter. All comments are welcome.
-- Krister Fundin
Neil Cerutti
Most IF parsers cannot cope if you use any words that it doesn't
already know. This makes it impossible to generate actions with
unknown objects, and usually the parser resorts to saying:
If it is truthful: I don't know the word "humbug".
If it is Inform: You can't see any such thing.
It might be nice to permit the generation of actions with one or
more unknown objects and let the author try to sort things out
based on the text. Much better error messages could be one
result. Another nice result would be that writing grammar to
handle arbitrary conversation would become possible without doing
all of the work yourself, and without the need to create special
grammar tokens to gobble up arbitrary text.
It would be an unforunate nuisance if authors were required to
check for this special case in all action handling code, so the
interface would need to be constructed carefully.
--
Neil Cerutti
quic...@quickfur.ath.cx
> I've been working for a while on an extension to improve the English
> parser in one of the popular IF systems, adding some things that I've
> been missing in existing parsers, or which might be appreciated by
> newbies, or which are completely useless but rather amusing anyway,
> like archaisms and slang.
Any specific examples that we can discuss?
> Having implemented much of what I could come up with on my own, I was
> wondering if anyone else had any ideas: something you've always
> thought that IF parsers should be able to understand or be smarter
> about, or some issue that often shows up and deserves a general
> solution, or just about any wild idea for that matter. All comments
> are welcome.
[...]
Here's an idea: we all know that natural language is ambiguous,
sometimes badly so (e.g., "time flies like an arrow; fruit flies like a
banana"). Most computer language parsers have unambiguous (or mostly
unambiguous) languages, and so most of the theory of parsing is geared
toward unambiguous grammars. But in IF, we *want* to deal with natural
languages, and therefore have to live with ambiguities. TADS 3 has made
some advancement in this area, in that if you refer to an ambiguous
object, it will first try to find the most logical match for that object
before giving up and asking the player to clarify what she means.
So what about extending this to deal with ambiguous sentence structures?
Given a sentence S, there is usually more than one way to parse it
(e.g., "time flies like an arrow" can have either 'time', 'flies', or
'like' as the verb, giving rise to at least 3 very different
interpretations of the sentence). Since we're not writing arcade games,
time isn't that much of an essence, so it should be feasible to
enumerate all possible parses of the sentence. Then, we can go through
each possibility, assigning to each a "sensibility" value. This value
reflects how likely that particular parse represents what the player
wants to do (e.g., a higher value is given if the resulting nouns and
verbs match the game's vocabulary, and a bonus score is given if the
nouns are in the PC's scope, etc.). At the end, if one possibility
clearly stands out from the rest, we assume that's what the player
intends, and go ahead with it.
To make this idea more concrete, let's take the pathological example
"time flies like an arrow". (This one isn't particularly exemplary of IF
commands, but it will suffice to describe this particular idea.) Here
are some ways in which in can be parsed:
1. time-VERB flies-NOUN (like an arrow)-ADVERB
2. time-NOUN flies-VERB (like an arrow)-ADVERB
3. (time flies)-NOUN like-VERB (an arrow)-NOUN
From a parser's standpoint, all of these are equally sensible. So how
does it decide which one is meant? (Or which one is more likely to be
meant?) By adopting TADS 3's approach: try to match up the verbs and
nouns with objects and actions in the game world. For example, if the
game happens to need an action of timing, then (1) gets a higher score.
If the game had a species of fly called 'time flies', then (3) would
also get a score boost. OTOH, if there are no such things as flies in
the game, then (1) and (3) would have a very low score, making (2) the
most likely possibility.
Here's a possible scenario: the game has the verbs 'fly' and 'time', and
you can refer to the current 'time', but has no such thing as 'flies'.
The parser would hypothetically go through the following decision
process:
(1) 'time' is a verb: +1
'flies' is a noun: -1 (there are no flies in this game)
Score: 0
(2) 'time' is a noun: +1 (we can refer to the time)
'flies' is a verb: +1 ('fly' is a verb in this game)
Score: 2
(3) 'time flies' is a noun: -1 (no such thing as flies in this game)
'like' is a verb: -1 (this game doesn't use the verb 'like')
Score: -2
The most likely meaning intended by the player is therefore (2).
Another scenario: the game has the verbs 'fly' and 'time', and there are
creatures known as 'time flies'. The decision process now is different:
(1) 'time' is a verb: +1
'flies' is a noun: 0 (it could refer to 'time flies', but it may not)
Score: 1
(2) 'time' is a noun: -1 (we don't need to refer to the current time)
'flies' is a verb: +1
Score: 0
(3) 'time flies' is a noun: +1 (this game has 'time flies')
'like' is a verb: -1 (this game doesn't use the verb 'like')
Score: 0
Result: (1) is the most likely meaning intended ('flies' could be
understood to refer to said 'time flies').
The key here is that the possibility chosen is *context-dependent*,
which is how we humans disambiguate these sentences in the first place.
The context, of course, is the contents of the game world. This helps
against comical (or more often, disastrous) misunderstandings of the
parser incongruous with the game world. E.g. "fly, fly away" could mean
the player wants to first fly, and then fly away, or it could be a
request to an NPC named 'fly' to fly away. The response "you see no fly
here" would be disastrous in a game where the player can fly, but would
make sense in a game in which the player can't fly but there's an NPC
called 'fly'. Similarly, "You can't fly" would be disastrous in a game
where the PC is trying to instruct the NPC 'fly' to fly away.
QF
--
Latin's a dead language, as dead as can be; it killed off all the
Romans, and now it's killing me! -- Schoolboy
Krister Fundin
<quic...@quickfur.ath.cx> skrev i meddelandet
news:20061013202711.GB8094@crystal...
> On Fri, Oct 13, 2006 at 07:26:39PM +0000, Krister Fundin wrote:
>> I've been working for a while on an extension to improve the English
>> parser in one of the popular IF systems, adding some things that I've
>> been missing in existing parsers, or which might be appreciated by
>> newbies, or which are completely useless but rather amusing anyway,
>> like archaisms and slang.
>
> Any specific examples that we can discuss?
Well, here are some of the things from the extension:
- A generic USE verb (should be standard IMHO).
- Better and more uniform handling of interjections:
- YES
- BOB, YES
- SAY YES
- SAY YES TO BOB
- TELL BOB YES
- YES, BOB (to do)
- THIS/THAT/THESE/THOSE/THEM as both pronouns and articles.
- Understanding EVERY BOOK in addition to ALL THE BOOKS.
- Understanding PLEASE DO X (just like in Intercal).
- Understanding NOTHING, NEITHER ONE, etc. as an answer to
disambiguation questions.
- Directions: GO TO THE NORTH, GO EASTWARDS, and
GO SOUTH-EAST with a hyphen.
- Understanding the ampersand where AND is understood.
Plus lots of synonyms and new phrasings for various standard commands,
and some things that I can't remember now. Mostly simple stuff.
>> Having implemented much of what I could come up with on my own, I was
>> wondering if anyone else had any ideas: something you've always
>> thought that IF parsers should be able to understand or be smarter
>> about, or some issue that often shows up and deserves a general
>> solution, or just about any wild idea for that matter. All comments
>> are welcome.
> [...]
>
> Here's an idea: we all know that natural language is ambiguous,
> sometimes badly so (e.g., "time flies like an arrow; fruit flies like a
> banana"). Most computer language parsers have unambiguous (or mostly
> unambiguous) languages, and so most of the theory of parsing is geared
> toward unambiguous grammars. But in IF, we *want* to deal with natural
> languages, and therefore have to live with ambiguities. TADS 3 has made
> some advancement in this area, in that if you refer to an ambiguous
> object, it will first try to find the most logical match for that object
> before giving up and asking the player to clarify what she means.
>
> So what about extending this to deal with ambiguous sentence structures?
That's absolutely necessary, of course. Speaking of TADS 3, its grammar
often produces several alternative parse trees for a given command, and
the library parser has a whole range of rules for choosing between them.
For instance, THROW BOB BALL has two possible meanings, but one
of them can be ruled out as long as there is no object called "bob ball" in
the story. It would be interesting if the verification scheme could be used
to disambiguate actions as well as objects, but that's way beyond the
scope of my extension, which is more about extending IFese to a larger
part of the natural language.
-- Krister Fundin
Krister Fundin
"Neil Cerutti" <hor...@yahoo.com> skrev i meddelandet
news:slrneivrap...@FIAD06.norwich.edu...
> Most IF parsers cannot cope if you use any words that it doesn't
> already know. This makes it impossible to generate actions with
> unknown objects, and usually the parser resorts to saying:
>
> If it is truthful: I don't know the word "humbug".
> If it is Inform: You can't see any such thing.
>
> It might be nice to permit the generation of actions with one or
> more unknown objects and let the author try to sort things out
> based on the text. Much better error messages could be one
> result.
I'm not sure if I follow. Do you mean that the player types, say, TAKE
THE TEMPERATURE, and as a last resort, this gets parsed as the
verb TAKE + some arbitrary text, and the ##Take action gets a chance
to try and figure out what it means?
> Another nice result would be that writing grammar to
> handle arbitrary conversation would become possible without doing
> all of the work yourself, and without the need to create special
> grammar tokens to gobble up arbitrary text.
Dunno. Seems that writing special grammar tokens would be easier
than looking at some text word by word. That said, I'm reminded of the
fact that TADS doesn't treat an unparsable order, E.G:
BOB, THIS IS ALL HUMBUG!
as saying some arbitrary text to Bob, which I do recall that Inform does.
-- Krister Fundin
Neil Cerutti
> news:slrneivrap...@FIAD06.norwich.edu...
>> Most IF parsers cannot cope if you use any words that it doesn't
>> already know. This makes it impossible to generate actions with
>> unknown objects, and usually the parser resorts to saying:
>>
>> If it is truthful: I don't know the word "humbug".
>> If it is Inform: You can't see any such thing.
>>
>> It might be nice to permit the generation of actions with one or
>> more unknown objects and let the author try to sort things out
>> based on the text. Much better error messages could be one
>> result.
>
> I'm not sure if I follow. Do you mean that the player types,
> say, TAKE THE TEMPERATURE, and as a last resort, this gets
> parsed as the verb TAKE + some arbitrary text, and the ##Take
> action gets a chance to try and figure out what it means?
Yes, that's essentially what I mean.
>> Another nice result would be that writing grammar to handle
>> arbitrary conversation would become possible without doing all
>> of the work yourself, and without the need to create special
>> grammar tokens to gobble up arbitrary text.
>
> Dunno. Seems that writing special grammar tokens would be
> easier than looking at some text word by word. That said, I'm
> reminded of the fact that TADS doesn't treat an unparsable
> order, E.G:
>
> BOB, THIS IS ALL HUMBUG!
>
> as saying some arbitrary text to Bob, which I do recall that
> Inform does.
That is true.
Inform does have a 'topic' gammar token for scooping up arbitrary
text. Most of what I'm thinking about actually fairly doable.
--
Neil Cerutti
constantl...@gmail.com
I would hesitate to agree with the introduction of a generic USE verb.
Should the player really be relieved of the burden to explain what
exactly he has in mind with the objects he mentions?
I suggest two possible exceptions. Here is the first one:
>dig
What do you want to dig with?
>use the shovel
...
The second one consists of allowing the USE verb if the player has
already figured out how to apply a certain object.
OH, and PLEASE DO NOT program your parsers in Intercal!
Greetings,
EternalGamer
aaroni...@gmail.com
> Most IF parsers cannot cope if you use any words that it doesn't
> already know. This makes it impossible to generate actions with
> unknown objects, and usually the parser resorts to saying:
>
> If it is truthful: I don't know the word "humbug".
> If it is Inform: You can't see any such thing.
It's fairly easy in I7 to write code that will generate this kind of
output:
You can see a meteor, a stone, and a long glass of sherbet here.
>EXAMINE ROCK
I'm sorry, I don't know what you're referring to. Perhaps you meant the
meteor, the stone, or the long glass of sherbet?
>EXAMINE BLACK
You can't see the stranger in Black just now.
...which behavior I find to be much less frustrating to the player than
the standard Inform defaults.
Jim Aikin
> already know. This makes it impossible to generate actions with
> unknown objects, and usually the parser resorts to saying:
>
> If it is truthful: I don't know the word "humbug".
> If it is Inform: You can't see any such thing.
Seems to me the Inform response, though clunky, is fairly clever. The parser
avoids either admitting or denying that it knows the word. Since either
admitting it or denying it might be a spoiler, this is a good option.
In answer to Krister's query, I'd suggest perhaps allowing the parser to
sort through alternate word orders and missing or extra words. It's
annoying, for instance, if the parser understands 'look out window' but not
'look out of window'. Both can be coded, of course, but it would be a
courtesy to the author to handle it automatically. Ditto for 'turn light on'
as an alternative version of 'turn on light'.
I recently ran into a fairly obscure bit of confusion that's pertinent: In
most IF, the distinction between containers (which use 'in') and supporters
(which use 'on') is unambiguous. But consider a simple bookcase object, for
which the nouns 'bookcase', 'shelf', and 'shelves' are implemented. If the
user prefers 'shelf', it's a supporter, but if the user types 'bookcase',
it's a container. 'put book on shelf' is normal English, as is 'put book in
bookcase'.
I solved this in I6 by creating a fake 'shelf' supporter that diverts
anything placed on it to the bookcase. But there may be other situations
where 'on' and 'in' are equally valid, and it seems perhaps inelegant to
have the parser do this (which is what it did before I implemented my
workaround):
>put book on shelf
That can't contain things.
Here's a bigger topic: There are situations in which 'crawl' and 'go' may as
well be synonymous, but there are also situations (such as a low tunnel or a
narrow ledge) in which the author might reasonably want to insist that the
player crawl. So if there were some way to alert the parser about
situationally splittable partial synonyms.... Well, it's worth thinking
about.
--Jim Aikin
Neil Cerutti
>> Most IF parsers cannot cope if you use any words that it doesn't
>> already know. This makes it impossible to generate actions with
>> unknown objects, and usually the parser resorts to saying:
>>
>> If it is truthful: I don't know the word "humbug".
>> If it is Inform: You can't see any such thing.
>
> Seems to me the Inform response, though clunky, is fairly
> clever. The parser avoids either admitting or denying that it
> knows the word. Since either admitting it or denying it might
> be a spoiler, this is a good option.
I don't believe that hiding the dictionary from the player is a
good way to make games difficult. And in addition I'm still not
convinced that letting the player query the dictionary is liable
to spoil anything.
There's the wrinkle to consider that a game can understand more
words than are just in the dictionary, but I've not heard that
used as a justification.
Anyhow, the other behavior is easy to obtain. I guess I just
wanted to kvetch (a kvetch is, apparently, a very small troll).
> In answer to Krister's query, I'd suggest perhaps allowing the
> parser to sort through alternate word orders and missing or
> extra words. It's annoying, for instance, if the parser
> understands 'look out window' but not 'look out of window'.
> Both can be coded, of course, but it would be a courtesy to the
> author to handle it automatically. Ditto for 'turn light on' as
> an alternative version of 'turn on light'.
This another approach that will have good and bad effects. Nitfol
has a word-correctin algorithm that sometimes causes bad things
to happen, and this approach could to.
But mostly it's change from the standard interface. Neither good
nor bad until we've tried it out.
> Here's a bigger topic: There are situations in which 'crawl'
> and 'go' may as well be synonymous, but there are also
> situations (such as a low tunnel or a narrow ledge) in which
> the author might reasonably want to insist that the player
> crawl. So if there were some way to alert the parser about
> situationally splittable partial synonyms.... Well, it's worth
> thinking about.
It's possible to modify the grammar on the fly using General
Parsing Routines, and even some of the less heavyweight grammar
tokens. But you wouldn't want to do it very often, as it doesn't
look very pretty in the IDE.
The Inform Port of Ditch Day Drifter contains a Knock-Knock joke
with which you can play along.
! (P) knock_knock_joke global
! I'm going to use this global, in conjunction with some general parsing
! routines, to prevent the library from recognizing the knock-knock joke
! grammar unless the joke is being told.
Global knock_knock_joke=0; ! 0 -- No knock-knock joke.
! 1 -- Listening for "who's there?"
! 2 -- Listening for "madame who?"
! (9.2.4)
[ ParseAnything
wd;
do
wd=NextWordStopped();
until (wd == -1);
return 0;
];
! (9.2.5)
[ ParseThere
wd;
if (knock_knock_joke ~= 1) return -1;
wd=NextWord();
if (wd == 'there' or 'there?') return 0;
else return -1;
];
! (9.2.6)
[ ParseWho
wd;
if (knock_knock_joke ~= 2) return -1;
wd=NextWord();
if (wd == 'who' or 'who?') return 0;
else return -1;
];
! (10.9.4)
[ KnockOnSub;
if (noun has door && noun has openable) {
if (noun hasnt open) "Nobody opens the door.";
! I will waste a pile of code on a useless knock-knock joke easter egg,
! which you get by knocking on open doors.
else {
knock_knock_joke=1; ! Initiate the joke.
"Knock, knock.";
}
}
if (noun == player) "Ow.";
if (noun has animate) "I don't think ", (the) noun, " would care for that.";
"", (The) noun, " ", (IsOrAre) noun, " unresponsive.";
];
! (10.9.5)
Verb 'who^s'
* -> NonVerb
* ParseThere -> WhosThere
* ParseAnything -> NonVerb;
! (10.9.6)
Verb 'who'
* -> NonVerb
* 'is' -> NonVerb
* 'is' ParseThere ->WhosThere
* ParseAnything -> NonVerb;
! (10.9.7)
[ WhosThereSub;
knock_knock_joke=2; ! Recognize "madame who?"
"Madame.";
];
! (10.9.8)
Verb 'Madame'
* -> NonVerb
* ParseWho -> MadameWho
* ParseAnything -> NonVerb;
! (10.9.9)
! Simulate the libraries standard response to unknown verbs.
[ NonVerbSub;
"That's not a verb I recognize.";
];
! (10.9.10)
[ MadameWhoSub;
knock_knock_joke=0; ! Turn off the knock-knock joke grammar.
"Madame knock-knock joke isn't very funny.";
];
I'm glad I got that off my chest.
--
Neil Cerutti
Daryl McCullough
>Most IF parsers cannot cope if you use any words that it doesn't
>already know. This makes it impossible to generate actions with
>unknown objects, and usually the parser resorts to saying:
>
>If it is truthful: I don't know the word "humbug".
>If it is Inform: You can't see any such thing.
I think that it was intentional that Inform worked that way.
Suppose that the game responds one way if a "humbug" appears
in the game, but the player hasn't encountered it, but responds
another way if "humbug" is not used by the game at all. That
might give the player a hint as to what's to come, which some
authors may not intend.
I suppose that the game could treat *every* word that the
player has not yet encounted as if it were an unknown word,
but that would be a little weird, as well.
Maybe an ambiguous error message such as
>Whatever "humbug" might mean, there doesn't seem to be one here.
--
Daryl McCullough
Ithaca, NY
Adam Thornton
ITYM, "PLEASE REFRAIN FROM progamming your parsers in INTERCAL!"
Adam
Krister Fundin
<constantl...@gmail.com> skrev i meddelandet
news:1160780258.6...@b28g2000cwb.googlegroups.com...
> Hello!
>
> I would hesitate to agree with the introduction of a generic USE verb.
> Should the player really be relieved of the burden to explain what
> exactly he has in mind with the objects he mentions?
Yes, at least in the cases where the interpretation is obvious. There's no
reason to burden the player just for the hell of it. If the player types USE
DOOR or USE BUTTON or USE CHAIR, then I think the parser would
merely seem rude if it said something like "you'll have to be more
specific".
If a USE verb was standard, then I would probably type in commands like
the above all the time. It's only three letters; takes less time to type
than
GO THROUGH, PUSH or SIT ON.
> I suggest two possible exceptions. Here is the first one:
>
>>dig
> What do you want to dig with?
>
>>use the shovel
> ...
That's a case I hadn't thought of, but I think it should be possible to add.
The parser already understands if you write WITH THE SHOVEL when
answering the question, so it would just be a matter of adding the USE
phrase as another alternative. The only problem would be if the player
suddenly changed her mind and wrote something like:
>DIG
What do you want to dig with?
[oops, forgot the shovel back in the shed...]
>USE THE DOOR
You can't dig anything with the door!
> The second one consists of allowing the USE verb if the player has
> already figured out how to apply a certain object.
That would be desirable as well, but it's something the individual game
will have to take care of.
-- Krister Fundin
Krister Fundin
<aaroni...@gmail.com> skrev i meddelandet
news:1160781096....@k70g2000cwa.googlegroups.com...
> [...]
>
>>EXAMINE BLACK
> You can't see the stranger in Black just now.
>
> ...which behavior I find to be much less frustrating to the player than
> the standard Inform defaults.
Yes, I've been thinking about this one too. When it comes to people,
some of our default error messages are less than good:
>TALK TO BOB
You can't see any such thing.
or
>TALK TO BOB
You can't see any bob here.
I would rather like to see some messages like:
Bob isn't here.
Bob just left. (then we can type FOLLOW HIM)
You last saw Bob in the kitchen.
This will probably be included in my extension.
-- Krister Fundin
Poster
That would rock. Without getting too much into AI, I think one of the
problems with parsers is that they are not aware of what the player has
already seen or experienced. That is to say, they're not stateful.
Ideally there'd be a way to distinguish between generic objects and
people. While that would probably assume too much processing power to
handle (the parser would only know "the maiden" is different than "the
shovel" with a lot of specific rules), if you restrict this to an
awareness of people that the player has already seen in the game, that
would be reasonable and help create a more immersive experience.
-- Poster
www.intaligo.com Building, INFORM, Seasons (upcoming!)
quic...@quickfur.ath.cx
>
> <quic...@quickfur.ath.cx> skrev i meddelandet
> news:20061013202711.GB8094@crystal...
> > On Fri, Oct 13, 2006 at 07:26:39PM +0000, Krister Fundin wrote:
> >> I've been working for a while on an extension to improve the English
> >> parser in one of the popular IF systems, adding some things that I've
> >> been missing in existing parsers, or which might be appreciated by
> >> newbies, or which are completely useless but rather amusing anyway,
> >> like archaisms and slang.
> >
> > Any specific examples that we can discuss?
>
> Well, here are some of the things from the extension:
>
> - A generic USE verb (should be standard IMHO).
Good idea. So I should be able to say USE SHOVEL instead of DIG GROUND
WITH SHOVEL?
> - Better and more uniform handling of interjections:
>
> - YES
> - BOB, YES
> - SAY YES
I think TADS 3 handles these already...?
> - SAY YES TO BOB
> - TELL BOB YES
> - YES, BOB (to do)
These are nice to have. Probably should be made standard. :-)
> - THIS/THAT/THESE/THOSE/THEM as both pronouns and articles.
Um... articles? Did you mean 'demonstratives'?
> - Understanding EVERY BOOK in addition to ALL THE BOOKS.
This should be standard, too.
> - Understanding PLEASE DO X (just like in Intercal).
"PLEASE <VERB> ..." would be a nice alternative too.
> - Understanding NOTHING, NEITHER ONE, etc. as an answer to
> disambiguation questions.
Nice. Although, of limited utility, unless there's a particular scenario
you have in mind that I didn't think of?
> - Directions: GO TO THE NORTH, GO EASTWARDS, and GO SOUTH-EAST with a
> hyphen.
These should be standard too, IMHO. They're of limited utility once
you're used to the standard shorthands (NE, SE, etc.), though.
> - Understanding the ampersand where AND is understood.
Not sure about this, but harmless, I guess.
> Plus lots of synonyms and new phrasings for various standard commands,
> and some things that I can't remember now. Mostly simple stuff.
OK. What about GIVE HIM THE BOOK as a synonym for GIVE THE BOOK TO HIM?
Some games only understand the latter, although TADS 3 understands both.
(I think this should be supported by default.)
This would, of course, need to be disambiguated from GIVE HIM TO THE
LION (the preposition changes the meaning of "HIM" from indirect object
to direct object).
[...]
> > Here's an idea: we all know that natural language is ambiguous,
> > sometimes badly so (e.g., "time flies like an arrow; fruit flies
> > like a banana"). Most computer language parsers have unambiguous (or
> > mostly unambiguous) languages, and so most of the theory of parsing
> > is geared toward unambiguous grammars. But in IF, we *want* to deal
> > with natural languages, and therefore have to live with ambiguities.
> > TADS 3 has made some advancement in this area, in that if you refer
> > to an ambiguous object, it will first try to find the most logical
> > match for that object before giving up and asking the player to
> > clarify what she means.
> >
> > So what about extending this to deal with ambiguous sentence
> > structures?
>
> That's absolutely necessary, of course. Speaking of TADS 3, its
> grammar often produces several alternative parse trees for a given
> command, and the library parser has a whole range of rules for
> choosing between them. For instance, THROW BOB BALL has two possible
> meanings, but one of them can be ruled out as long as there is no
> object called "bob ball" in the story. It would be interesting if the
> verification scheme could be used to disambiguate actions as well as
> objects, but that's way beyond the scope of my extension, which is
> more about extending IFese to a larger part of the natural language.
[...]
Oh, I didn't know TADS 3 already handles that. Yet another reason to be
glad for picking TADS 3 as my first IF language. :-)
On that note, I do want to see more automation in reconciling synonyms
for actions, whether or not you feel like implementing it. :-) For
example, RAISE FLAG should map to TURN CRANK ON FLAGPOLE if there's a
flagpole with a crank in the current room, but should map to HOLD UP
FLAG if I'm surrendering on a battlefield while holding a white flag.
In other words, verbs may sometimes map to multiple actions, and which
one is meant is decided based on context.
Natural language is full of this kind of polysemy, and accounting for at
least the common cases will go a long way to improving parsing in IF.
QF
--
Food and laptops don't mix.
JDC
Krister Fundin wrote:
> >TALK TO BOB
> You can't see any bob here.
>
> I would rather like to see some messages like:
>
> Bob isn't here.
> Bob just left. (then we can type FOLLOW HIM)
> You last saw Bob in the kitchen.
In Inform 7 you can do something like this using the "printing a parser
error" activity. The following is a pretty basic first approximation:
<code>
After deciding the scope of the player while printing a parser error:
place Bob in scope.
Rule for printing a parser error when parser error is can't see any
such thing:
if the player's command includes "[Bob]" and Bob is not in the
location, say "Bob is in [location of Bob]." instead;
otherwise say "You can't see any such thing."
</code>
-JDC
Krister Fundin
<quic...@quickfur.ath.cx> skrev i meddelandet
news:20061014171912.GA8533@crystal...
> On Fri, Oct 13, 2006 at 09:10:56PM +0000, Krister Fundin wrote:
>> Well, here are some of the things from the extension:
>>
>> - A generic USE verb (should be standard IMHO).
>
> Good idea. So I should be able to say USE SHOVEL instead of DIG
> GROUND WITH SHOVEL?
Yes, and ditto for anything else that has a single obvious use.
>> - Better and more uniform handling of interjections:
>>
>> - YES
>> - BOB, YES
>> - SAY YES
>
> I think TADS 3 handles these already...?
It does, except that YES and SAY YES are synonymous, so a command
like TELL BOB TO SAY YES wouldn't have the desired effect. (It
would be trated the same way as BOB, YES.)
>> - THIS/THAT/THESE/THOSE/THEM as both pronouns and articles.
>
> Um... articles? Did you mean 'demonstratives'?
Yeah, I guess. A sample command could be: TAKE FIVE OF THEM
APPLES AND PUT THOSE ON THAT TABLE.
>> - Understanding PLEASE DO X (just like in Intercal).
>
> "PLEASE <VERB> ..." would be a nice alternative too.
That's what I meant. PLEASE TAKE THE BOOK, or TAKE THE
BOOK PLEASE.
>> - Understanding NOTHING, NEITHER ONE, etc. as an answer to
>> disambiguation questions.
>
> Nice. Although, of limited utility, unless there's a particular scenario
> you have in mind that I didn't think of?
It's a newbie thing. You don't want to answer the question, but don't
know that you can type another command instead. Typing NOTHING
or equivalent results in a short message explaining the situation.
>> - Directions: GO TO THE NORTH, GO EASTWARDS, and GO
>> SOUTH-EAST with a hyphen.
>
> These should be standard too, IMHO. They're of limited utility once
> you're used to the standard shorthands (NE, SE, etc.), though.
Sure. They're mostly for completion. I remember reading some getting-
started-with-IF texts a few years back, and more than one specifically
mentioned that hyphenated directions must not be used. I never
understood why they couldn't simply implement this and get on with it.
I suppose it's related to the 6 characters limit on dictionary words in
Z3 and earlier, but we should have gotten past that by now.
>> - Understanding the ampersand where AND is understood.
>
> Not sure about this, but harmless, I guess.
Again, it's mostly for completion.
> OK. What about GIVE HIM THE BOOK as a synonym for GIVE
> THE BOOK TO HIM? Some games only understand the latter,
> although TADS 3 understands both.
> (I think this should be supported by default.)
I agree. This happens to be a TADS 3 extension, though, so that's
already covered. ISTR that later version of Inform handle this too.
> On that note, I do want to see more automation in reconciling synonyms
> for actions, whether or not you feel like implementing it. :-) For
> example, RAISE FLAG should map to TURN CRANK ON
> FLAGPOLE if there's a flagpole with a crank in the current room, but
> should map to HOLD UP FLAG if I'm surrendering on a battlefield
> while holding a white flag. In other words, verbs may sometimes map to
> multiple actions, and which one is meant is decided based on context.
Yes, and PUT THE HAT ON doesn't map to the same action as PUT
THE KETTLE ON either. I think it would be nice if we could have a
finer distinction between actions (which always mean the same thing) and
commands (which don't necessarily). We'd have fewer actions but more
commands. Translations would be easier that way too. But this is also
beyond the scope of my extension.
-- Krister Fundin
Emily Short
JDC wrote:
> In Inform 7 you can do something like this using the "printing a parser
> error" activity. The following is a pretty basic first approximation:
>
> <code>
> After deciding the scope of the player while printing a parser error:
> place Bob in scope.
>
> Rule for printing a parser error when parser error is can't see any
> such thing:
> if the player's command includes "[Bob]" and Bob is not in the
> location, say "Bob is in [location of Bob]." instead;
> otherwise say "You can't see any such thing."
> </code>
And with slightly more complexity:
<code>
A thing can be seen or unseen.
Definition: a thing is distant if the location of it is not the
location.
After printing the name of something (called target): now the target is
seen.
After deciding the scope of the player while printing a parser error:
repeat with item running through seen things
begin;
place item in scope;
end repeat.
Rule for printing a parser error when parser error is can't see any
such thing:
if the player's command includes "[a seen distant thing]", say
"[The noun] is in [the location of noun]." instead;
otherwise
say "You can't see any such thing."
Rule for printing a parser error when parser error is can only do that
to something animate:
if the player's command includes "[a seen distant person]", say
"[The noun] is in [the location of noun]." instead;
otherwise
say "You can only do that to something animate."
</code>
There may still be some problems with this. But it does handle this
sort of thing:
>kiss bob
You can't see any such thing.
>s
Library
You can see Bob here.
>n
Kitchen
>kiss bob
Bob is in the Library.
Emily Short
Krister Fundin wrote:
> Having implemented much of what I could come up with on my own, I was
> wondering if anyone else had any ideas: something you've always thought
> that IF parsers should be able to understand or be smarter about, or
> some issue that often shows up and deserves a general solution, or just
> about any wild idea for that matter. All comments are welcome.
Two things I found in novice logs, and have tried to account for when
writing my own games for new players:
1) players using unconventional kinds of movement command, especially
GO TO [named room] and GO BACK (or variations on it) to mean "return to
the room I was just in".
2) players using adverbial phrases, especially referring to body parts
-- HIT MAN WITH FIST, etc. These are a bit harder to catch, but I have
tried putting in matches that find and delete these from a command
before parsing, sometimes with a short explanation that that "with
[body part]" isn't necessary or understood by the game.
quic...@quickfur.ath.cx
>
> <quic...@quickfur.ath.cx> skrev i meddelandet
> news:20061014171912.GA8533@crystal...
> > On Fri, Oct 13, 2006 at 09:10:56PM +0000, Krister Fundin wrote:
> >> Well, here are some of the things from the extension:
> >>
> >> - A generic USE verb (should be standard IMHO).
> >
> > Good idea. So I should be able to say USE SHOVEL instead of DIG
> > GROUND WITH SHOVEL?
>
> Yes, and ditto for anything else that has a single obvious use.
Cool.
> >> - Better and more uniform handling of interjections:
> >>
> >> - YES
> >> - BOB, YES
> >> - SAY YES
> >
> > I think TADS 3 handles these already...?
>
> It does, except that YES and SAY YES are synonymous, so a command
> like TELL BOB TO SAY YES wouldn't have the desired effect. (It
> would be trated the same way as BOB, YES.)
Hmm. That would be odd... although I can't confirm if TADS 3 does this
from a cursory test.
> >> - THIS/THAT/THESE/THOSE/THEM as both pronouns and articles.
> >
> > Um... articles? Did you mean 'demonstratives'?
>
> Yeah, I guess. A sample command could be: TAKE FIVE OF THEM APPLES AND
> PUT THOSE ON THAT TABLE.
Hmm. I'd use "THE" instead of "THEM", although I guess it's harmless for
the parser to be lenient here.
[...]
> >> - Understanding NOTHING, NEITHER ONE, etc. as an answer to
> >> disambiguation questions.
> >
> > Nice. Although, of limited utility, unless there's a particular scenario
> > you have in mind that I didn't think of?
>
> It's a newbie thing. You don't want to answer the question, but don't
> know that you can type another command instead. Typing NOTHING
> or equivalent results in a short message explaining the situation.
OK.
[...]
> > On that note, I do want to see more automation in reconciling
> > synonyms for actions, whether or not you feel like implementing it.
> > :-) For example, RAISE FLAG should map to TURN CRANK ON FLAGPOLE if
> > there's a flagpole with a crank in the current room, but should map
> > to HOLD UP FLAG if I'm surrendering on a battlefield while holding a
> > white flag. In other words, verbs may sometimes map to multiple
> > actions, and which one is meant is decided based on context.
>
> Yes, and PUT THE HAT ON doesn't map to the same action as PUT THE
> KETTLE ON either. I think it would be nice if we could have a finer
> distinction between actions (which always mean the same thing) and
> commands (which don't necessarily). We'd have fewer actions but more
> commands. Translations would be easier that way too. But this is also
> beyond the scope of my extension.
[...]
Bingo. I think you've hit upon the key here: verbs and actions are
different things, albeit related, and we'd like to automatically handle
ambiguous mappings from verbs to actions where possible. I think it
shouldn't be *too* hard to extend the current TADS 3 system to handle
this: it already goes through all ambiguous nouns, evaluating the
"logicalness" of each combination of objects, and picking the one that
seems most likely (or prompting the player to clarify what she means).
Now all we need is to do that for different actions as well. So for each
verb, there may be one or more associated actions, and we simply
evaluate the "logicalness" of each possible action as before (which
yields the most "logical" combination of objects for each of the
actions), and pick the action which has the highest "logical" value.
QF
--
Life is too short to run proprietary software. -- Bdale Garbee
she's long gone
Jim Aikin wrote:
> Seems to me the Inform response, though clunky, is fairly clever. The parser
> avoids either admitting or denying that it knows the word. Since either
> admitting it or denying it might be a spoiler, this is a good option.
This is solvable if the game has a way to know which things the player
is aware of, and which he isn't. That's not very difficult, nor is it
much more work to produce something like
"You last saw the apple pie on the kitchen table."
Daryl McCullough
>I don't believe that hiding the dictionary from the player is a
>good way to make games difficult. And in addition I'm still not
>convinced that letting the player query the dictionary is liable
>to spoil anything.
I certainly don't want to hide information from the player in
order to make things more *difficult*, but I think that hiding
information from the player can sometimes heighten the emotional
impact of a scene. If you know that the game is going to involve
ghosts, or aliens, or evil robots, or something, then it takes
a little bit of the edge off a mystery. And if the word "ghost"
is in the dictionary, then you can bet the game is about ghosts.
Benjamin Caplan
I'm cross-posting this to rgif because I think that we really need a
players'-side view on this question. It's the kind of thing that beta
testing was invented for.
So, players of interactive fiction, what kinds of annoyances and
frustrations do you most often experience with the IF parser?
(Yes, I know there's a lot of crossover between the r*ifs.)
Richard Bos
> On Fri, Oct 13, 2006 at 09:10:56PM +0000, Krister Fundin wrote:
> >
> > <quic...@quickfur.ath.cx> skrev i meddelandet
> > news:20061013202711.GB8094@crystal...
> > > On Fri, Oct 13, 2006 at 07:26:39PM +0000, Krister Fundin wrote:
> > >> I've been working for a while on an extension to improve the English
> > >> parser in one of the popular IF systems, adding some things that I've
> > >> been missing in existing parsers, or which might be appreciated by
> > >> newbies, or which are completely useless but rather amusing anyway,
> > >> like archaisms and slang.
> > >
> > > Any specific examples that we can discuss?
> >
> > Well, here are some of the things from the extension:
> >
> > - A generic USE verb (should be standard IMHO).
>
> Good idea. So I should be able to say USE SHOVEL instead of DIG GROUND
> WITH SHOVEL?
Yes. You'll also be able to USE SHOVEL instead of HIT MUGGER WITH
SHOVEL. If you're being mugged in a garden, USE SHOVEL will use the
random number generator to decide which of the two possible actions you
meant.
> > - THIS/THAT/THESE/THOSE/THEM as both pronouns and articles.
>
> Um... articles? Did you mean 'demonstratives'?
Anyway, they are all already supported as pronouns in Inform 6; as
demonstratives, their value is limited. When I say GET THOSE BOOKS,
_which_ "those books" do I mean? IRL, it's easy to point, but that's
harder on a computer screen.
> > - Understanding EVERY BOOK in addition to ALL THE BOOKS.
>
> This should be standard, too.
Already the case in Inform 6.
> > - Understanding PLEASE DO X (just like in Intercal).
>
> "PLEASE <VERB> ..." would be a nice alternative too.
PLEASE REFRAIN FROM SUPPORTING PLEASE.
> > Plus lots of synonyms and new phrasings for various standard commands,
> > and some things that I can't remember now. Mostly simple stuff.
>
> OK. What about GIVE HIM THE BOOK as a synonym for GIVE THE BOOK TO HIM?
> Some games only understand the latter, although TADS 3 understands both.
Inform, too.
Richard
Richard Bos
> <quic...@quickfur.ath.cx> skrev i meddelandet
> > On Fri, Oct 13, 2006 at 09:10:56PM +0000, Krister Fundin wrote:
> >> - THIS/THAT/THESE/THOSE/THEM as both pronouns and articles.
> >
> > Um... articles? Did you mean 'demonstratives'?
>
> Yeah, I guess. A sample command could be: TAKE FIVE OF THEM
> APPLES AND PUT THOSE ON THAT TABLE.
"Them apples"? That's bad English. Anyway, which "that" table? Just the
single table that's present? Then "the table" works just as well.
Richard
Krister Fundin
"Richard Bos" <ral...@xs4all.nl> skrev i meddelandet
news:45324b04...@news.xs4all.nl...
> "Krister Fundin" <fun...@yahoo.com> wrote:
>
>> TAKE FIVE OF THEM APPLES AND PUT THOSE ON THAT
>> TABLE.
>
> "Them apples"? That's bad English.
Regional maybe -- I wouldn't know. My dictionary mentions this
phrasing under possible uses for "them".
> Anyway, which "that" table? Just the single table that's present? Then
> "the table" works just as well.
Certainly. But someone could still conceivably type "that table", and
there's no particular reason not to allow it.
-- Krister Fundin
JDC
Richard Bos wrote:
> > Yeah, I guess. A sample command could be: TAKE FIVE OF THEM
> > APPLES AND PUT THOSE ON THAT TABLE.
>
> "Them apples"? That's bad English. Anyway, which "that" table? Just the
> single table that's present? Then "the table" works just as well.
Yeah, it should really be: TAKE FIVE OF THEM APPLES AND PUT THOSE ON
THAT THERE TABLE.
-JDC
Neil Cerutti
In English it seems like a simple enhancement. I say why not
accept regional dialects when it's so cheap?
--
Neil Cerutti
Eric Eve
news:pMWXg.6719
> Here's a bigger topic: There are situations in which 'crawl' and
> 'go' may as well be synonymous, but there are also situations
> (such as a low tunnel or a narrow ledge) in which the author might
> reasonably want to insist that the player crawl. So if there were
> some way to alert the parser about situationally splittable
> partial synonyms.... Well, it's worth thinking about.
At least in TADS 3, I6 and I7 this is already possible, at least for
game authors (who would have to be the people to deal with this
level of detail, rather than library or extension writers). All
three systems allow you to check what verb the player actually
typed, so that if CRAWL and GO were synonymous in 90% of cases
(making it convenient to have them trigger the same action) in the
other 10% of cases you could check the player's input to split the
responses to the two verbs. This doesn't seem to require any new
standard parser features, unless there was something else you had in
mind.
-- Eric
Eric Eve
<quic...@quickfur.ath.cx> wrote in message
news:20061014171912.GA8533@crystal...
> On that note, I do want to see more automation in reconciling
> synonyms
> for actions, whether or not you feel like implementing it. :-) For
> example, RAISE FLAG should map to TURN CRANK ON FLAGPOLE if
> there's a
> flagpole with a crank in the current room, but should map to HOLD
> UP
> FLAG if I'm surrendering on a battlefield while holding a white
> flag.
> In other words, verbs may sometimes map to multiple actions, and
> which
> one is meant is decided based on context.
I'd have thought this kind of thing was up to individual game
authors to sort out; libraries and extensions can hardly be expected
to have a sufficiently detailed knowledge of particular game worlds
(many games won't have flags at all; those that do might use them in
all sorts of different ways), while conversely any decent existing
IF system will allow an author to vary what a command does according
to context (it would be difficult to write decent IF without this
ability). So I'm not sure whether this amounts to much more in
practice than a plea for authors to be a bit smarter about
customising the way some commands interact with some game objects.
To expand just a little, I see it as the job of the general parser
(as supplied by the library or an extension) to parse the player's
input (RAISE FLAG, HOIST THE FLAG, RAISE THE GREEN FLAG or whatever)
so that it resolves to, say, the Raise action and the greenFlag
object (after taking into account scope and any other such
considerations the parser uses to resolve ambiguity). It's then up
to the game author to program what performing the Raise action on
the greenFlag object actually does (if it's not simply some
default), and that task surely includes checking for context, e.g.:
instead of raising the green flag when the player can touch the
flagpole:
try turning the crank.
Or
greenFlag: Thing 'green flag*flag' 'green flag'
...
dobjFor(Raise) maybeRemapTo(actor.canTouch(flagPole), Turn, crank)
;
-- Eric
Nathan
> So, players of interactive fiction, what kinds of annoyances and
> frustrations do you most often experience with the IF parser?
I don't know whether this is a function of the parser *per se*, but
I've always been bothered by games arbitrarily changing the
antecedent of IT. This was a particular problem with Infocom
games, but I've experienced it with recent games too.
Somewhat related, but maybe I'm alone here: I dislike
maintaining a strict distinction between IT and THEM, such
that I can't refer to the last object as IT if it's plural.
Eric Eve
"Nathan" <nts...@netscape.net> wrote in message
news:1161012770.9...@k70g2000cwa.googlegroups.com...
> I don't know whether this is a function of the parser *per se*,
> but
> I've always been bothered by games arbitrarily changing the
> antecedent of IT. This was a particular problem with Infocom
> games, but I've experienced it with recent games too.
If it truly is arbitrary then it's likely to be annoying. Ideally a
parser should try to deduce what a player most likely means by IT in
terms of the last noun the player explicitly referred to. But there
are two problems with this seemingly simple rule:
(1) The player may just have referred to two objects, e.g. PUT
THE BALL IN THE BOWL. If the player issues the command TAKE IT on
the next turn, does IT mean the ball or the bowl? (I'd personally go
for the ball in this situation, but it's conceivable that the player
meant the bowl, but the parser can't be expected to rad the player's
mind here).
(2) The game may have responded to the player's last command with
text that calls attention to a particular object not previously
mentioned, e.g.:
>LOOK UNDER CARPET
Under the carpet you find a gleaming diamond.
A player who types TAKE IT next probably means IT to refer to the
diamond rather than the carpet; is it arbitrary to change the
antecedent in such a case in anticipation of this piece of player
psychology? Or should one stick to the rule that IT must refer to
the noun the player last refer to:
>TAKE IT
The carpet is too heavy for you to carry around with you.
> Somewhat related, but maybe I'm alone here: I dislike
> maintaining a strict distinction between IT and THEM, such
> that I can't refer to the last object as IT if it's plural.
This is a bit double-edged. Where an object is ambiguously plural
(e.g. a pair of shoes), I'd agree with you: IT could naturally refer
to the pair and THEM to the shoes, so a player could reasonably use
either pronoun. In other contexts it's more helpful to the player to
maintain a strict distinction:
>PUT GRAPES IN BOWL.
IT now naturally refers to the bowl, and THEM to the grapes.
Or even
>X BOWL
It's full of grapes.
>X GRAPES
They're green and round.
>TAKE IT
[The bowl or the grapes? I think the most reasonable expectation is
that this should be the bowl, and that thad the player meant the
grapes s/he should have typed TAKE THEM. If, however, we had:
>X BOWL
In the bowl is a bunch of grapes.
Then immediately after we've referred to the grapes (X BUNCH or X
GRAPES) then IT perhaps most naturally refers to the bunch.
So it's hard to generalize!
-- Eric
quic...@quickfur.ath.cx
>
> "Richard Bos" <ral...@xs4all.nl> skrev i meddelandet
> news:45324b04...@news.xs4all.nl...
> > "Krister Fundin" <fun...@yahoo.com> wrote:
> >
> >> TAKE FIVE OF THEM APPLES AND PUT THOSE ON THAT
> >> TABLE.
> >
> > "Them apples"? That's bad English.
>
> Regional maybe -- I wouldn't know. My dictionary mentions this
> phrasing under possible uses for "them".
It's slang. Slang is not necessarily "incorrect", just that you wouldn't
use it outside of an informal, with-my-good-friends context.
QF
--
One who has not yet appreciated the beauty of language is not worthy to
bemoan its flaws.
Steve
WTF is wrong with Intercal? By all accounts it is a perfectly
reasonable language for general computing purposes. Sure, it may be a
little wierd, but that's just part of its charm.
Regards,
Steve
quic...@quickfur.ath.cx
>
> <quic...@quickfur.ath.cx> wrote in message
> news:20061014171912.GA8533@crystal...
>
> > On that note, I do want to see more automation in reconciling
> > synonyms for actions, whether or not you feel like implementing it.
> > :-) For example, RAISE FLAG should map to TURN CRANK ON FLAGPOLE if
> > there's a flagpole with a crank in the current room, but should map
> > to HOLD UP FLAG if I'm surrendering on a battlefield while holding a
> > white flag. In other words, verbs may sometimes map to multiple
> > actions, and which one is meant is decided based on context.
>
> I'd have thought this kind of thing was up to individual game authors
> to sort out; libraries and extensions can hardly be expected to have a
> sufficiently detailed knowledge of particular game worlds
That's not my point at all; the point is that the context, which is game
world dependent, is specified by the author, and based on this
information the library maps verbs differently.
> (many games won't have flags at all; those that do might use them in
> all sorts of different ways), while conversely any decent existing IF
> system will allow an author to vary what a command does according to
> context (it would be difficult to write decent IF without this
> ability). So I'm not sure whether this amounts to much more in
> practice than a plea for authors to be a bit smarter about customising
> the way some commands interact with some game objects.
My point was that this customisation should be more automated than it
currently is.
> To expand just a little, I see it as the job of the general parser (as
> supplied by the library or an extension) to parse the player's input
> (RAISE FLAG, HOIST THE FLAG, RAISE THE GREEN FLAG or whatever) so that
> it resolves to, say, the Raise action and the greenFlag object (after
> taking into account scope and any other such considerations the parser
> uses to resolve ambiguity).
Yes, this is what I was driving at. How easy is it under the current
TADS 3 system to do this?
AFAIK, if I want a non-standard verb as a synonym (e.g. "hoist") I have
to actually go through the trouble of defining a Hoist verb, and
possibly a HoistAction if I anticipate the verb 'hoist' to mean
something else in another part of the game, and add remapTo()'s for
different objects for which the action is possible. I was hoping for a
cleaner separation between verb and action, such that the author could
simply list a set of verb rules and specify (somewhere) that they map to
a certain action. E.g., something to the effect of:
mapPhraseToAction [
'raise {greenFlag}',
'hoist {greenFlag}',
'turn {flagpoleCrank}',
... etc.
] -> [ RaiseAction, greenFlag ];
greenFlag : Thing {
...
dobjFor(RaiseAction) { /* raise the flag */ }
}
and then somewhere else, you may have something like:
mapPhraseToAction [
'hoist car [with crane]'
'lift car [with crane]'
'pick up car [with crane]'
...
] -> [ LiftWithAction, theCar, theCrane ];
The library then collects all of these phrase mappings, and figures out
that if the verb 'hoist' is used with an object, it should check whether
the object is greenFlag or theCar, and map it to [RaiseAction,
greenFlag] or [LiftWithAction, theCrane], respectively.
> It's then up to the game author to program what performing the Raise
> action on the greenFlag object actually does (if it's not simply some
> default), and that task surely includes checking for context, e.g.:
>
> instead of raising the green flag when the player can touch the
> flagpole:
> try turning the crank.
>
> Or
>
> greenFlag: Thing 'green flag*flag' 'green flag'
> ...
> dobjFor(Raise) maybeRemapTo(actor.canTouch(flagPole), Turn, crank)
>
> ;
[...]
What if you also want to use the verb 'turn' in, say, the phrase TURN
AROUND? Or maybe, if the game has a polymorphic PC, TURN INTO A FROG. I
know this can all be done if the author defines enough new verb rules
and remappings, but I think games would benefit a lot more if the
library could handle a lot of this tedious work more automatically.
(Many authors would simply give up if too much work is involved when all
they want is to specify an alternate phrasing of a particular action.)
The verb/action distinction would help a lot in simplifying the code
required to implement TURN THE CRANK, TURN AROUND, and TURN INTO A FROG
in the same game (with all the possible alternate phrasings and their
respective verbs).
Or maybe there's already a clean way of doing this and I'm just speaking
out of ignorance.
QF
--
This is not a sentence.
Andrew Plotkin
>
> "Nathan" <nts...@netscape.net> wrote in message
> news:1161012770.9...@k70g2000cwa.googlegroups.com...
> > I don't know whether this is a function of the parser *per se*,
> > but
> > I've always been bothered by games arbitrarily changing the
> > antecedent of IT. This was a particular problem with Infocom
> > games, but I've experienced it with recent games too.
>
> If it truly is arbitrary then it's likely to be annoying. Ideally a
> parser should try to deduce what a player most likely means by IT in
> terms of the last noun the player explicitly referred to.
Inform 6 has long had a feature (and I'd rather put that in
nasty-quotes) where IT refers to the last noun that the *game*
explicitly referred to. So "inventory" and "look" change the referent.
(And if "look" mentions a person, the referent of "he" or "she"
changes. Etc.)
I believe Inform 7 has inherited that feature. It can be turned off,
but since authors don't know about it, they don't consider the
question.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the borogoves..."
*
Bush's biggest lie is his claim that it's okay to disagree with him. As soon as
you *actually* disagree with him, he sadly explains that you're undermining
America, that you're giving comfort to the enemy. That you need to be silent.
Emily Short
Andrew Plotkin wrote:
> Inform 6 has long had a feature (and I'd rather put that in
> nasty-quotes) where IT refers to the last noun that the *game*
> explicitly referred to. So "inventory" and "look" change the referent.
> (And if "look" mentions a person, the referent of "he" or "she"
> changes. Etc.)
>
> I believe Inform 7 has inherited that feature. It can be turned off,
> but since authors don't know about it, they don't consider the
> question.
I keep forgetting to add this to the feature-change-requests list, but
I am doing so now.
Adam Thornton
You have missed both the point and the joke. Also, name *one* such
account. It's perfectly reasonable in the same sense that Brainf*ck is
perfectly reasonable.
Adam
Jim Aikin
There may be even easier ways to do it. In I6, I'd try creating two separate
verbs, and then do something like this:
[ CrawlSub; <<Go noun>>; ];
As a first approximation, that would redirect the 'crawl' action everywhere
except where I want to intercept it somehow.
Truth be told, given the existing languages' ability to check what the
player actually typed, are any new parser features actually needed? Probably
not, if the author is willing to hack her way through whatever weird cases
may come up.
I think Krister was looking for feedback about what may come up often enough
to be worth implementing as a general case. I don't claim to have any
insights into what would be more useful to more people more of the time ...
I'm just tossing out ideas.
--JA
Autymn D. C.
> So, players of interactive fiction, what kinds of annoyances and
> frustrations do you most often experience with the IF parser?
That I can't use 'search all' or 'get all' or 'x all' in nearly all
games/imps. :D
I would like to anwrite the dictionary to take original and consistent
ME, sheerly grammatic and literal-verbal input. 'go', for example,
means "try". So 'go west' is verbally wrong because it means "try
west". So I'd replace it with something like 'meet west' or 'see
west', where "west" is anything. IOW, I want my own verbs. Then
again, we don't need a verb for directions. This is like the old
debate about the one or two clicks needed to open icòns rather than
entry in a command line. If the parser were verbal, 'west' would
return 'Huh?' or "'west' is not a verb I recognise.". (But it's
sentimental.) IF's grammar is markedly American (as in the natives)
that conjugats by space, over European that conjugats by time.
"Imagine" a gameworld without turns and rooms and actions. (Never
mind--there are, but they're loosser.) Commands are more contextual
and treelike. 'undo' is not global but is aware of what [manual]
commands are neded to take back the last, as well as give back with
'ando'. How about further commands like 'rear' and 'get' to plan and
recall.
As for spots, in a "room"'s description one is compelled to write where
every other "room" or thing is off a compass direction, when we don't
think in terms of the compass but with walls, paths, and our own head
and what we ken therewith. If you can ken it, you can track it, and
you don't need to choose which global direction to follow to meet it.
So, uh, let's abolish roomnames, and program a bunch of objects with
letters and lotters (base-64, like youtube) as tags/flags that link to
each other in nearness. "But rooms are real!" Yeah, put whatever name
it feels like in the description, but it'll be dead in the map. 'call
here [enth] spot' to backtrack if you want, otherwise 'among', 'about',
'along', 'awith', 'ahead', 'ahind', 'astride', 'aside', 'atop', 'abot'.
(Well lookkee there, I'v ten fingers as well.)
So there can be duplicate items that differ onely in their tag. (Tags
become slots if they're on you.) For commands without demonstrativs,
the "it" or "who" or "deed" will be in bold in the output. The
gameworld is a great piece of furniture.
Time needs a meetly list as well, such as to make 'wait' and 'yes' more
sòfisticated. I could use the same ten, with i- or y- instead of a-,
where many of the offways are in imaginary or mental dimensions.
'wait' is 'istride', 'help' is 'iside'; 'ilong' and 'ihead' apply if
the player or writere pland (rearrd) a [hi]story that the player is
aware of (or iware of). (Now this feels like Puzz3D or 3D chess!)
'itop' and 'ibot' are for how byssy you'll go. 'among' and 'imong' are
by default after a 'meet'.
-Aut
>22,19
Gene Wirchenko
[snip]
>OH, and PLEASE DO NOT program your parsers in Intercal!
Why not? BRAINFUCK has already been done.
Sincerely,
Gene Wirchenko
Computerese Irregular Verb Conjugation:
I have preferences.
You have biases.
He/She has prejudices.
Eric Eve
news:20061016163521.GB19168@crystal...
> On Mon, Oct 16, 2006 at 04:28:17PM +0100, Eric Eve wrote:
>>
>> <quic...@quickfur.ath.cx> wrote in message
>> news:20061014171912.GA8533@crystal...
>>
>> > On that note, I do want to see more automation in reconciling
>> > synonyms for actions, whether or not you feel like implementing
>> > it.
>> > :-) For example, RAISE FLAG should map to TURN CRANK ON
>> > FLAGPOLE if
>> > there's a flagpole with a crank in the current room, but should
>> > map
>> > to HOLD UP FLAG if I'm surrendering on a battlefield while
>> > holding a
>> > white flag. In other words, verbs may sometimes map to
>> > multiple
>> > actions, and which one is meant is decided based on context.
>>
>> I'd have thought this kind of thing was up to individual game
>> authors
>> to sort out; libraries and extensions can hardly be expected to
>> have a
>> sufficiently detailed knowledge of particular game worlds
>
> That's not my point at all; the point is that the context, which
> is game
> world dependent, is specified by the author, and based on this
> information the library maps verbs differently.
I don't follow how this can be "not your point at all", simply
because I suggest something might be better handled in game code
rather than library code (when it clearly seems to addressing the
same issue, unless we really are talking past each other here).
>> (many games won't have flags at all; those that do might use them
>> in
>> all sorts of different ways), while conversely any decent
>> existing IF
>> system will allow an author to vary what a command does according
>> to
>> context (it would be difficult to write decent IF without this
>> ability). So I'm not sure whether this amounts to much more in
>> practice than a plea for authors to be a bit smarter about
>> customising
>> the way some commands interact with some game objects.
>
> My point was that this customisation should be more automated than
> it
> currently is.
Perhaps you'd need to make your point a bit more specific to help me
to understand what you're actually driving at then. What kind of
automation would belong in a library to make it easier to customise
a game in this respect?
>> To expand just a little, I see it as the job of the general
>> parser (as
>> supplied by the library or an extension) to parse the player's
>> input
>> (RAISE FLAG, HOIST THE FLAG, RAISE THE GREEN FLAG or whatever) so
>> that
>> it resolves to, say, the Raise action and the greenFlag object
>> (after
>> taking into account scope and any other such considerations the
>> parser
>> uses to resolve ambiguity).
>
> Yes, this is what I was driving at.
Ah, so it turns out I haven't missed your point after all?
> How easy is it under the current TADS 3 system to do this?
Extremely. See below.
> AFAIK, if I want a non-standard verb as a synonym (e.g. "hoist") I
> have
> to actually go through the trouble of defining a Hoist verb, and
> possibly a HoistAction if I anticipate the verb 'hoist' to mean
> something else in another part of the game, and add remapTo()'s
> for
> different objects for which the action is possible.
That's right. Although the remaps could be added to classes if you
have a bunch of objects that behave the same way, to save
customizing a whole lot of objects the same way.
> I was hoping for a
> cleaner separation between verb and action, such that the author
> could
> simply list a set of verb rules and specify (somewhere) that they
> map to
> a certain action. E.g., something to the effect of:
>
> mapPhraseToAction [
> 'raise {greenFlag}',
> 'hoist {greenFlag}',
> 'turn {flagpoleCrank}',
> ... etc.
> ] -> [ RaiseAction, greenFlag ];
But apart from anything else (such as not being standard TADS 3
syntax) this doesn't look like it's performing the kind of context
checking you originally asked for.
> greenFlag : Thing {
> ...
> dobjFor(RaiseAction) { /* raise the flag */ }
> }
>
> and then somewhere else, you may have something like:
>
> mapPhraseToAction [
> 'hoist car [with crane]'
> 'lift car [with crane]'
> 'pick up car [with crane]'
> ...
> ] -> [ LiftWithAction, theCar, theCrane ];
>
> The library then collects all of these phrase mappings, and
> figures out
> that if the verb 'hoist' is used with an object, it should check
> whether
> the object is greenFlag or theCar, and map it to [RaiseAction,
> greenFlag] or [LiftWithAction, theCrane], respectively.
I'm not sure why this is significantly better than defining the
appropriate remappings on the greenFlag and theCar objects, which is
the way TADS 3 is designed to work. I suppose it would be possible
to define custom grammar tokens that matched the car object or the
flag object or whatever and then write custom grammar rules, but
again this would have to happen in the game rather than the library,
and it actually feels a more difficult way to achieve the same
object to me.
Well, it's pretty clean: you simply define different actions that
match different grammars:
Turn (as in TURN THE CRANK) is already defined in the standard
library, so you'd then define:
DefineIAction(TurnAround)
execAction()
{
"{You/he} turn{s} round. ";
}
;
VerbRule(TurnAround)
('turn' | 'spin') ('round' | 'around')
: TurnAroundAction
verbPhrase = 'turn/turning around'
;
DefineTopicAction(TurnInto)
execAction()
{
/* code for handling this */
}
;
VerbRule(TurnInto)
'turn' 'into' singleTopic
: TurnIntoAction
verbPhrase = 'turn/turning (into what)'
;
IOW TADS 3 already has a verb/action distinction built in. (So do
Inform and Hugo, though it works a little differently; the same is
probably true of other languages besides).
-- Eric
Richard Bos
> "Richard Bos" <ral...@xs4all.nl> skrev i meddelandet
> > "Krister Fundin" <fun...@yahoo.com> wrote:
> >
> >> TAKE FIVE OF THEM APPLES AND PUT THOSE ON THAT
> >> TABLE.
> >
> > "Them apples"? That's bad English.
>
> Regional maybe -- I wouldn't know. My dictionary mentions this
> phrasing under possible uses for "them".
With an asterisk in front, I hope? It's not correct in any civilised
form of English.
> > Anyway, which "that" table? Just the single table that's present? Then
> > "the table" works just as well.
>
> Certainly. But someone could still conceivably type "that table", and
> there's no particular reason not to allow it.
And in fact "that table" appears to work in Inform 6, though I suspect
this is an accident of its parser rather than by design.
Richard
Richard Bos
> In rec.games.int-fiction, Eric Eve <eric...@nospamhmc.ox.ac.uk> wrote:
> >
> > "Nathan" <nts...@netscape.net> wrote in message
> > news:1161012770.9...@k70g2000cwa.googlegroups.com...
> > > I don't know whether this is a function of the parser *per se*, but
> > > I've always been bothered by games arbitrarily changing the
> > > antecedent of IT. This was a particular problem with Infocom
> > > games, but I've experienced it with recent games too.
> >
> > If it truly is arbitrary then it's likely to be annoying. Ideally a
> > parser should try to deduce what a player most likely means by IT in
> > terms of the last noun the player explicitly referred to.
>
> Inform 6 has long had a feature (and I'd rather put that in
> nasty-quotes) where IT refers to the last noun that the *game*
> explicitly referred to. So "inventory" and "look" change the referent.
> I believe Inform 7 has inherited that feature. It can be turned off,
> but since authors don't know about it, they don't consider the
> question.
It can also be turned off in Inform 6, by declaring MANUAL_PRONOUNS. I
don't know how many authors know about that. It's not in the DM4; IIRC
it was added in a later version of the library. It only turns off the
ittification of objects mentioned in inventories and room descriptions,
but that is enough to stop it from irritating me.
Richard
Steve
> In article <1161016012.3...@k70g2000cwa.googlegroups.com>,
> Steve <steve...@yahoo.ca> wrote:
> >
> >Adam Thornton wrote:
> >> In article <1160780258.6...@b28g2000cwb.googlegroups.com>,
> >> <constantl...@gmail.com> wrote:
> >> >OH, and PLEASE DO NOT program your parsers in Intercal!
> >>
> >> ITYM, "PLEASE REFRAIN FROM progamming your parsers in INTERCAL!"
> >
> >WTF is wrong with Intercal? By all accounts it is a perfectly
> >reasonable language for general computing purposes. Sure, it may be a
> >little wierd, but that's just part of its charm.
>
> You have missed both the point and the joke. Also, name *one* such
> account.
The references fall under the category of 'personal correspondence',
but I assure you that the account is sound. I will have to contact a
few of the authors and see if they will mind if I post their testimony.
You don't mind waiting a little bit so I can properly support my
argument, do you?
> It's perfectly reasonable in the same sense that Brainf*ck is
> perfectly reasonable.
So long as it's between two consenting adults, I see no problem with
Brainf*cking.
Regards,
Steve
Adam Thornton
Steve <steve...@yahoo.ca> wrote:
>The references fall under the category of 'personal correspondence',
>but I assure you that the account is sound. I will have to contact a
>few of the authors and see if they will mind if I post their testimony.
> You don't mind waiting a little bit so I can properly support my
>argument, do you?
Sure.
Note that I'm not disputing that you CAN write functional code in
INTERCAL. Merely that it is no more a suitable language for
understandable algorithmic expression than is Brainf*ck. Well, OK, a
*little* more.
It was, after all, I who gave the compiler for Object-Oriented INTERCAL
(on the late lamented assurdo.com, and I've never found the sources
anywhere else, and I don't think I kept a copy) its name: "oo, ick".
This was back in the days when embedded spaces and commas in file names
were still objects of horror, rather than Just Something Windows Users
Did So You'd Better Get Used To It.
Adam
Krister Fundin
"Autymn D. C." <lysd...@sbcglobal.net> skrev i meddelandet
news:1161024267....@m73g2000cwd.googlegroups.com...
> I would like to anwrite the dictionary to take original and consistent
> ME, sheerly grammatic and literal-verbal input. 'go', for example,
> means "try". So 'go west' is verbally wrong because it means "try
> west". So I'd replace it with something like 'meet west' or 'see
> west', where "west" is anything. IOW, I want my own verbs.
Hm... Perhaps a trainable parser would be useful to this person, I.E.
one where you can mess with its grammar at runtime:
to meet is a verb
meet means go
meet west
Similarly, one could add missing synonyms and perhaps even classify
objects in various ways:
a book is a reading material
a newspaper is a reading material
take all the reading materials
Mostly a pointless gimmick though.
-- Krister Fundin
Krister Fundin
"Benjamin Caplan" <celestial...@gmail.com> skrev i meddelandet
news:1160939790....@e3g2000cwe.googlegroups.com...
> So, players of interactive fiction, what kinds of annoyances and
> frustrations do you most often experience with the IF parser?
As for Inform games, there's one particular thing that has always
annoyed me: that they don't understand PUT THE HAT ON. It's like
a big black hole in the grammar definitions. Also, ISTR that commands
such as TAKE THE HAT AND WEAR IT don't work too well.
As for TADS 3 games, one thing that's come up a few times is the
parsing of disambiguation responses in cases like this one:
> READ BOOK
Which book do you mean, the book on the shelf or the book on the
desk?
Here, I have a tendency to just write "desk", which the parser doesn't
accept. You have to write "the one on the desk" or somesuch. It would
be nice if the answer could be treated the same way as a SpecialTopic as
a last resort.
-- Krister Fundin
Autymn D. C.
don, doff, both, all
JDC
Krister Fundin wrote:
> Hm... Perhaps a trainable parser would be useful to this person, I.E.
> one where you can mess with its grammar at runtime:
>
> to meet is a verb
> meet means go
> meet west
>
> Similarly, one could add missing synonyms and perhaps even classify
> objects in various ways:
>
> a book is a reading material
> a newspaper is a reading material
> take all the reading materials
>
> Mostly a pointless gimmick though.
Actually, this might be kind of neat if the game could be set up to
read these synonyms from a file. Then each player could set up his own
aynonym file and have it loaded every time he played a game. I could
see this being particularly useful for playing a game which was not in
your native language. Someone could create a mapping of the most common
verbs from various languages (actually, I think someone proposed this
in another thread a while back). If you know enough of a language to be
able to read the output (with a dictionary, perhaps), it can still be
difficult to remember the words for a command you want to enter...
-JDC
quic...@quickfur.ath.cx
OK, I didn't make myself clear then. What I meant was that I'd like to
see more *automation* in specifying how to deal with these alternative
phrasings. The current approach involves creating new verbs and then
associating said verbs with actions, possibly remapping verbs for
certain objects, etc.. What I'd prefer is if the author could simply
say something to the effect of "RAISE FLAG should be synonymous to TURN
CRANK ON FLAGPOLE", and the library figures out that it should create a
new verb for "RAISE", and map that to TURN CRANK ON FLAGPOLE when the
flagpole is in context. Then when the betatesters come back to the
author and asks for another alternate phrasing, the author doesn't have
to create a brand new verb, add a new action, and possibly putting more
remap's into existing objects. All he has to do is to state the
alternate phrasing, and the library takes care of creating the necessary
mappings.
[...]
> >> To expand just a little, I see it as the job of the general parser
> >> (as supplied by the library or an extension) to parse the player's
> >> input (RAISE FLAG, HOIST THE FLAG, RAISE THE GREEN FLAG or
> >> whatever) so that it resolves to, say, the Raise action and the
> >> greenFlag object (after taking into account scope and any other
> >> such considerations the parser uses to resolve ambiguity).
> >
> > Yes, this is what I was driving at.
>
> Ah, so it turns out I haven't missed your point after all?
Well, my point is that this process can be made much more convenient.
> > How easy is it under the current TADS 3 system to do this?
>
> Extremely. See below.
>
> > AFAIK, if I want a non-standard verb as a synonym (e.g. "hoist") I
> > have to actually go through the trouble of defining a Hoist verb,
> > and possibly a HoistAction if I anticipate the verb 'hoist' to mean
> > something else in another part of the game, and add remapTo()'s for
> > different objects for which the action is possible.
>
> That's right. Although the remaps could be added to classes if you
> have a bunch of objects that behave the same way, to save customizing
> a whole lot of objects the same way.
It still seems awkward to me. I mean, the current system does work, but
every time you want to add a new alternate phrasing, you have to go
through the process of defining a new verb and specifying a new action
(and modifying class Thing to handle default cases, etc.). What I'd like
to be able to do is, for some object X, specify a set of phrases
(involving that object) that maps to some action A on the object. I
don't want to care if the same verb is used elsewhere; the library
should notice that some phrases across objects share the same lexical
verb, and do the necessary mappings/remappings to handle those cases.
> > I was hoping for a cleaner separation between verb and action, such
> > that the author could simply list a set of verb rules and specify
> > (somewhere) that they map to a certain action. E.g., something to
> > the effect of:
> >
> > mapPhraseToAction [
> > 'raise {greenFlag}',
> > 'hoist {greenFlag}',
> > 'turn {flagpoleCrank}',
> > ... etc.
> > ] -> [ RaiseAction, greenFlag ];
>
> But apart from anything else (such as not being standard TADS 3
> syntax) this doesn't look like it's performing the kind of context
> checking you originally asked for.
The context checking comes in when you have these phrases for multiple
objects, some of which may share the same lexical verbs (or nouns,
whichever is the case). The author shouldn't have to worry about the
fact that two different actions on two different objects happen to use
the same word to refer to the action, and so have to define the verb and
specify remappings a certain way. The library should collect all the
phrases listed for every object, sort through them, and realize that
some verb V is being used multiple times in different contexts, and so
create the necessary verb definitions and remappings for the objects in
question. This will be done in such a way that when the player uses the
verb V in different contexts, it gets mapped to the appropriate actions
as specified by the author.
> > The library then collects all of these phrase mappings, and figures
> > out that if the verb 'hoist' is used with an object, it should check
> > whether the object is greenFlag or theCar, and map it to
> > [RaiseAction, greenFlag] or [LiftWithAction, theCrane],
> > respectively.
>
> I'm not sure why this is significantly better than defining the
> appropriate remappings on the greenFlag and theCar objects, which is
> the way TADS 3 is designed to work. I suppose it would be possible to
> define custom grammar tokens that matched the car object or the flag
> object or whatever and then write custom grammar rules, but again this
> would have to happen in the game rather than the library, and it
> actually feels a more difficult way to achieve the same object to me.
The advantage to this method is that the author can potentially specify
a LOT of alternate phrasings for the same action easily. Haven't we all
encountered some game X where we knew what action to take, but the
author never thought of the way we phrased it, and so we have to guess a
phrasing that the game understood? Some of these actions can be phrased
in so many ways that it becomes very tedious for the author to account
for them all---he has to define 20 new verbs for every other action in
the game, each of which involves non-trivial amounts of code. (And then
he has to worry about what to do if those new verbs are applied to
objects that he didn't intend them to.) By having the library infer the
verb definitions and remaps automatically (as much as is possible), the
author can simply add new phrasings by adding a single line of code. It
leaves more time for the author to think about the game instead of
struggling with tedious code.
[...]
> > Or maybe there's already a clean way of doing this and I'm just
> > speaking out of ignorance.
>
> Well, it's pretty clean: you simply define different actions that
> match different grammars:
>
> Turn (as in TURN THE CRANK) is already defined in the standard
> library, so you'd then define:
>
> DefineIAction(TurnAround)
> execAction()
> {
> "{You/he} turn{s} round. ";
> }
> ;
>
> VerbRule(TurnAround)
> ('turn' | 'spin') ('round' | 'around')
> : TurnAroundAction
> verbPhrase = 'turn/turning around'
> ;
>
> DefineTopicAction(TurnInto)
> execAction()
> {
> /* code for handling this */
> }
> ;
>
> VerbRule(TurnInto)
> 'turn' 'into' singleTopic
> : TurnIntoAction
> verbPhrase = 'turn/turning (into what)'
> ;
>
> IOW TADS 3 already has a verb/action distinction built in. (So do
> Inform and Hugo, though it works a little differently; the same is
> probably true of other languages besides).
[...]
True, so it does have the facility for doing this. Still, I think that a
lot of this could be automated more than it currently is.
QF
--
Life is too short to run proprietary software. -- Bdale Garbee
Emily Short
quic...@quickfur.ath.cx wrote:
> OK, I didn't make myself clear then. What I meant was that I'd like to
> see more *automation* in specifying how to deal with these alternative
> phrasings. The current approach involves creating new verbs and then
> associating said verbs with actions, possibly remapping verbs for
> certain objects, etc.. What I'd prefer is if the author could simply
> say something to the effect of "RAISE FLAG should be synonymous to TURN
> CRANK ON FLAGPOLE", and the library figures out that it should create a
> new verb for "RAISE", and map that to TURN CRANK ON FLAGPOLE when the
> flagpole is in context.
That's an attractive idea, but it leaves a fair number of things
unspecified. Are we just matching the literal text "raise flag", or is
"flag" a thing in the game? If so, does it have to be in scope? Should
the game understand "raise [something else]" at all? If so, what will
be the default message when the player tries to raise something that
doesn't have this mapping? And so on.
Not saying there couldn't be any improvement on the way this is
currently handled in various languages, but it would be hard to make it
*quite* as automatic as you're suggesting, I think.
Eric Eve
<quic...@quickfur.ath.cx> wrote in message
news:20061018052933.GA27135@crystal...
> OK, I didn't make myself clear then. What I meant was that I'd
> like to
> see more *automation* in specifying how to deal with these
> alternative
> phrasings. The current approach involves creating new verbs and
> then
> associating said verbs with actions, possibly remapping verbs for
> certain objects, etc.. What I'd prefer is if the author could
> simply
> say something to the effect of "RAISE FLAG should be synonymous to
> TURN
> CRANK ON FLAGPOLE", and the library figures out that it should
> create a
> new verb for "RAISE", and map that to TURN CRANK ON FLAGPOLE when
> the
> flagpole is in context. Then when the betatesters come back to the
> author and asks for another alternate phrasing, the author doesn't
> have
> to create a brand new verb, add a new action, and possibly putting
> more
> remap's into existing objects. All he has to do is to state the
> alternate phrasing, and the library takes care of creating the
> necessary
> mappings.
I'm now not quite sure at what level you want this intervention; as
Emily asks in a separate post, what would you want to happen to
RAISE X (where X != flag), and are you wanting the parser to act on
the flag object or the string "flag". If the latter you could simply
do what you wanted with a StringPreParser:
StringPreParser
doParsing (str, which)
{
if(str.toLower == 'raise flag'
&& gPlayerChar.canTouch(flagPole))
return 'turn crank on flagpole';
return str;
}
;
And if that's all you wanted, you could probably write a macro so
that an author could express it a good deal more concisely, roughly
along the lines you suggest; e.g. it might be compressible to
something like:
changeCommand('raise flag', 'turn crank on handle',
gPlayerChar.canTouch(flagPole))
But this doesn't test for the flag being in scope, or for other ways
in which the player might refer to the flag. It may be someone can
come up with a syntactic short-cut that handles all this too, but to
do the job properly you have to make sure the library performs the
same kind of checks it already does, and to cut across that may risk
breaking the system. Part of the problem is that the TADS 3 parser
doesn't attempt to resolve noun phrases to objects until it's
resolved the entire phrase to an action, so unless RAISE resolves to
some action, the parser can't go on to check whether the noun phrase
entered by the player resolves to the flag object, which itself
involves not only checking whether the flag object is in scope but
whether it's the most logical available target for a 'raise'
command. Short-circuiting these steps may be possible, but unless
you're very careful, it may not be such a good idea, and may end up
being more trouble than it's worth. The problem may in any case be
somewhat more complex than you're allowing for.
> It still seems awkward to me. I mean, the current system does
> work, but
> every time you want to add a new alternate phrasing, you have to
> go
> through the process of defining a new verb and specifying a new
> action
> (and modifying class Thing to handle default cases, etc.). What
> I'd like
> to be able to do is, for some object X, specify a set of phrases
> (involving that object) that maps to some action A on the object.
> I
> don't want to care if the same verb is used elsewhere; the library
> should notice that some phrases across objects share the same
> lexical
> verb, and do the necessary mappings/remappings to handle those
> cases.
Not necessarily; if the alternative phrasing is simply a synonym for
an existing one, you simply define the new phrasing. For example, if
you want to allow INSERT X INTO X to mean the same as PUT X IN Y,
then in TADS 3 you'd simply write:
modify VerbRule(PutIn)
('put' | 'insert') dobjList ('in'| 'into') singleIobj:
;
You only need to go through defining a new Action and a new VerbRule
and then modifying Thing etc. if you're defining a totally new
Action; you don't need it to do all that just for synonyms. On the
other hand, if you are defining a completely new Action (say Raise)
you probably do need to define it properly, since if players find
that RAISE FLAG works they may well try RAISE HANDS or RAISE SHIELD
or RAISE CHILDREN, and the parser (or rather, your game) ought to
handle such attempts gracefully (or wittily, as the case may be),
and certainly not by telling players that "The word 'raise' is not
needed in this game" or "I don't understand your command" or some
such equivalent, which is what you'll probably get if you don't go
to the bother of carrying out all the necessary steps.
IOW, automation is not such a good thing if it encourages authors
not to take steps they really need to take to ensure a polished
product.
But I think I'm simply amplifying Emily's points here.
-- Eric
Matthew Slattery
> It was, after all, I who gave the compiler for Object-Oriented INTERCAL
> (on the late lamented assurdo.com, and I've never found the sources
> anywhere else, and I don't think I kept a copy) its name: "oo, ick".
http://homepages.nildram.co.uk/~intercal/
-- Matthew.
Jan Thorsby
How bout before one stars to make a game, one could fill out a form about
what standard commands one would like to have in the game, just tick off a
YES box or a NO box. (Or occasionally there could be alternative grammars
for commands one could choose between.) That way there could be lots of
semi-standard commands, but without all writers having to worry about them.
And for people who can't be bothered to fill out the form, it is set to the
normal standard verbs.
quic...@quickfur.ath.cx
>
> quic...@quickfur.ath.cx wrote:
> > OK, I didn't make myself clear then. What I meant was that I'd like
> > to see more *automation* in specifying how to deal with these
> > alternative phrasings. The current approach involves creating new
> > verbs and then associating said verbs with actions, possibly
> > remapping verbs for certain objects, etc.. What I'd prefer is if
> > the author could simply say something to the effect of "RAISE FLAG
> > should be synonymous to TURN CRANK ON FLAGPOLE", and the library
> > figures out that it should create a new verb for "RAISE", and map
> > that to TURN CRANK ON FLAGPOLE when the flagpole is in context.
>
> That's an attractive idea, but it leaves a fair number of things
> unspecified. Are we just matching the literal text "raise flag", or is
> "flag" a thing in the game?
FLAG is a thing in the game. Literal matching comes with a lot of
problems, as you & Eric point out.
> If so, does it have to be in scope?
Yes, otherwise it wouldn't make sense to refer to it. You'd probably get
a message along the lines of "you don't see a flag here".
> Should the game understand "raise [something else]" at all? If so,
> what will be the default message when the player tries to raise
> something that doesn't have this mapping? And so on.
A default message would do, I suspect. "You can't raise a [thing]" or
something along those lines.
> Not saying there couldn't be any improvement on the way this is
> currently handled in various languages, but it would be hard to make
> it *quite* as automatic as you're suggesting, I think.
I'm not expecting it to be easy. :-) But I'd like to throw in some ideas
about how one might go about implementing such a thing, so that we work
towards it.
QF
--
Who told you to swim in Crocodile Lake without life insurance??
Neil Cerutti
I like the gist of that idea. Removing grammar from a game is
harder than it needs to be.
--
Neil Cerutti
quic...@quickfur.ath.cx
>
> <quic...@quickfur.ath.cx> wrote in message
> news:20061018052933.GA27135@crystal...
>
> > OK, I didn't make myself clear then. What I meant was that I'd like
> > to see more *automation* in specifying how to deal with these
> > alternative phrasings. The current approach involves creating new
> > verbs and then associating said verbs with actions, possibly
> > remapping verbs for certain objects, etc.. What I'd prefer is if
> > the author could simply say something to the effect of "RAISE FLAG
> > should be synonymous to TURN CRANK ON FLAGPOLE", and the library
> > figures out that it should create a new verb for "RAISE", and map
> > that to TURN CRANK ON FLAGPOLE when the flagpole is in context. Then
> > when the betatesters come back to the author and asks for another
> > alternate phrasing, the author doesn't have to create a brand new
> > verb, add a new action, and possibly putting more remap's into
> > existing objects. All he has to do is to state the alternate
> > phrasing, and the library takes care of creating the necessary
> > mappings.
>
> I'm now not quite sure at what level you want this intervention; as
> Emily asks in a separate post, what would you want to happen to RAISE
> X (where X != flag), and are you wanting the parser to act on the flag
> object or the string "flag". If the latter you could simply do what
> you wanted with a StringPreParser:
No, literal matching is too restrictive, and opens another can of worms
about how the parser maps the string to the object automatically.
[...]
> Part of the problem is that the TADS 3 parser doesn't attempt to
> resolve noun phrases to objects until it's resolved the entire phrase
> to an action, so unless RAISE resolves to some action, the parser
> can't go on to check whether the noun phrase entered by the player
> resolves to the flag object, which itself involves not only checking
> whether the flag object is in scope but whether it's the most logical
> available target for a 'raise' command.
Yes, which is why I raised the idea of having the parser maintain a set
of possible verb-to-action mappings (rather than picking just one). Then
it goes through each action in the set, and does the noun phrase
resolutions for it, and stores the logicalness value somewhere. After it
has gone through all possible action mappings, it then picks the one
that yields the most logical noun phrase resolutions.
Now I don't know enough about exactly how TADS goes about this process,
so maybe my idea doesn't quite work within the framework of TADS. But it
does sound doable on its own.
[...]
> > It still seems awkward to me. I mean, the current system does work,
> > but every time you want to add a new alternate phrasing, you have to
> > go through the process of defining a new verb and specifying a new
> > action (and modifying class Thing to handle default cases, etc.).
> > What I'd like to be able to do is, for some object X, specify a set
> > of phrases (involving that object) that maps to some action A on the
> > object. I don't want to care if the same verb is used elsewhere;
> > the library should notice that some phrases across objects share the
> > same lexical verb, and do the necessary mappings/remappings to
> > handle those cases.
>
> Not necessarily; if the alternative phrasing is simply a synonym for
> an existing one, you simply define the new phrasing. For example, if
> you want to allow INSERT X INTO X to mean the same as PUT X IN Y,
> then in TADS 3 you'd simply write:
>
> modify VerbRule(PutIn)
> ('put' | 'insert') dobjList ('in'| 'into') singleIobj:
> ;
Yes, I know you can do this. :-) My point is that after you've done
this, then at some later stage in your game, you decide that you need
another action using the same verb (but different syntax, maybe a
different number of objects). Now you have to go back and define a new
VerbRule for it.
And if you upgrade the TADS library, you may have to go back and revisit
all such modifications to ensure that you don't lose the benefit of,
say, new alternative phrasings that may have been added to the library
for this action. If your game has as many alternative phrasings as I
envision, then this could be quite a daunting task. Why not rather have
the library pick up what the author wants to use, and generate the
underlying mappings automatically and ensure smooth integration of
bugfixes/enhancements/etc.?
> You only need to go through defining a new Action and a new VerbRule
> and then modifying Thing etc. if you're defining a totally new Action;
> you don't need it to do all that just for synonyms. On the other hand,
> if you are defining a completely new Action (say Raise) you probably
> do need to define it properly, since if players find that RAISE FLAG
> works they may well try RAISE HANDS or RAISE SHIELD or RAISE CHILDREN,
> and the parser (or rather, your game) ought to handle such attempts
> gracefully (or wittily, as the case may be), and certainly not by
> telling players that "The word 'raise' is not needed in this game" or
> "I don't understand your command" or some such equivalent, which is
> what you'll probably get if you don't go to the bother of carrying out
> all the necessary steps.
But if there are no CHILDREN objects in the game, the game could simply
say "you don't see any children here".
As for RAISE HANDS or other such examples, it's the author's
responsibility to handle these cases gracefully. I'm not saying that the
library will automate *everything*! (Although, IMHO, implied objects
such as body parts should be included by default in the library, perhaps
coupled with default messages to the effect of "you don't need to refer
to <bodypart> in this game").
> IOW, automation is not such a good thing if it encourages authors not
> to take steps they really need to take to ensure a polished product.
[...]
I don't know... forcing authors to get down on the nitty-gritty details
all the time does tend to frustrate the creative process, even if it
does make them think more about the details. Thinking about the details
is good, but it should be done when the author is focusing on the
details, not forced upon the author at every occasion. It is useful to
be able to make a rapid prototype of a game just to assess its
feasibility, before one starts coding every last detail into every last
object.
QF
--
Why do conspiracy theories always come from the same people??
Adam Thornton
No, that's plain old CLC-INTERCAL. It's merely twitch-inducing.
It's not Object-Oriented INTERCAL. There was also Quantum Intercal.
Adam
bogus6...@mailinator.com
pretend that her parser (whether for IF or another application)
understands natural language. If she does, I will continually be
frustrated with it, as I will not have a clear idea of what it can and
cannot handle.
I prefer the honesty of "I understand commands X, Y, and Z" to "I
understand natural language; go ahead, type complete sentences".
Natural language interfaces usually fall flat. Examples:
- Eliza
- Virtual Woman (www.virtualwoman.net), which is about on Eliza's
level.
- The parser for questions in Emily Short's "Mystery House Revisited"
If Ms. Short is reading this, the specific problem I had with her
question parser was asking (probably not in these exact words) "Where
were you when So-and-so was killed?" The parser seemed to think I was
asking "When (i.e., at what time) was So-and-so killed?".
I find it strange that Inform parses "one" through "twenty", but no
other numbers as words. (IIRC, Mr. Cadre made Varicella parse "zero",
though.) Why not make it parse either _all_ numbers as words, or
_none_? (This would decrease memory strain on the player.) Also, I find
it interesting that GET 2 MACGUFFINS is not parsed correctly, even
where GET TWO MACGUFFINS would be.
As for directions: "North-east" is not good modern English. I see no
good reason for parsers to support misspellings.
Synonyms:
- If a game has an "Elizabeth" character, the game should at least
recognize "Liz". (Who wants to type "Elizabeth" ten times if they don't
have to?)
- In any normal, non-Ad-Verbum-like game, normal synonyms for nouns
should be supported. A female receptionist should answer to "woman" (if
she is the only woman present), a pair of jeans should answer to
"pants" (at least in American English), etc. It is hard to immerse
yourself in a story if you have to keep track of exactly how things are
worded.
- It is better to support few verbs and to do so correctly, rather than
try to support too many verbs and botch it. IMHO, it is acceptable
sometimes to cue the player as to what verbs are understood in a game
(as by putting them in boldface), rather than have the player guess or
flounder.
Eric Eve
news:20061019022326.GB32368@crystal...
> On Wed, Oct 18, 2006 at 09:17:12AM +0100, Eric Eve wrote:
>>
>> Part of the problem is that the TADS 3 parser doesn't attempt to
>> resolve noun phrases to objects until it's resolved the entire
>> phrase
>> to an action, so unless RAISE resolves to some action, the parser
>> can't go on to check whether the noun phrase entered by the
>> player
>> resolves to the flag object, which itself involves not only
>> checking
>> whether the flag object is in scope but whether it's the most
>> logical
>> available target for a 'raise' command.
>
> Yes, which is why I raised the idea of having the parser maintain
> a set
> of possible verb-to-action mappings (rather than picking just
> one). Then
> it goes through each action in the set, and does the noun phrase
> resolutions for it, and stores the logicalness value somewhere.
> After it
> has gone through all possible action mappings, it then picks the
> one
> that yields the most logical noun phrase resolutions.
Oh right; I recall seeing that suggestion somewhere upthread but I
hadn't twigged it was what you were proposing here. The model you
suggest above sounds doable in principle; I'm just wondering how
much it gains you in practice. I assume the kind of mapping you
might have in mind are, for example:
TAKE BALL -> PICK UP BALL
TAKE PATH -> GO ALONG PATH
FOLLOW MAN -> GO WHERE MAN WENT
FOLLOW PATH -> GO ALONG PATH.
This is currently handled by selective remapping on the PathPassage
class; I suppose it could be done at the earlier stage as you
suggest, but I'm not sure whether that constitutes much of a gain in
the context of TADS 3 (but see below). The slight awkwardness from
your suggestion is how the parser goes about breaking a tie when it
finds two grammar matches that are equally logical. Presumably it
could display a disambiguation prompt. The greater awkwardness is if
the parser has to resolve both ambigous command syntax and ambiguous
objects at the same time: which would the player be asked to resolve
first, and how tolerant would players be of being asked to resolve
both?
> Now I don't know enough about exactly how TADS goes about this
process,
> so maybe my idea doesn't quite work within the framework of TADS.
> But it
> does sound doable on its own.
Well indeed the terms of the discussion are rather different
depending whether we're talking about devising a new parser from the
ground up or writing a library extension for an existing system, in
this case TADS 3. My impression was that we were discussing the
latter; if you're thinking in terms of the former that's a different
matter, since in principle the kind of features you're talking about
could be made integral to the design. My concern was that what you
were suggesting would cut across the way the TADS 3 parser works, or
else would be more effort than it was worth to make it worth with
the TADS 3 parser (since you'd end up having two different and
partly incompatible mechanisms for performing essentially the same
task). Your suggestion of having the parser consider several
possible resolutions of command grammar to action and then pick the
most logical would require, I think, fairly deep rewriting of the
TADS 3 parser (theoretically doable in an extension, but a
non-trivial task I wouldn't be brave enough to attempt myself!).
Given the relative infrequency of the cases in which it would still
be useful and the alternative mechanisms that already exist in TADS
3 for handling them, it may be that *in the context of TADS 3* (and
possibly other existing systems as well), your proposal risks
looking like using a sledgehammer to crack a nut.
The situation is, of course, entirely different if you are talking
about the design of a new parser for a new system, where everything
has to be designed from scratch anyway.
[I should also point out that TADS 3 already has a partial mechanism
for choosing between alternative verb->action resolutions, namely
the 'badness' attached to any grammar line. I appreciate, of course,
that this is less flexible than what you are proposing].
>> Not necessarily; if the alternative phrasing is simply a synonym
>> for
>> an existing one, you simply define the new phrasing. For example,
>> if
>> you want to allow INSERT X INTO X to mean the same as PUT X IN Y,
>> then in TADS 3 you'd simply write:
>>
>> modify VerbRule(PutIn)
>> ('put' | 'insert') dobjList ('in'| 'into') singleIobj:
>> ;
>
> Yes, I know you can do this. :-) My point is that after you've
> done
> this, then at some later stage in your game, you decide that you
> need
> another action using the same verb (but different syntax, maybe a
> different number of objects). Now you have to go back and define a
> new
> VerbRule for it.
But you'd have to do something equivalent to that in any case
wouldn't you? If you have a standard library that defines MOVE X and
you also want your game to understand MOVE X WITH Y, you're clearly
going to have to define grammar for MOVE X WITH Y somewhere, and
that's what VerbRule does.
More generally, if the libary defines FROB X, and your game wants to
implement FROB X WITH Y, there's a reason why TADS 3 makes you go
through all the stuff it does (defining a new action, new VerbRule,
and modifying Thing plus any other relevant classes); this is the
work that's necessary to ensure that the player gets an intelligent
response to FROB X WITH Y for all X and Y in the game, and not just
the particular pair of objects you have in mind for it.
OTOH if your point is that you might want a shortcut because the
phrasing FROB X WITH Y doesn't need a new action, but sometimes
needs to mean FOO X WITH Y and sometimes BAR X WITH Y and sometimes
simply FROBBLE X (where FOO WITH, BAR WITH and FROBBLE are existing
actions), then there is already available the shortcut of adding
FROB X WITH Y to the grammar of the existing FOO action and then
having FOO X WITH Y remap to BAR X WITH Y or FROBBLE X under the
appropriate circumstances (which would include checking that the
player typed a command beginning FROB). This is work the author is
effectively going to have to do one way or another under any
circumstances, ISTM.
Of course, once again, the discussion is rather different if you're
talking about building a completely new parser from the ground up,
which could then be designed round your suggested way of doing
things.
> And if you upgrade the TADS library, you may have to go back and
> revisit
> all such modifications to ensure that you don't lose the benefit
> of,
> say, new alternative phrasings that may have been added to the
> library
> for this action. If your game has as many alternative phrasings as
> I
> envision, then this could be quite a daunting task. Why not rather
> have
> the library pick up what the author wants to use, and generate the
> underlying mappings automatically and ensure smooth integration of
> bugfixes/enhancements/etc.?
Again I'm left feeling that the proposed solution is out of
proportion to the problem described here TADS 3 library updates are
not that common, and the changes they make to the grammar
definitions of library-defined actions tend to be few and far
between. In any case checking that your phrasings are compatible
with a libary upgrade is only one part - and usually a pretty minor
part - of ensuring that all your code is compatible with a library
upgrade, and, if not, making the necessary changes.
Sure, the game could say that, but it has to know how to deal with
the command in order to generate that message. IOW the parser has to
be able to deal with RAISE X for any X, and not just RAISE FLAG,
which requires defining a RaiseAction and all the rest. So I fail to
see the scope for a significant shortcut here. It's not enough to
tell the parser RAISE FLAG means TURN THE CRANK ON THE FLAGPOLE when
there's a flagpole nearby, and leave the rest undefined.
That said, I suppose what you could do is to devise some means of
having the library gather up all your RAISE FLAG means so-and-so
type definitions for you and effectively create new actions and verb
rules to handle the other cases in a default bland fashion, but I'm
not sure how satisfactory the result would be. If a response is only
provided for the flag, and there IS a children object in the game,
how should RAISE CHILDREN be handled when the children object is in
scope?
>> IOW, automation is not such a good thing if it encourages authors
>> not
>> to take steps they really need to take to ensure a polished
>> product.
> [...]
>
> I don't know... forcing authors to get down on the nitty-gritty
> details
> all the time does tend to frustrate the creative process, even if
> it
> does make them think more about the details. Thinking about the
> details
> is good, but it should be done when the author is focusing on the
> details, not forced upon the author at every occasion. It is
> useful to
> be able to make a rapid prototype of a game just to assess its
> feasibility, before one starts coding every last detail into every
> last
> object.
IHMO a shortcut is splendid if it makes it easier for authors to do
the job properly. But not if it only makes it easier for them to do
it sloppily (and hence tempts them not to do it properly).
In any case, there's nothing forcing an author to deal with all the
details of adding new actions or new phrasings at any particular
point in the creative process. It takes very little time to write a
new action definition and VerbRule using the macros provided. Going
back to modify Thing (plus any other classes) is a chore that can be
left till later, if the author would rather get on with something
else in the meanwhile.
-- Eric
Emily Short
bogus6...@mailinator.com wrote:
> If Ms. Short is reading this, the specific problem I had with her
> question parser was asking (probably not in these exact words) "Where
> were you when So-and-so was killed?" The parser seemed to think I was
> asking "When (i.e., at what time) was So-and-so killed?".
Yeah, I'm not surprised. This was an experiment I expected to (partly)
fail: I was curious to see whether it was possible to create a
chatbot-like interface using some of the tools of Inform 7. What I came
up with borrowed some ideas from, but wasn't as flexible as, AIML (one
of the leading chatbot-scripting languages out there). And even where I
got the design right, it quite simply doesn't have enough content to
work nearly as well as a good chatbot does.
I still think that it *might* be possible, given a more AIML-like
mechanism, and a game with very specific goals and limited focus, to
train up a much more persuasive chatbot-like NPC. Not one who couldn't
be broken, of course -- that's impossible with current technology --
but one with sufficient coverage of the range of things likely to be
said in the course of the game that most players wouldn't lose
immersion very often unless they were trying. If one kept the access to
the NPC very short, and the purpose of the interaction very clear, and
the number of words the player could enter very small, then maybe... in
any case it would certainly have been possible to catch questions of
the more elaborate form you describe.
But "train" is an important word here. Most good chatbots have been
created through a huge amount of interaction and iterative refinement.
Even if I'm right and it's possible to do anything interesting with
this at all, I would have needed a lot more time and testing to improve
the results significantly, I think -- much more testing than the
average IF beta-testing team would provide. Is this a realistic
direction to pursue for most IF games? I think not: far too much effort
to build, far too little improvement over the existing interface. For
many many pieces the narrative is served adequately by commands like
TALK TO JANINE ABOUT FRED. But it would still be cool if one could pull
the natural language stuff off even once, in the context of a story
that really built on it.
Facade is a more credible attempt to do exactly that, in fact
(http://www.interactivestory.net/). I don't think it works -- I found
it to be pretty hard to steer, and the NPC responses are often odd and
unexpected; only in a few cases was it clear to me exactly why they'd
reacted as they did to what I said. I'm not sure that the real-time
interface helps it here, since it's hard for the player to interrupt
exactly when he wants to, and the characters go on talking (and moving
narrative context forward) while he types. I also think it would be
possible to narrow the scope of the problem by making the relationship
of PC/NPC more constrained -- give the PC a clear, specific goal (like
investigating one event), and you can focus more of your efforts on
perfecting that interaction.
Chris Crawford's Deikto language
(http://www.storytron.com/overview/ov_deikto.html) looks like an
attempt to solve this problem from another direction -- providing a
more fluid and flexible kind of interaction than that currently handled
by the average IF parser, but still keeping the vocabulary small
(relative to the scope of natural language) and offering the player
full knowledge of the dictionary. And forcing the NPCs to speak back in
this language. It's hard to evaluate how well this will work until
there are some games demonstrating it.
Buuut... yeah. "Mystery House Possessed" was definitely an experiment,
in a context designed for experimentation. The only other IF game I
know of which has tried this in recent years is Jon Ingold's "Insight"
-- which also didn't quite work, but also involves interrogation on a
tightly-defined topic. Nonetheless, in the larger world quite a lot has
been done with natural language conversation since "Eliza", and not all
of it is stupid.
bogus6...@mailinator.com
Emily Short wrote:
> bogus6...@mailinator.com wrote:
> > If Ms. Short is reading this, the specific problem I had with her
> > question parser was asking (probably not in these exact words) "Where
> > were you when So-and-so was killed?" The parser seemed to think I was
> > asking "When (i.e., at what time) was So-and-so killed?".
>
> Yeah, I'm not surprised. This was an experiment I expected to (partly)
> fail: I was curious to see whether it was possible to create a
> chatbot-like interface using some of the tools of Inform 7. What I came
> up with borrowed some ideas from, but wasn't as flexible as, AIML (one
> of the leading chatbot-scripting languages out there). And even where I
> got the design right, it quite simply doesn't have enough content to
> work nearly as well as a good chatbot does.
>
>
> Buuut... yeah. "Mystery House Possessed" was definitely an experiment,
> in a context designed for experimentation. The only other IF game I
> know of which has tried this in recent years is Jon Ingold's "Insight"
> -- which also didn't quite work, but also involves interrogation on a
> tightly-defined topic. Nonetheless, in the larger world quite a lot has
> been done with natural language conversation since "Eliza", and not all
> of it is stupid.
Here, I wasn't even _trying_ to break the game: I just wanted the
character to answer the question, which I thought was a quite
reasonable one to ask given the nature of the game.
Adam Thornton
Well, sort of. Claudio has rolled the quantum variable stuff into the
language itself, but, alas:
The command-line compiler "oo, ick" and the inline module
"Language::INTERCAL" are not currently provided. They have been replaced
by the compiler "sick" and the module "Language::INTERCAL::Sick"
respectively, which have a rather different usage. A compatibility "oo,
ick" and "Language::INTERCAL" is intended to appear in a future
pre-escape, and certainly before the escape.
This makes me sad.
Adam
quic...@quickfur.ath.cx
That's a good point. I imagine it wouldn't be *too* bad if the game
prompts using some canonical phrasing of each possible action by the
author, e.g., something like "Do you mean, WALK ALONG THE PATH, or WALK
ALONG THE SIDEWALK, or FOLLOW THE MAN?"
> > Now I don't know enough about exactly how TADS goes about this
> > process, so maybe my idea doesn't quite work within the framework of
> > TADS. But it does sound doable on its own.
>
> Well indeed the terms of the discussion are rather different depending
> whether we're talking about devising a new parser from the ground up
> or writing a library extension for an existing system, in this case
> TADS 3. My impression was that we were discussing the latter; if
> you're thinking in terms of the former that's a different matter,
> since in principle the kind of features you're talking about could be
> made integral to the design.
Actually, I'm approaching this more from the angle of identifying an
area of possible improvement with current parsers, coming up with a
possible solution, and then looking at existing systems to see if this
could be done. It's not either extreme of rewriting everything from
scratch, or shoe-horning an existing system into a new way of working.
:-)
> My concern was that what you were suggesting would cut across the way
> the TADS 3 parser works, or else would be more effort than it was
> worth to make it worth with the TADS 3 parser (since you'd end up
> having two different and partly incompatible mechanisms for performing
> essentially the same task). Your suggestion of having the parser
> consider several possible resolutions of command grammar to action and
> then pick the most logical would require, I think, fairly deep
> rewriting of the TADS 3 parser (theoretically doable in an extension,
> but a non-trivial task I wouldn't be brave enough to attempt myself!).
I see. I had, based on what limited knowledge I have of the TADS parser,
assumed mistakenly that this wouldn't require such drastic changes.
> Given the relative infrequency of the cases in which it would still be
> useful and the alternative mechanisms that already exist in TADS 3 for
> handling them, it may be that *in the context of TADS 3* (and possibly
> other existing systems as well), your proposal risks looking like
> using a sledgehammer to crack a nut.
Perhaps, but I *was* trying to address the question of whether it's
possible to make IF parsers handle a bigger subset of natural language
than they currently do. Since natural language is inherently ambiguous,
it seems to me that some similar scheme of resolving disambiguation
would be necessary to take IF parsing to the next level.
And it has just occurred to me that another issue I was trying to
address, which slipped my mind when I typed the last few responses, is
that of cross-category ambiguity. For example, in my original example
"fruit flies like a banana", "flies" may either be a verb or a noun. I
don't think current parsers are able to handle this at all (or am I
mistaken?). Of course, in IF parsing we're mostly dealing with
imperatives (DO THIS, GO THERE, TAKE THAT), so the verb/noun ambiguity
won't crop up all that often. But what about, to pick a real-life
example, referring to the NPC named With (from Spider & Web), since it
may be interpreted either as an adverb or a proper noun in that context?
I suspect things like "TELL WITH ABOUT DOOR" will fall flat on its face
horribly under existing parsers. Or better yet, "HIT WITH" (what do you
want to hit with?), or "HIT WITH WITH A HAMMER".
Using my suggested parsing strategy, this would at least be solvable
(though whether my method of doing it is the best is debatable).
[...]
> >> modify VerbRule(PutIn)
> >> ('put' | 'insert') dobjList ('in'| 'into') singleIobj:
> >> ;
> >
> > Yes, I know you can do this. :-) My point is that after you've done
> > this, then at some later stage in your game, you decide that you
> > need another action using the same verb (but different syntax, maybe
> > a different number of objects). Now you have to go back and define a
> > new VerbRule for it.
>
> But you'd have to do something equivalent to that in any case wouldn't
> you? If you have a standard library that defines MOVE X and you also
> want your game to understand MOVE X WITH Y, you're clearly going to
> have to define grammar for MOVE X WITH Y somewhere, and that's what
> VerbRule does.
>
> More generally, if the libary defines FROB X, and your game wants to
> implement FROB X WITH Y, there's a reason why TADS 3 makes you go
> through all the stuff it does (defining a new action, new VerbRule,
> and modifying Thing plus any other relevant classes); this is the work
> that's necessary to ensure that the player gets an intelligent
> response to FROB X WITH Y for all X and Y in the game, and not just
> the particular pair of objects you have in mind for it.
That's true.
> OTOH if your point is that you might want a shortcut because the
> phrasing FROB X WITH Y doesn't need a new action, but sometimes
> needs to mean FOO X WITH Y and sometimes BAR X WITH Y and sometimes
> simply FROBBLE X (where FOO WITH, BAR WITH and FROBBLE are existing
> actions), then there is already available the shortcut of adding
> FROB X WITH Y to the grammar of the existing FOO action and then
> having FOO X WITH Y remap to BAR X WITH Y or FROBBLE X under the
> appropriate circumstances (which would include checking that the
> player typed a command beginning FROB). This is work the author is
> effectively going to have to do one way or another under any
> circumstances, ISTM.
This is true, too. Although, in the context of having IF parsers be more
powerful in handling ambiguity in natural language, I was hoping for
*some* sort of automation so that the author would not have to spend a
lot of time implementing alternate phrasings of things. But maybe this
is just a pipe-dream.
[...]
> > And if you upgrade the TADS library, you may have to go back and
> > revisit all such modifications to ensure that you don't lose the
> > benefit of, say, new alternative phrasings that may have been added
> > to the library for this action. If your game has as many alternative
> > phrasings as I envision, then this could be quite a daunting task.
> > Why not rather have the library pick up what the author wants to
> > use, and generate the underlying mappings automatically and ensure
> > smooth integration of bugfixes/enhancements/etc.?
>
> Again I'm left feeling that the proposed solution is out of
> proportion to the problem described here TADS 3 library updates are
> not that common, and the changes they make to the grammar
> definitions of library-defined actions tend to be few and far
> between. In any case checking that your phrasings are compatible
> with a libary upgrade is only one part - and usually a pretty minor
> part - of ensuring that all your code is compatible with a library
> upgrade, and, if not, making the necessary changes.
That's true too.
Maybe I'm going about it the wrong way... we're already talking about
the details of implementation whereas my idea really should be fleshed
out more and debated on the conceptual level first.
> >> [...] On the other hand, if you are defining a completely new
> >> Action (say Raise) you probably do need to define it properly,
> >> since if players find that RAISE FLAG works they may well try RAISE
> >> HANDS or RAISE SHIELD or RAISE CHILDREN, and the parser (or rather,
> >> your game) ought to handle such attempts gracefully (or wittily, as
> >> the case may be), and certainly not by telling players that "The
> >> word 'raise' is not needed in this game" or "I don't understand
> >> your command" or some such equivalent, which is what you'll
> >> probably get if you don't go to the bother of carrying out all the
> >> necessary steps.
> >
> > But if there are no CHILDREN objects in the game, the game could
> > simply say "you don't see any children here".
>
> Sure, the game could say that, but it has to know how to deal with the
> command in order to generate that message. IOW the parser has to be
> able to deal with RAISE X for any X, and not just RAISE FLAG, which
> requires defining a RaiseAction and all the rest. So I fail to see the
> scope for a significant shortcut here. It's not enough to tell the
> parser RAISE FLAG means TURN THE CRANK ON THE FLAGPOLE when there's a
> flagpole nearby, and leave the rest undefined.
I didn't make it explicit (maybe I should've), but it was implied that
since these mappings are always defined in the context of certain
objects, the parser would pick up on the fact that FLAG isn't just some
random 4-letter word, but happens to refer to the Flag object currently
in scope, and would infer based on that, that RAISE FLAG really is an
instance of RAISE <noun>, and the author is explicating a particular
case of <noun> here. Similarly, if one is able to TURN THE CRANK ON THE
FLAGPOLE, one would assume that there are objects in the current context
that are known as CRANK and FLAGPOLE to the parser, and therefore the
parser infers that the author is using an instance of the pattern TURN
THE <object1> ON THE <object2>.
> That said, I suppose what you could do is to devise some means of
> having the library gather up all your RAISE FLAG means so-and-so type
> definitions for you and effectively create new actions and verb rules
> to handle the other cases in a default bland fashion, but I'm not sure
> how satisfactory the result would be. If a response is only provided
> for the flag, and there IS a children object in the game, how should
> RAISE CHILDREN be handled when the children object is in scope?
This is a good point. At this point, the author would have to specify an
appropriate response, since the parser can't possibly invent one on its
own---but then it brings us back to your point that since the author has
to do this anyway, it gains us nothing over the current way of
specifying these things.
[...]
> > I don't know... forcing authors to get down on the nitty-gritty
> > details all the time does tend to frustrate the creative process,
> > even if it does make them think more about the details. Thinking
> > about the details is good, but it should be done when the author is
> > focusing on the details, not forced upon the author at every
> > occasion. It is useful to be able to make a rapid prototype of a
> > game just to assess its feasibility, before one starts coding every
> > last detail into every last object.
>
> IHMO a shortcut is splendid if it makes it easier for authors to do
> the job properly. But not if it only makes it easier for them to do it
> sloppily (and hence tempts them not to do it properly).
>
> In any case, there's nothing forcing an author to deal with all the
> details of adding new actions or new phrasings at any particular point
> in the creative process. It takes very little time to write a new
> action definition and VerbRule using the macros provided. Going back
> to modify Thing (plus any other classes) is a chore that can be left
> till later, if the author would rather get on with something else in
> the meanwhile.
[...]
Although, I fear that if left till later, the author may not have time
(or just plain forget) to come back and fill up these holes, leading to
poor results.
But you do have a point, in that doing things the way I suggested may
not really gain that much in terms of simplifying the author's task. I
think I got distracted by how things could be implemented, when my
original idea really is to consider how to extend IF parsing to handle
more of natural language than it currently does.
QF
--
MASM = Mana Ada Sistem, Man!
Emily Short
bogus6...@mailinator.com wrote:
> Here, I wasn't even _trying_ to break the game: I just wanted the
> character to answer the question, which I thought was a quite
> reasonable one to ask given the nature of the game.
It was. All I'm saying is that it's not reasonable to take that game,
created as an experiment and with limited resources compared to what
one would need to do really well at this, as a demonstration of the
best chatbot-style processing can do. And the those bits were never
meant as a general parser, either; they were only relevant within the
domain of conversation.
Eric Eve
news:20061019160728.GA2896@crystal...
> On Thu, Oct 19, 2006 at 08:29:24AM +0000, Eric Eve wrote:
>> <quic...@quickfur.ath.cx> wrote in message
>> news:20061019022326.GB32368@crystal...
> That's a good point. I imagine it wouldn't be *too* bad if the
> game
> prompts using some canonical phrasing of each possible action by
> the
> author, e.g., something like "Do you mean, WALK ALONG THE PATH, or
> WALK
> ALONG THE SIDEWALK, or FOLLOW THE MAN?"
Yes, you could do that; whether it's a better player interface I'm
not so sure.
>> My concern was that what you were suggesting would cut across the
>> way
>> the TADS 3 parser works, or else would be more effort than it was
>> worth to make it worth with the TADS 3 parser (since you'd end up
>> having two different and partly incompatible mechanisms for
>> performing
>> essentially the same task). Your suggestion of having the parser
>> consider several possible resolutions of command grammar to
>> action and
>> then pick the most logical would require, I think, fairly deep
>> rewriting of the TADS 3 parser (theoretically doable in an
>> extension,
>> but a non-trivial task I wouldn't be brave enough to attempt
>> myself!).
> I see. I had, based on what limited knowledge I have of the TADS
> parser,
> assumed mistakenly that this wouldn't require such drastic
> changes.
I *think* it would require quite a deep change to implement your
'match the most logical grammar line' idea.
a sledgehammer to crack a nut.
> Perhaps, but I *was* trying to address the question of whether
> it's
> possible to make IF parsers handle a bigger subset of natural
> language
> than they currently do. Since natural language is inherently
> ambiguous,
> it seems to me that some similar scheme of resolving
> disambiguation
> would be necessary to take IF parsing to the next level.
Yes, indeed, and this is a different issue.
> And it has just occurred to me that another issue I was trying to
> address, which slipped my mind when I typed the last few
> responses, is
> that of cross-category ambiguity. For example, in my original
> example
> "fruit flies like a banana", "flies" may either be a verb or a
> noun. I
> don't think current parsers are able to handle this at all (or am
> I
> mistaken?). Of course, in IF parsing we're mostly dealing with
> imperatives (DO THIS, GO THERE, TAKE THAT), so the verb/noun
> ambiguity
> won't crop up all that often.
Right; and in the main it's probably a Good Thing (TM) to limit IF
commands to this form, since it makes it easier for players to hit
on the right commands if there's only a small subset of natural
language they can usefully try. The main possible exception to this
is in conversation; one experimental attempt to extend the range of
what can be used in conversational commands is my own SayQuery
extension; I'm very much in two minds whether it's a successful
experiment, though, since the more free form a commands are allowed
to become, the more the player is faced with a 'guess the command
phrasing' puzzle (unless you're going to equip NPCs with natural
language parsing abilities, but that's going down an AI route that's
way ahead of what's possible with current IF tools).
Of course, you can devise an extension to make the parser a bit more
fault-tolerant for newbies who are shaky on the expected command
syntax; Emily Short has done this sort of thing for Inform.
> But what about, to pick a real-life
> example, referring to the NPC named With (from Spider & Web),
> since it
> may be interpreted either as an adverb or a proper noun in that
> context?
> I suspect things like "TELL WITH ABOUT DOOR" will fall flat on its
> face
> horribly under existing parsers. Or better yet, "HIT WITH" (what
> do you
> want to hit with?), or "HIT WITH WITH A HAMMER".
Actually the standard TADS 3 parser has no difficulty with this (I
just tried it). If you have an object called 'with' and an object
called 'hammer' in scope, then you get perfectly good responses to
HIT WITH and HIT WITH WITH HAMMER. This is probably helped by the
[badness] rating I mentioned before, which the TADS 3 parser already
uses to help decide the best among a number of ambiguous phrasings.
In my test example, having made suitable objects definitions I get:
>hit with
You give the with a sharp tap.
>hit with with hammer
(first taking the hammer)
You hit the with with the hammer.
No problem!
> This is true, too. Although, in the context of having IF parsers
> be more
> powerful in handling ambiguity in natural language, I was hoping
> for
> *some* sort of automation so that the author would not have to
> spend a
> lot of time implementing alternate phrasings of things. But maybe
> this
> is just a pipe-dream.
Well, maybe I'm not grasping your idea, but I'm not yet seeing how
it would work (or rather, how it would improve things).
> Maybe I'm going about it the wrong way... we're already talking
> about
> the details of implementation whereas my idea really should be
> fleshed
> out more and debated on the conceptual level first.
Indeed; but in part I'm trying to get a handle on what the problem
is that you're trying to find a solution to! :)
> I didn't make it explicit (maybe I should've), but it was implied
> that
> since these mappings are always defined in the context of certain
> objects, the parser would pick up on the fact that FLAG isn't just
> some
> random 4-letter word, but happens to refer to the Flag object
> currently
> in scope, and would infer based on that, that RAISE FLAG really is
> an
> instance of RAISE <noun>, and the author is explicating a
> particular
> case of <noun> here. Similarly, if one is able to TURN THE CRANK
> ON THE
> FLAGPOLE, one would assume that there are objects in the current
> context
> that are known as CRANK and FLAGPOLE to the parser, and therefore
> the
> parser infers that the author is using an instance of the pattern
> TURN
> THE <object1> ON THE <object2>.
I think I had gathered that after our last exchange; the problem is,
once that much is granted, then as you say below:
>> That said, I suppose what you could do is to devise some means of
>> having the library gather up all your RAISE FLAG means so-and-so
>> type
>> definitions for you and effectively create new actions and verb
>> rules
>> to handle the other cases in a default bland fashion, but I'm not
>> sure
>> how satisfactory the result would be. If a response is only
>> provided
>> for the flag, and there IS a children object in the game, how
>> should
>> RAISE CHILDREN be handled when the children object is in scope?
>
> This is a good point. At this point, the author would have to
> specify an
> appropriate response, since the parser can't possibly invent one
> on its
> own---but then it brings us back to your point that since the
> author has
> to do this anyway, it gains us nothing over the current way of
> specifying these things.
Yes, that's precisely the point I was trying to make!
> But you do have a point, in that doing things the way I suggested
> may
> not really gain that much in terms of simplifying the author's
> task. I
> think I got distracted by how things could be implemented, when my
> original idea really is to consider how to extend IF parsing to
> handle
> more of natural language than it currently does.
You might want to look at the SayQuery extension (grabbable from
http://users.ox.ac.uk/~manc0049/files/ or from the IF-Archive) for
one approach to extending the range of natural language that can be
used in conversational commands.
For the more general command case, the next step forward would
probably be to list the kind of commands you think a parser should
handle that it currently doesn't (but it would be worth
experimenting with the current parser first to see what it can and
can't handle satisfactorially).
-- Eric
Matthew Slattery
Ah, you're looking at version 1.-94.-4.1. "oo, ick" can be found in the
0.05+ version (and you're credited in the change log for suggesting a
useful feature!).
-- Matthew.
Adam Thornton
Matthew Slattery <mat...@confusion.org> wrote:
>Adam Thornton <ad...@fsf.net> wrote:
>Ah, you're looking at version 1.-94.-4.1. "oo, ick" can be found in the
>0.05+ version (and you're credited in the change log for suggesting a
>useful feature!).
Oh my goodness. Nonconstant probabilities are my fault?
I was young and I needed the money. I was drunk and on tranquilizers.
That Congressional Page was just too sexy. I don't remember a thing--it
must have been the Roofies. It wasn't me, it was my evil twin.
Adam
Kevin Forchione
news:h64l04-...@silver.yka.fsf.net...
You did not have sex with that compiler...
--Kevin
Jannie
> I'm cross-posting this to rgif because I think that we really need a
> players'-side view on this question. It's the kind of thing that beta
> testing was invented for.
>
> So, players of interactive fiction, what kinds of annoyances and
> frustrations do you most often experience with the IF parser?
I've got some ideas, not all of which may be practical - but that's what you
get for asking at rgif :}
Also, Ithink T3 does a few of these by default.
SPECIFY OBJECTS BY THEIR PROPERTIES
-----------------------------------
Allow players to refer to objects and collections of non-identical objects
by adjectives, nouns, location, or other properties known to the parser
and/or the world model:
"Take everything (which is) silver" when there're a silver spoon, a silver
coin, and a silver bullet.
"Look in (all) pots" when there're a flower pot, a cooking pot, and a
chamber pot.
"Look in (all) boxes (which are) on the shelf" when there're boxes on the
shelf, the floor, and in the next room (visible, but out of reach).
"Look in everything (which is) silver (which is) on the table". And so on!
DISAMBIGUATION
--------------
The ability to answer disambiguation questions
with "either/any", "neither/none", "both/all", or perhaps phrases such as
the ones above.
> take floppy disk
Which floppy disk do you mean: the 5.25 inch floppy disk, or the 3.5 inch
floppy disk?
> the one (which is) in the disk drive
3.5 inch floppy disk: Taken.
I'm not sure where to stop with this; the player could of course try to
describe objects as "the burnt one" or "the one that is/has been burnt"...
I suppose some of that could be achieved just by adding adjectives on the
fly...
T3 does some of those things, and I like it... sorely missed it in a comp
game I just played.
CATCH ADVERBS
-------------
> quickLY climb up the ladder/sing happiLY/do stuff adjectiveLY
I don't know the word "quickly"/"happily"/"adjectively". Did you mean to use
an adverb? Those never work, sorry.
USE X TO DO Y = DO Y WITH X
---------------------------
Make "use object to do stuff" synonymous with "do stuff with object", and
respond to "use object" intelligently (as you would for "tell johnny"
or "give key").
ASK/TELL X TO DO Y = X, DO Y
----------------------------
Make "ask/tell/... NPC to do stuff" synonymous with the less intuitive
(IMHO) "NPC, do stuff". (Ideally with at least these two levels of
politeness, but just being understood at all would be nice.)
LOOK NORTH/UP/BACK...
---------------------
Maybe keep it simple and don't list portable objects (many of which would
realistically be obscured even if the gameworld has no concept of that) -
just give a general impression of the other room and any NPCs within.
Also, "look through window/door/porthole/..." to achieve the same.
ADDRESS LOCATIONS, NOT JUST DIRECTIONS
--------------------------------------
Like "look into kitchen" when you're in the dining room, or "examine room"
to mean "look around". It's always seemed strange to me that games don't
usually understand the name of the room you're in.
LESS DISJOINTED MAPS
--------------------
Give more hints as to where I'm going and what "conduit" I'm taking to
pass from one location to another, and allow me to refer to that conduit
in my commands (instead of giving a compass direction):
> north
You follow the river toward the jetty.
> go through sliding door
You go south into the dining room.
> enter dining room
You go south through the sliding door.
I suppose the announcements in my example above could get irritating and
should perhaps be off by default, but it might really help terminally lost
people like me. IF is so compartmentalised, sometimes I find it hard to
imagine how outdoor locations connect.
n2...@yahoo.com
> I've been working for a while on an extension to improve...
I have never needed to be a student of parsers,
until possibly now. I see there was one mention
of LFG here:
My Linux box had fallen by the wayside to run this:
http://www.parc.com/istl/groups/nltt/medley/
When I was unhappy with the early 2.6 kernels, and
OS/X seemed to filling my Open Source needs adaquately.
I was just thinking of trying again on my 2 page Mac screen.
Should be big enough now to run w/o scroll bars, and a
modern IDE side-by-side (wasn't the resolution (WORKspace)
on early workstation incredible?) But now, It will be more for,
than just a study of the ancient lost technologies of InterLisp-D...
This time when I Googled LFG, It came w/ this page higher up -
http://www.essex.ac.uk/linguistics/LFG/
whose FAQ leads to other implementations, if you
don't have Linux / Solaris / *nix & X (optional OSX install)
Richard Bos
> Oh my goodness. Nonconstant probabilities are my fault?
>
> I was young and I needed the money. I was drunk and on tranquilizers.
> That Congressional Page was just too sexy. I don't remember a thing--it
> must have been the Roofies.
This Congressional Page Intentionally Left Blank?
Richard
Paul McGuire
news:4536d714$1...@news.broadpark.no...
simple text adventure. The presentation is online at
http://www.python.org/pycon/2006/papers/4/, and the source code is included
in the examples included with the download of pyparsing (available at
http://sourceforge.net/projects/pyparsing/).
-- Paul McGuire
Richard Bos
> Synonyms:
> - If a game has an "Elizabeth" character, the game should at least
> recognize "Liz". (Who wants to type "Elizabeth" ten times if they don't
> have to?)
That's up to the game author to add to the vocabulary, though. It's not
part of the parser, and should definitely not be fixed in the library.
Sometimes a name could be abbreviated, but should not; and sometimes,
for example, a character should react differently to his abbreviated
name than to his full one.
Richard