[Inform] Unlock Gate With Key (this doesn't work)
David A. Cornelson
Maybe this is archived somewhere but I don't have time to search....
If you type...
> open gate with key
You unlock the gate.
If you type...
> unlock gate with key
I only understood you as far as wanting to unlock the gate.
This really doesn't make sense to me....am I missing something or is this
a bug?
David A. Cornelson, Chicago
-------------------==== Posted via Deja News ====-----------------------
http://www.dejanews.com/ Search, Read, Post to Usenet
Magnus Olsson
In article <884926422....@dejanews.com>,
David A. Cornelson <dcorn...@placet.com> wrote:
>Maybe this is archived somewhere but I don't have time to search....
>
>If you type...
>
>> open gate with key
>You unlock the gate.
>
>If you type...
>
>> unlock gate with key
>I only understood you as far as wanting to unlock the gate.
>
>This really doesn't make sense to me....am I missing something or is this
>a bug?
This indicates that there isn't a grammar rule
verb 'unlock'
* noun 'with' held -> Unlock;
or something like that. I thought there was such a rule in grammar.h -
have you by any chance modified the verb 'unlock'?
--
Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
------ http://www.pobox.com/~zebulon ------
Not officially connected to LU or LTH.
Jeff Hatch
David A. Cornelson wrote:
>
> Maybe this is archived somewhere but I don't have time to search....
>
> If you type...
>
> > open gate with key
> You unlock the gate.
>
> If you type...
>
> > unlock gate with key
> I only understood you as far as wanting to unlock the gate.
>
> This really doesn't make sense to me....am I missing something or is this
> a bug?
Essentially, it's a bug. Apparently, the game you're playing doesn't
understand a "grammar" for unlock that allows the use of a prepositional
phrase like "with key." Perhaps typing "unlock gate" would work.
Other systems might tell you that they don't allow the verb "unlock" to
take an indirect object or prepositional phrase. But Inform doesn't
bother to notice that "with key" is a prepositional phrase, since
"unlock" can't use a prepositional phrase anyway. It parses the
sentence as far as it can, and then tells you how much of your sentence
it understood. Hence the confusing error message; it only understood
"unlock gate."
-Rúmil
Andrew Plotkin
David A. Cornelson (dcorn...@placet.com) wrote:
> Maybe this is archived somewhere but I don't have time to search....
> If you type...
> > open gate with key
> You unlock the gate.
> If you type...
> > unlock gate with key
> I only understood you as far as wanting to unlock the gate.
Verb 'open' 'unwrap' 'uncover' 'undo'
* noun -> Open
* noun 'with' held -> Unlock;
Verb 'unlock'
* noun 'with' held -> Unlock;
That's from the 6/7 libraries. I can only conclude that you've done
something clever to the grammar for 'unlock'.
If you haven't, er, what els clever are you doing? This sort of thing is
supposed to work.
--Z
--
"And Aholibamah bare Jeush, and Jaalam, and Korah: these were the
borogoves..."
Julian Arnold
In article <erkyrathE...@netcom.com>, Andrew Plotkin
<URL:mailto:erky...@netcom.com> wrote:
> David A. Cornelson (dcorn...@placet.com) wrote:
> > Maybe this is archived somewhere but I don't have time to search....
>
> > If you type...
>
> > > open gate with key
> > You unlock the gate.
>
> > If you type...
>
> > > unlock gate with key
> > I only understood you as far as wanting to unlock the gate.
>
> Verb 'open' 'unwrap' 'uncover' 'undo'
> * noun -> Open
> * noun 'with' held -> Unlock;
> Verb 'unlock'
> * noun 'with' held -> Unlock;
"Unwrap door with iron key" indeed!
Jools
--
"For small erections may be finished by their first architects; grand
ones, true ones, ever leave the copestone to posterity. God keep me from
ever completing anything." -- Herman Melville, "Moby Dick"
Magnus Olsson
In article <ant16214...@arnod.demon.co.uk>,
Julian Arnold <jo...@arnod.demon.co.uk> wrote:
>In article <erkyrathE...@netcom.com>, Andrew Plotkin
><URL:mailto:erky...@netcom.com> wrote:
>> Verb 'open' 'unwrap' 'uncover' 'undo'
>> * noun -> Open
>> * noun 'with' held -> Unlock;
>
Indeed :-).
This is actually an explicit philosophy of Graham's: it's acceptable
if the parser accepts some unheard-of syntax as a consequence of
having synonyms. That is, for the sake of simplicity the parser
treats 'unwrap' and 'open' as synonyms, even though they aren't
exact synonyms in all contexts ("unwrap parcel" and "open parcel"
are synonymous; "unwrap door" and "open door" usually aren't).
What do people think about this from the player's perspective?
Does it distrub you as a player if the parser recognizes strange
commands such as "unwrap door with key"?
Lynn Johannesen
Magnus Olsson (m...@bartlet.df.lth.se) wrote:
: In article <ant16214...@arnod.demon.co.uk>,
: Julian Arnold <jo...@arnod.demon.co.uk> wrote:
: >In article <erkyrathE...@netcom.com>, Andrew Plotkin
: ><URL:mailto:erky...@netcom.com> wrote:
: >> Verb 'open' 'unwrap' 'uncover' 'undo'
: >> * noun -> Open
: >> * noun 'with' held -> Unlock;
: >
: >"Unwrap door with iron key" indeed!
: Indeed :-).
: This is actually an explicit philosophy of Graham's: it's acceptable
: if the parser accepts some unheard-of syntax as a consequence of
: having synonyms. That is, for the sake of simplicity the parser
: treats 'unwrap' and 'open' as synonyms, even though they aren't
: exact synonyms in all contexts ("unwrap parcel" and "open parcel"
: are synonymous; "unwrap door" and "open door" usually aren't).
: What do people think about this from the player's perspective?
: Does it disturb you as a player if the parser recognizes strange
: commands such as "unwrap door with key"?
As a player, I can't recall that it's ever bothered me, just because
I don't think of trying weird things like that. As a programmer,
it impresses me pretty strongly as the wrong way to do things.
But not strongly enough to make me write my own language.
Andrew Plotkin
Lynn Johannesen (ly...@netcom.com) wrote:
> : >> Verb 'open' 'unwrap' 'uncover' 'undo'
> : >> * noun -> Open
> : >> * noun 'with' held -> Unlock;
> : >
> : >"Unwrap door with iron key" indeed!
> : Indeed :-).
> : This is actually an explicit philosophy of Graham's: it's acceptable
> : if the parser accepts some unheard-of syntax as a consequence of
> : having synonyms. That is, for the sake of simplicity the parser
> : treats 'unwrap' and 'open' as synonyms, even though they aren't
> : exact synonyms in all contexts ("unwrap parcel" and "open parcel"
> : are synonymous; "unwrap door" and "open door" usually aren't).
> As a player, I can't recall that it's ever bothered me, just because
> I don't think of trying weird things like that.
As a player, I agree. The parser will "recognize" all sorts of nonsense,
but the player is trying so hard to avoid nonsense that it rarely gets
noticed.
> As a programmer,
> it impresses me pretty strongly as the wrong way to do things.
> But not strongly enough to make me write my own language.
There are some verbs in the Inform standard grammar that I sometimes want
to split apart. Which is easy to do; in the above case, you could put the
following in your own code:
Extend 'unwrap' replace
* noun -> Open;
Extend only 'open' replace
* noun -> Open
* noun 'with' held -> Unlock;
But in this case, I think Graham made the right choice. 'unwrap' doesn't
sensibly apply to doors, but it does apply to packages, and maybe boxes.
And boxes can be locked, and even packages can be wrapped with a magical
knotted rope. :-) A novice Inform programmer might well implement that
with a "locked" container, with a magical knife as the key. In which case
"undo package with knife" would be sensible.
To disallow "unwrap door with key", you'd have to define separate actions
for Open and Unwrap... which both do the same thing, except one works on
doors and treasure chests, and the other works on parcels... That becomes
silly. Silly for a general library, I mean. (It might be a good idea in a
particular game.)
Irene Callaci
Yes, it bothers me, but only if the command is something I
should logically be able to do. 'Unwrap door' is not something
I am likely to try, so that particular example doesn't bother
me. However, if I discover the odd synonym by accident, it does
annoy me. For example 'stand up' is synonymous with 'exit' by
default. If the game allows me to 'exit' a room, then 'stand up'
will usually boot me out as well.
irene
On 17 Jan 1998 10:39:15 +0100, m...@bartlet.df.lth.se (Magnus Olsson)
wrote:
>
>What do people think about this from the player's perspective?
>Does it distrub you as a player if the parser recognizes strange
>commands such as "unwrap door with key"?
>
Kenneth Fair
In article <69pu83$ibd$1...@bartlet.df.lth.se>, m...@bartlet.df.lth.se (Magnus
Olsson) wrote:
>In article <ant16214...@arnod.demon.co.uk>,
>Julian Arnold <jo...@arnod.demon.co.uk> wrote:
>>In article <erkyrathE...@netcom.com>, Andrew Plotkin
>><URL:mailto:erky...@netcom.com> wrote:
>>> Verb 'open' 'unwrap' 'uncover' 'undo'
>>> * noun -> Open
>>> * noun 'with' held -> Unlock;
>>
>>"Unwrap door with iron key" indeed!
>
>Indeed :-).
>
>This is actually an explicit philosophy of Graham's: it's acceptable
>if the parser accepts some unheard-of syntax as a consequence of
>having synonyms. That is, for the sake of simplicity the parser
>treats 'unwrap' and 'open' as synonyms, even though they aren't
>exact synonyms in all contexts ("unwrap parcel" and "open parcel"
>are synonymous; "unwrap door" and "open door" usually aren't).
>
>What do people think about this from the player's perspective?
>Does it distrub you as a player if the parser recognizes strange
>commands such as "unwrap door with key"?
I don't mind it so much. I'm much more concerned about getting all
the synonyms right that a normal person might try (not one of you
freaky beta-testers from hell--you know who you are!). While it
can lead to some amusing results, it doesn't often fall down on
the job and it has the benefit of simplification.
--
KEN FAIR - U. Chicago Law | <http://student-www.uchicago.edu/users/kjfair>
Of Counsel, U. of Ediacara | Power Mac! | CABAL(tm) | I'm w/in McQ - R U?
"Any smoothly functioning technology will be
indistinguishable from a rigged demo." Isaac Asimov
Jeff Hatch
Magnus Olsson wrote:
[snip]
> >"Unwrap door with iron key" indeed!
>
> Indeed :-).
>
> This is actually an explicit philosophy of Graham's: it's acceptable
> if the parser accepts some unheard-of syntax as a consequence of
> having synonyms. That is, for the sake of simplicity the parser
> treats 'unwrap' and 'open' as synonyms, even though they aren't
> exact synonyms in all contexts ("unwrap parcel" and "open parcel"
> are synonymous; "unwrap door" and "open door" usually aren't).
>
> What do people think about this from the player's perspective?
> Does it distrub you as a player if the parser recognizes strange
> commands such as "unwrap door with key"?
>VERBOSE
Maximum verbosity.
As a programmer, this method seems vaguely sloppy to me. As a player, I
don't care, since I never try to unwrap doors with keys. But
occasionally other manifestations of this design philosophy irritate me
as a player. Here's my list of the common "dirty" techniques that I
dislike, either as a player or as a programmer.
#1. Discarding the word "the" wherever it appears, as in Zork I.
>LIGHT
What do you want to light?
>THE LIGHT
What do you want to light?
#2. Using a synonym to avoid the trouble of creating a two-part object.
>EXAMINE DESK
The desk drawer is empty.
#3. Mindlessly matching a string of object words to parse an object
name.
>INVENTORY
You are carrying a ripe red tomato and a green tomato.
Red and Jennifer Carey enter the room. "I'm hungry!" Red remarks.
>GIVE RED RED TOMATO
Who do you want to give the ripe red tomato to, Red Carey or Jennifer
Carey?
>GIVE RED CAREY RED TOMATO
Which tomato do you want to give to Red Carey, the ripe red tomato or
the green tomato?
#4. Hacking the library to solve the other problems!
[Example: Problem #63 in the Inform Manual]
"There is no problem with calling a container 'hole in wall', because
the parser will understand 'put apple in hole in wall' as 'put (apple)
in (hole in wall)'. But create a fly in amber, so that 'put fly in amber
in hole in wall' works properly...
The trick is to convert "fly in amber" into "fly fly amber" (a harmless
name) before the parser gets under way.
My theory is that if I disallow nonsense, this may help the parser
understand when the apparent nonsense turns out to be meaningful in an
unexpected way. Example: Most pairs of words which combine to describe
an action can either be both placed at the beginning of a command or put
on opposite sides of the direct object. But when the pronoun "it" is
the direct object, it's customary to place the two words on opposite
sides of the object. That is, "pick it up" is a more natural phrasing
than "pick up it." I intend to give my parser a slight bias against
sentences like "pick up it." Extreme perfectionism, yes. But it would
be helpful in certain (extremely unusual!) circumstances:
>EXAMINE TABLE
Stephen King's _IT_ is on the table.
>TAKE BOOK
You're carrying too many things already.
>DROP MISERY
You drop Stephen King's _Misery_.
>PICK UP IT
You take Stephen King's _IT_.
It takes less time to create a good parser for a game using Graham
Nelson's philosophy of understanding nonsense. But I hope it may take
less time to create an excellent parser using my method, because the
weaknesses in my scheme are easier to find and remedy quickly. For
instance, few programmers could miss this error:
>INVENTORY
You are carrying a beautifully gift-wrapped box and a small brown box
(which is closed).
>UNWRAP BOX
I don't understand the word "unwrap" as a verb.
But would even an experienced Inform beta-tester catch this one?
>INVENTORY
You are carrying a beautifully gift-wrapped box and a small brown box
(which is closed).
>UNWRAP BOX
Which box do you want to open, the beautifully gift-wrapped box or the
small brown box?
>BRIEF
No you weren't. You ranted about impossible hypothetical examples! If
your system will only out-parse Inform in such outlandish situations,
why would anybody switch?
>SHUT UP
I only understood you as far as wanting to close something.
>QUIT. Y
-Rúmil
Chris Marriott
In article <34C1DF...@hatch.net>, Jeff Hatch <je...@hatch.net> writes
>It takes less time to create a good parser for a game using Graham
>Nelson's philosophy of understanding nonsense. But I hope it may take
>less time to create an excellent parser using my method, because the
>weaknesses in my scheme are easier to find and remedy quickly.
Forgive the question, Jeff, I'm not too well up on who's written what.
Which IF development system uses your parser?
Chris
----------------------------------------------------------------
Chris Marriott, Microsoft Certified Solution Developer.
SkyMap Software, U.K. e-mail: ch...@skymap.com
Visit our web site at http://www.skymap.com
Den of Iniquity
On 17 Jan 1998, Magnus Olsson wrote:
>>"Unwrap door with iron key" indeed!
>
>What do people think about this from the player's perspective?
>Does it distrub you as a player if the parser recognizes strange
>commands such as "unwrap door with key"?
It's absurd. If it's pretty certain that no sane player would use such
command then there's no problem with it IMHO. This excepts the case in
which the player tries out daft commands for the purpose of amusement
because one has been told that they work. Like sticking Xyzzies throughout
a command.
Sometimes, such a command might conceivably be useful - in which case the
author should definitely take care of it - if one can "unwrap sardine tin
with key" (OK, it's strained, but it's the best I can do) perhaps one
should avoid mapping unwrap_with to anything else. I dunno. This is a
slightly different question, I think.
--
Den
David A. Cornelson
In article <69pu83$ibd$1...@bartlet.df.lth.se>,
m...@bartlet.df.lth.se (Magnus Olsson) wrote:
>
> In article <ant16214...@arnod.demon.co.uk>,
> Julian Arnold <jo...@arnod.demon.co.uk> wrote:
> >In article <erkyrathE...@netcom.com>, Andrew Plotkin
> ><URL:mailto:erky...@netcom.com> wrote:
> >> Verb 'open' 'unwrap' 'uncover' 'undo'
> >> * noun -> Open
> >> * noun 'with' held -> Unlock;
> >
>
>
> This is actually an explicit philosophy of Graham's: it's acceptable
> if the parser accepts some unheard-of syntax as a consequence of
> having synonyms. That is, for the sake of simplicity the parser
> treats 'unwrap' and 'open' as synonyms, even though they aren't
> exact synonyms in all contexts ("unwrap parcel" and "open parcel"
> are synonymous; "unwrap door" and "open door" usually aren't).
>
> Does it distrub you as a player if the parser recognizes strange
> commands such as "unwrap door with key"?
>
This is a difficult question to ask. First of all, few of us, certainly
not myself, are goung to argue the merits of Graham's code. His code has
helped many of us accomplish something we'd set out to do fifteen years
ago.
On the other hand, this methodology seems to hold us back from improving
the complexity of the parser itself. I say 'us' weakly. If the parser
were to break out all instances of grammar and intention separately then
we could easily continue to build on the foundation. But with these
quirky aspects to the parser, we're sort of funneled into thinking of
logical ways to combine illogical concepts.
I would be in favor of the grammar library being stretched out to handle
each and every statement differently with separate functions. It may take
more time to compile on some machines and it may take up more code, but
it would seem to me to be the right way to 'build' the parser library.
David A. Cornelson
Graham Nelson
> Magnus Olsson wrote:
> > This is actually an explicit philosophy of Graham's: it's acceptable
> > if the parser accepts some unheard-of syntax as a consequence of
> > having synonyms. That is, for the sake of simplicity the parser
> > treats 'unwrap' and 'open' as synonyms, even though they aren't
> > exact synonyms in all contexts ("unwrap parcel" and "open parcel"
> > are synonymous; "unwrap door" and "open door" usually aren't).
Yes, it would be easy not to do this. (Indeed it is easy not
to do this, if you don't want it: you can replace the grammar
for 'unwrap' alone, leaving 'open' where it was.) Ultimately
it saves a little memory in the parse tables, which was an
important consideration in the early years of Inform. It is also
pretty easy to give Inform objects adjectives and nouns as
distinct syntactic parts of names, and some people do indeed
do this; it isn't a fundamental of the Inform parser that the
default arrangement happens not to take this course.
These, then, are not typical examples of the Inform parser's
philosophy, which Jeff refers to below as "understanding nonsense".
The sort of nonsense which the Inform parser intentionally allows
would be something like this:
> PUT ELEPHANT INSIDE SHOEBOX
or this:
> EAT RAINBOW
In principle, the Inform parser should look after syntax, leaving
the semantic interpretation to (i) the verb routines in the first
instance, and (ii) the game itself (which is able to override (i)).
There are, after all, times when the two commands above can make
good semantic sense: a model elephant; a rainbow-cake. And it is
possible to imagine a fantasy game in which a rainbow could be
taken, by a player with supernatural powers. In Inform, the parser
is an early stage of the comprehension process: it is not the
entire process.
Parsing, in short, should understand too much rather than too
little, to maximise later usefulness. It can never understand
exactly the right amount without going beyond its scope and into
the actual game design itself.
> ...
> occasionally other manifestations of this design philosophy irritate me
> as a player. Here's my list of the common "dirty" techniques that I
> dislike, either as a player or as a programmer.
>
> #1. Discarding the word "the" wherever it appears, as in Zork I.
> >LIGHT
> What do you want to light?
> >THE LIGHT
> What do you want to light?
I agree. Inform doesn't even discard the information when parsing
nouns, because the choice of a definite article is important
information when disambiguating (and indeed it can carry inflections
of gender and number in languages other than English: the Inform
algorithm has functioned in Spanish, German, Italian and French as
well as English, and in all of those languages the definite article
is an important clue). It's not even easy to recognise "the" in
some cases: in French, for instance, "l'" can mean "it" or "the",
and is of ambiguous gender but definite number.
> #2. Using a synonym to avoid the trouble of creating a two-part object.
> >EXAMINE DESK
> The desk drawer is empty.
This is, I would argue, a genre convention comparable to the "That's
not something you need to refer to in this game." convention. I don't
find it bothersome, myself, except when the two parts of the object
are each referred to in the game and distinguished between.
> #3. Mindlessly matching a string of object words to parse an object
> name.
> >INVENTORY
> You are carrying a ripe red tomato and a green tomato.
> Red and Jennifer Carey enter the room. "I'm hungry!" Red remarks.
> >GIVE RED RED TOMATO
> Who do you want to give the ripe red tomato to, Red Carey or Jennifer
> Carey?
> >GIVE RED CAREY RED TOMATO
> Which tomato do you want to give to Red Carey, the ripe red tomato or
> the green tomato?
Well, as I mention above, you can easily override this behaviour
in Inform. The present arrangement is quick and convenient, while
apparently not offending too many people in practice. That seems
a sensible compromise to me; Inform gives you the choice, but I don't
think I've seen any Inform-written game where the author chose to
split adjectives and nouns, so it can't matter all that much.
(I could well be wrong about that.)
> #4. Hacking the library to solve the other problems!
> [Example: Problem #63 in the Inform Manual]
> "There is no problem with calling a container 'hole in wall', because
> the parser will understand 'put apple in hole in wall' as 'put (apple)
> in (hole in wall)'. But create a fly in amber, so that 'put fly in amber
> in hole in wall' works properly...
> The trick is to convert "fly in amber" into "fly fly amber" (a harmless
> name) before the parser gets under way.
This is a blatant trick, yes, but to be fair it is given explicitly
as an example of oddball ways you can hack with the parser. You could
solve the same problem more elegantly by instructing the object to
respond to "in" in a noun context only when followed by "amber", for
instance.
The point being demonstrated is that you _can_ program the parser.
I see this as a strength rather than a weakness, even if it means
that Chapter V of the Designer's Manual reads a bit like the Perl
manual sometimes (for better and also for worse).
> My theory is that if I disallow nonsense, this may help the parser
> understand when the apparent nonsense turns out to be meaningful in an
> unexpected way. Example: Most pairs of words which combine to describe
> an action can either be both placed at the beginning of a command or put
> on opposite sides of the direct object. But when the pronoun "it" is
> the direct object, it's customary to place the two words on opposite
> sides of the object. That is, "pick it up" is a more natural phrasing
> than "pick up it." I intend to give my parser a slight bias against
> sentences like "pick up it." Extreme perfectionism, yes. But it would
> be helpful in certain (extremely unusual!) circumstances:
>
> >EXAMINE TABLE
> Stephen King's _IT_ is on the table.
> >TAKE BOOK
> You're carrying too many things already.
> >DROP MISERY
> You drop Stephen King's _Misery_.
> >PICK UP IT
> You take Stephen King's _IT_.
Indeed, the Inform parser has a painstakingly elaborate process to
handle indefinite articles (particularly in non-English languages)
and number-words like this. For instance:
Card School
A room full of green baize tables.
You can see a two of hearts, a two of spades, a jack of hearts,
a seven of spades, a three of clubs and a seven of clubs here.
>get two of spades
Taken.
>get two of clubs
three of clubs: Taken.
seven of clubs: Taken.
>get two
(the two of hearts)
Taken.
>drop two twos
two of hearts: Dropped.
two of spades: Dropped.
It parses phrases like "two of hearts" according to the surrounding
context -- if this seems to be plural, the text is interpreted as
"two of the cards which are of the suit hearts"; if it seems singular,
the text is interpreted as referring to one and only one object; if
there is no textual way to tell, the actual game situation is examined
(as above: "two of clubs" must refer to a pair of items, there being
no actual two of clubs available -- this is an example of Inform's
parser making use of semantic information after all).
> It takes less time to create a good parser for a game using Graham
> Nelson's philosophy of understanding nonsense.
It has taken me something like 25 intermediate states and five
years to get this far...
> But I hope it may take
> less time to create an excellent parser using my method, because the
> weaknesses in my scheme are easier to find and remedy quickly.
I'm not sure from the above what "your method" is, exactly, except
that you seem generally to be arguing against cutting any corners.
But to repeat my distinction above, parsing is the first stage in
comprehension, not the entire process. It is the responsibility of
a game's author to instruct the design system on any special parsing
points likely to arise because of textually unusual items in the
game.
--
Graham Nelson | gra...@gnelson.demon.co.uk | Oxford, United Kingdom
Jeff Hatch
Graham Nelson wrote:
> These, then, are not typical examples of the Inform parser's
> philosophy, which Jeff refers to below as "understanding nonsense".
> The sort of nonsense which the Inform parser intentionally allows
> would be something like this:
>
> > PUT ELEPHANT INSIDE SHOEBOX
>
> or this:
>
> > EAT RAINBOW
Yes, I agree that a parser should allow any syntactically correct
sentence. But by default, your library usually would consider both of
these commands to be nonsense semantically. I think "unwrap door"
should work the same way.
> The present arrangement is quick and convenient, while
> apparently not offending too many people in practice. That seems
> a sensible compromise to me; Inform gives you the choice, but I don't
> think I've seen any Inform-written game where the author chose to
> split adjectives and nouns, so it can't matter all that much.
> (I could well be wrong about that.)
I agree that it's a sensible compromise. Inform does "cut corners," but
whenever you've learned of any problems this causes, you've immediately
corrected them. As a player, the only two parser problems that have
actually offended me are the Zork example I gave, which AFAIK isn't a
problem in any modern system, and the lazy version of the "desk with
drawer," which is the fault of the game programmer and not the parser.
So I have no problems with Inform as a player, only as an idealistic
(and not always practical!) programmer.
[snip]
> > But create a fly in amber, so that 'put fly in amber
> > in hole in wall' works properly...
> > The trick is to convert "fly in amber" into "fly fly amber" (a harmless
> > name) before the parser gets under way.
[snip]
> The point being demonstrated is that you _can_ program the parser.
> I see this as a strength rather than a weakness, even if it means
> that Chapter V of the Designer's Manual reads a bit like the Perl
> manual sometimes (for better and also for worse).
I see that as a strength, too. Of course, one of Inform's other
strengths is that it's seldom necessary to program the parser, and I
think Inform would be even stronger if it were necessary less often.
[snip]
> Indeed, the Inform parser has a painstakingly elaborate process to
> handle indefinite articles (particularly in non-English languages)
> and number-words like this. For instance:
[snip]
> You can see a two of hearts, a two of spades, a jack of hearts,
> a seven of spades, a three of clubs and a seven of clubs here.
>
> >get two of spades
> Taken.
>
> >get two of clubs
> three of clubs: Taken.
> seven of clubs: Taken.
[snip]
To me, that's the epitome of Inform's parsing. A "painstakingly
elaborate process" that is incredibly intelligent in the situations that
it's specifically programmed for.
But my system will be able to distinguish between "get two of spades"
and "get two of clubs" like this without ANY special code being written
in the parser for this situation! Since it can handle this with no
situation-specific code, it will also be able to correctly interpret
other sentences that Inform hasn't been specifically equipped to deal
with, and that I can't even foresee.
> > It takes less time to create a good parser for a game using Graham
> > Nelson's philosophy of understanding nonsense.
>
> It has taken me something like 25 intermediate states and five
> years to get this far...
[snip]
> But to repeat my distinction above, parsing is the first stage in
> comprehension, not the entire process. It is the responsibility of
> a game's author to instruct the design system on any special parsing
> points likely to arise because of textually unusual items in the
> game.
Oops! I meant the game-specific parsing, not the system's parser!
Sorry about that.
In Inform the game programmer wouldn't need to bother making the verb
"Unwrap" work on a wrapped parcel. In mine, he probably would. But
because "Unwrap" and "Open" are synonyms in Inform, unexpected parser
problems can occasionally arise, and these problems are more difficult
to catch.
That's the gist of my intentions. When I write a game using my system,
I'll have to spend more time specifying all the possible adjectives,
nouns and verbs that players will use. But I won't have to fix (or even
look for) parsing problems caused by textually unusual items.
-Rúmil
Jeff Hatch
Chris Marriott wrote:
>
> In article <34C1DF...@hatch.net>, Jeff Hatch <je...@hatch.net> writes
> >It takes less time to create a good parser for a game using Graham
> >less time to create an excellent parser using my method, because the
> >weaknesses in my scheme are easier to find and remedy quickly.
>
> Which IF development system uses your parser?
None of them, not even mine yet. I'm writing my own system, which will
be released later this year. The library (including the parser)
probably won't be completed until this summer, since I've put most of my
effort recently into refining my programming language and interface, and
school starts soon.
-Rúmil
Andrew Plotkin
Jeff Hatch (je...@hatch.net) wrote:
> To me, that's the epitome of Inform's parsing. A "painstakingly
> elaborate process" that is incredibly intelligent in the situations that
> it's specifically programmed for.
> But my system will be able to distinguish between "get two of spades"
> and "get two of clubs" like this without ANY special code being written
> in the parser for this situation! Since it can handle this with no
> situation-specific code, it will also be able to correctly interpret
> other sentences that Inform hasn't been specifically equipped to deal
> with, and that I can't even foresee.
You're making a distinction here that I don't understand. Surely there's
special code to handle this *somewhere*, since it can be handled. It's
parsing, so it's in the parser; it's not situation-specific code,
therefore it's in the standard library (or whatever passes for it in your
system.)
How does this differ from Inform?
Jeff Hatch
Essentially, I have a "universal disambiguator" that's part of my
programming language, not my library. It allows my parser to try every
grammatically possibile interpretation of a sentence and use whichever
one yields the most desirable result.
This is my system's most unique feature AFAIK, and certainly my
favorite. I didn't bring it up earlier because I haven't written enough
of a library to make much use of it yet. My disambiguator has been
fully functional since September--but my system can't understand both
interpretations of "get two of clubs," so there didn't seem to be any
point in advertising its inherent ability to effortlessly distinguish
between the two.
-Rúmil
Den of Iniquity
On Sun, 18 Jan 1998, Jeff Hatch wrote:
>This is my system's most unique feature
Can people please avoid phrases like 'most unique' - it makes my grammar
disambiguator crash. :)
--
Den
Graham Nelson
In article <34C294...@hatch.net>, Jeff Hatch
<URL:mailto:je...@hatch.net> wrote:
>
> Essentially, I have a "universal disambiguator" that's part of my
> programming language, not my library. It allows my parser to try every
> grammatically possibile interpretation of a sentence and use whichever
> one yields the most desirable result.
In your programming language? But that's surely a set of syntactic
rules, not a part of the program. Inform's disambiguation routines
are inside the parser, which seems the only place they could be, really.
There's nothing actually difficult about disambiguating sentence
structure, except with odd cases like interpreting "of" ("two of
clubs" meaning one object, or two?) and "in" ("put the fly in amber
in the hole"), and a few other particles such as numbers, pronouns
and articles. It very seldom happens that there are two radically
different sentences which could be meant.
Instead, the art of disambiguation is deciding what object a
noun-phrase refers to. It had better be said now that there is no
universally agreed, or transcendently obvious, way of doing this;
Inform basically has a pile of rules based on experience of what
mostly works best. The situation only becomes really difficult
when there are plural objects in scope, and which cannot be
distinguished one from another by anything which the player could
type. When adjudicating decisions like this, the Inform parser
has to divide the potential matched objects into equivalence
classes according to distinguishability, and then adjudicate
between the classes.
Graham Nelson
In article <34C27C...@hatch.net>, Jeff Hatch
<URL:mailto:je...@hatch.net> wrote:
> Graham Nelson wrote:
> [snip]
> > Indeed, the Inform parser has a painstakingly elaborate process to
> > handle indefinite articles (particularly in non-English languages)
> > and number-words like this. For instance:
> > a seven of spades, a three of clubs and a seven of clubs here.
> >
> > >get two of spades
> > Taken.
> >
> > >get two of clubs
> > three of clubs: Taken.
> > seven of clubs: Taken.
>
> To me, that's the epitome of Inform's parsing. A "painstakingly
> elaborate process" that is incredibly intelligent in the situations that
> it's specifically programmed for.
>
> But my system will be able to distinguish between "get two of spades"
> and "get two of clubs" like this without ANY special code being written
> in the parser for this situation!
Just to clarify -- the above example required no specific coding
on the part of the game designer. The object names were simply
name "two" "of" "clubs//p"
and so on, and the parser handled the situation entirely on its own.
No "special code" was required on the part of the game designer.
FemaleDeer
>From: Graham Nelson <gra...@gnelson.demon.co.uk>
>Date: Sun, Jan 18, 1998 12:35 EST
> It is the responsibility of
>a game's author to instruct the design system on any special parsing
>points likely to arise because of textually unusual items in the
>game.
>
>
I agree. I think it would be impossible to write a parser to cover every
possible disambiguation. And it would be a tremendous task to split all verbs
into a single instance. If I have unusual objects in my game neccesitating
unusual verbs, >I< as the game designer, then split verbs and add my own
verb/preposition combinations to the grammar part of the library and/or
construct my own verbsub routines to handle the results. This is the beauty of
a programmable ("hackable") library.
Essentially, what it comes down to is, Inform's library does most of the
automatic work, but this does not let the game designer off the hook, he/she
still has to do at least SOME (I would say most) of the work in programming a
game. In my opinion, that is the way it should be.
------------------------------------------------------------------------------
Femal...@aol.com "Good breeding consists in
concealing how much we think of ourselves and how
little we think of the other person." Mark Twain
Magnus Olsson
In article <ant1817361cbM+4%@gnelson.demon.co.uk>,
Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
>In article <34C1DF...@hatch.net>, Jeff Hatch
><URL:mailto:je...@hatch.net> wrote:
>> Magnus Olsson wrote:
>> > This is actually an explicit philosophy of Graham's: it's acceptable
>> > if the parser accepts some unheard-of syntax as a consequence of
>> > having synonyms. That is, for the sake of simplicity the parser
>> > treats 'unwrap' and 'open' as synonyms, even though they aren't
>> > exact synonyms in all contexts ("unwrap parcel" and "open parcel"
>> > are synonymous; "unwrap door" and "open door" usually aren't).
>
>Yes, it would be easy not to do this. (Indeed it is easy not
>to do this, if you don't want it: you can replace the grammar
>for 'unwrap' alone, leaving 'open' where it was.)
I should have pointed this out in my post, lest anyone get the wrong
impression of Inform's flexibility. In fact, I think it is important
to point out to fledgling Inform programmers that not only _can_ they
easily split off synonyms (with "extend only"), but that they _should_
do this in many situations.
>Ultimately
>it saves a little memory in the parse tables, which was an
>important consideration in the early years of Inform.
I suppose so; but even today it is (somewhat) helpful for the
programmer to minimize the number of actions. The extreme case of
having one action for each verb, and no synonyms, would lead to code
like this:
object mirror "mirror"
with
before [ ;
Break, Smash, Destroy, Shatter, Hit, Kick:
"That would mean seven years of bad luck!";
]
;
>These, then, are not typical examples of the Inform parser's
>philosophy,
I'd like to point out that I was using the word "philosophy" in a very
loose sense, and I didn't mean to imply that this is in any case a
fundamental philosophy of Inform in general, but rather just a
principle that's been used in writing grammar.h.
> which Jeff refers to below as "understanding nonsense".
>The sort of nonsense which the Inform parser intentionally allows
>would be something like this:
>
> > PUT ELEPHANT INSIDE SHOEBOX
>
>or this:
>
> > EAT RAINBOW
>
>In principle, the Inform parser should look after syntax, leaving
>the semantic interpretation to (i) the verb routines in the first
>instance, and (ii) the game itself (which is able to override (i)).
Indeed. The parser's domain is essentially syntax, not semantics. But
the boundary line between syntax and semantics is rather fuzzy in
natural langauges: some parsers (such as TADS') try to recognize
prepositional phrases, whereas others (such as Inform's) don't.
And I don't think this is "understanding nonsense"; it's rather
"trying to make sense of nonsense". And it should: if I type "unlock
elephant with me", then I want an appropriate response, not just "I
didn't understand that."
The observation that started this thread was that sometimes the parser
makes the _wrong_ sense of nonsense, as when it parses "unwrap door
with key" as synonymous with "unlock door with key".
>> #2. Using a synonym to avoid the trouble of creating a two-part object.
>> >EXAMINE DESK
>> The desk drawer is empty.
>
>This is, I would argue, a genre convention comparable to the "That's
>not something you need to refer to in this game." convention. I don't
>find it bothersome, myself, except when the two parts of the object
>are each referred to in the game and distinguished between.
Agreed. There are cases where the programmer's been cutting too many
corners, turning what was intended as sensible replies into weird non
sequiturs (because the player was really referring to a different part
of the "multi-part" object in question).
But I don't think we can blame the parser for this, or even pronounce
the genre convention as harmful. We can only be wary of its misuse.
>> #3. Mindlessly matching a string of object words to parse an object
>> name.
>> >INVENTORY
>> You are carrying a ripe red tomato and a green tomato.
>> Red and Jennifer Carey enter the room. "I'm hungry!" Red remarks.
>> >GIVE RED RED TOMATO
>> Who do you want to give the ripe red tomato to, Red Carey or Jennifer
>> Carey?
>> >GIVE RED CAREY RED TOMATO
>> Which tomato do you want to give to Red Carey, the ripe red tomato or
>> the green tomato?
This is actually Infocom's fault, isn't it?
>Well, as I mention above, you can easily override this behaviour
>in Inform. The present arrangement is quick and convenient, while
>apparently not offending too many people in practice. That seems
>a sensible compromise to me;
It's sensible as long as the author avoids having situation where,
for example, nouns and adjectives can be confused, as above. Not all
authors are aware of this, though, or maybe they are, but they have
missed the exercise about adjectives in the Manual.
>Inform gives you the choice, but I don't
>think I've seen any Inform-written game where the author chose to
>split adjectives and nouns, so it can't matter all that much.
>(I could well be wrong about that.)
It matters to me, and when I finally get around to releasing any of
the Inform games I'm working on, you'll see that they do distinguish
between adjectives and nouns.
Jeff Hatch
Graham Nelson wrote:
>
> In article <34C27C...@hatch.net>, Jeff Hatch
> <URL:mailto:je...@hatch.net> wrote:
> > Graham Nelson wrote:
> > [snip]
> > > Indeed, the Inform parser has a painstakingly elaborate process to
> > > handle indefinite articles (particularly in non-English languages)
> > > and number-words like this. For instance:
> > > You can see a two of hearts, a two of spades, a jack of hearts,
> > > a seven of spades, a three of clubs and a seven of clubs here.
> > >
> > > >get two of spades
> > > Taken.
> > >
> > > >get two of clubs
> > > three of clubs: Taken.
> > > seven of clubs: Taken.
> >
> > To me, that's the epitome of Inform's parsing. A "painstakingly
> > elaborate process" that is incredibly intelligent in the situations that
> > it's specifically programmed for.
> >
> > But my system will be able to distinguish between "get two of spades"
> > and "get two of clubs" like this without ANY special code being written
> > in the parser for this situation!
>
> Just to clarify -- the above example required no specific coding
> on the part of the game designer. The object names were simply
>
> name "two" "of" "clubs//p"
>
> and so on, and the parser handled the situation entirely on its own.
> No "special code" was required on the part of the game designer.
>
> Graham Nelson | gra...@gnelson.demon.co.uk | Oxford, United Kingdom
Special code was not required for the game designer, but for the Inform
designer.
Once I write my library to be able to handle plurals in the first place,
it will automatically be able to figure out when the phrase "two of"
refers to an individual item (like the two of clubs) and when it refers
to a group of items.
-Rúmil
Jeff Hatch
Graham Nelson wrote:
>
> In article <34C294...@hatch.net>, Jeff Hatch
Hmm. It appears as though you didn't look closely at the email I sent
you earlier this month on this very topic. It was rather technical and
long-winded, I admit. In essence, I described a simple, powerful
alternative which I hope will completely replace the "pile of rules."
I didn't mention this earlier in rec.arts.int-fiction, since my
library's so primitive that I can't use the disambiguator to do anything
remotely impressive. "Put fly in amber in hole in wall" wouldn't even
work--I haven't enabled multi-word object names yet!
Since I've brought it up now, I'll post a clear, detailed explanation of
my technique sometime this week. (Probably as the start of a new
thread.)
-Rúmil
Jeff Hatch
FemaleDeer wrote:
[snip]
> I agree. I think it would be impossible to write a parser to cover every
> possible disambiguation. And it would be a tremendous task to split all verbs
> into a single instance. If I have unusual objects in my game neccesitating
> unusual verbs, >I< as the game designer, then split verbs and add my own
> verb/preposition combinations to the grammar part of the library and/or
> construct my own verbsub routines to handle the results. This is the beauty of
> a programmable ("hackable") library.
I agree about the verbs to some extent. My difference of opinion on
that subject is only a matter of degree. For instance, I would use
"break" and "destroy" as synonyms--but I don't think that nearly every
violent action imaginable should mean "break," as they do in Inform.
I'll explain the disambiguator soon. I shouldn't have brought it up in
the first place without a clear explanation, really.
-Rúmil
Jeff Hatch
Magnus Olsson wrote:
[snip]
> I suppose so; but even today it is (somewhat) helpful for the
> programmer to minimize the number of actions. The extreme case of
> having one action for each verb, and no synonyms, would lead to code
> like this:
>
> object mirror "mirror"
> with
> before [ ;
> Break, Smash, Destroy, Shatter, Hit, Kick:
> "That would mean seven years of bad luck!";
> ]
> ;
If there were no synonyms, there'd have to be another method of grouping
actions, of course. Perhaps something like this:
object mirror : CFixedItem
{
name = "mirror";
void Before (CActor actor, CAction action)
{
if (action.IsViolent ()) EndMessage ("That would mean seven years of
bad luck!");
}
}
Just because I don't think verbs shouldn't be indistinguisable doesn't
mean I think they should require separate handling.
-Rúmil
Jeff Hatch
Jeff Hatch wrote:
> Just because I don't think verbs shouldn't be indistinguisable doesn't
> mean I think they should require separate handling.
Yikes! A triple negative, a typographical error, and confusing phrasing
all in one sentence. Forgot to proofread that one.
I DO think verbs should be distinguishable, but I don't think they need
necessarily be distinguished in all situations.
-Rúmil
Gunther Schmidl
>For instance, I would use
>"break" and "destroy" as synonyms--but I don't think that nearly every
>violent action imaginable should mean "break," as they do in Inform.
Which reminds me that I'm *really* missing "kick" as a synonym for "attack".
It's the first thing I do when I want to attack something (don't ask me why,
because I don't know...), and I always get annoyed when it doesn't work.
--
+------------------------+----------------------------------------------+
+ Gunther Schmidl + "I couldn't help it. I can resist everything +
+ Ferd.-Markl-Str. 39/16 + except temptation" -- Oscar Wilde +
+ A-4040 LINZ +----------------------------------------------+
+ Tel: 0732 25 28 57 + http://gschmidl.home.ml.org - new & improved +
+------------------------+---+------------------------------------------+
+ sothoth (at) usa (dot) net + please remove the "xxx." before replying +
+----------------------------+------------------------------------------+
Magnus Olsson
>> I suppose so; but even today it is (somewhat) helpful for the
>> programmer to minimize the number of actions. The extreme case of
>> having one action for each verb, and no synonyms, would lead to code
>> like this:
>>
>> object mirror "mirror"
>> with
>> before [ ;
>> Break, Smash, Destroy, Shatter, Hit, Kick:
>> "That would mean seven years of bad luck!";
>> ]
>> ;
>
>actions, of course.
(...)
>Just because I don't think verbs shouldn't be indistinguisable doesn't
>mean I think they should require separate handling.
Of course not. I was being deliberately silly.
I think the best way to think about Inform's grammar.h is as a
*default* set of grammar rules, that works OK with most simple games,
but which you not only *can*, but *should* modify if you want that
little extra from your game. For example, in a game where violence
*is* the answer :-), it's suboptimal to have all violent verbs treated
as synonyms.
Graham Nelson
In article <34c45...@alijku02.edvz.uni-linz.ac.at>, Gunther Schmidl
<URL:mailto:sot...@xxx.usa.net> wrote:
> >For instance, I would use
> >"break" and "destroy" as synonyms--but I don't think that nearly every
> >violent action imaginable should mean "break," as they do in Inform.
>
> Which reminds me that I'm *really* missing "kick" as a synonym for "attack".
> It's the first thing I do when I want to attack something (don't ask me why,
> because I don't know...), and I always get annoyed when it doesn't work.
Just as a historical note, "kick" is a different action from
"attack" in Advent. Try kicking a dwarf, next time you're wandering
around the Hall of Mists.
Graham Nelson
In article <34C40F...@hatch.net>, Jeff Hatch
<URL:mailto:je...@hatch.net> wrote:
>
> Special code was not required for the game designer, but for the Inform
> designer.
>
> Once I write my library to be able to handle plurals in the first place,
> it will automatically be able to figure out when the phrase "two of"
> refers to an individual item (like the two of clubs) and when it refers
> to a group of items.
You've lost me. In what way would that be different from what I've
done?
Kenneth Fair
>>For instance, I would use
>>"break" and "destroy" as synonyms--but I don't think that nearly every
>>violent action imaginable should mean "break," as they do in Inform.
>
>Which reminds me that I'm *really* missing "kick" as a synonym for "attack".
>It's the first thing I do when I want to attack something (don't ask me why,
>because I don't know...), and I always get annoyed when it doesn't work.
Me too. I *always* try "kick."
Jeff Hatch
Graham Nelson wrote:
>
> In article <34C40F...@hatch.net>, Jeff Hatch
> <URL:mailto:je...@hatch.net> wrote:
> >
> > Special code was not required for the game designer, but for the Inform
> > designer.
> >
> > Once I write my library to be able to handle plurals in the first place,
> > it will automatically be able to figure out when the phrase "two of"
> > refers to an individual item (like the two of clubs) and when it refers
> > to a group of items.
>
> You've lost me. In what way would that be different from what I've
> done?
I think I've lost lots of people recently. Have you seen the Inform
"drop all" thread? I'm referring to my disambiguator there, too, and it
doesn't seem to make sense to anyone.
As far as I can tell, you wrote code to enable sentences like "take two
of the cards," a while ago. Later, you spent some time adding clever
disambiguation rules so that sentences like "get two of spades" would
either be interpreted as "take two of the spades," or as "take the two
of spades," depending on the situation. This is what I'm referring to
as "special code." Of course, once you've added that to your library,
game designers won't need to worry about this. Is this correct?
In my system, as soon as I've written code to enable sentences like
"take two of the cards," it'll take me maybe five minutes and a couple
of lines of code to make my parser distinguish between the two
interpretations. Actually, I'll just integrate those lines in the first
place, but hopefully you get the idea. I'm claiming I've found a simple
solution for disambiguation that nearly eliminates the extra work that
would normally be needed to create special rules for unusual
disambiguation situations like this one. So "get ten of spades" would
work using my system, and so would "put fly in amber in hole in wall,"
even though I won't bother to write any special code to handle the use
of "in" or "of" in object names.
I'll post the full explanation either today or tomorrow. This seems to
be impossible to explain piecemeal.
-Rúmil
John J Lee
On 19 Jan 1998, FemaleDeer wrote:
[...]
> If I have unusual objects in my game neccesitating unusual verbs,
> >I< as the game designer, then split verbs and add my own
> verb/preposition combinations to the grammar part of the library and/or
> construct my own verbsub routines to handle the results. This is the
> beauty of a programmable ("hackable") library.
Surely you wouldn't need to change a library to do that? Aren't you just
changing the mapping of an inputted phrase to a verb routine in your
program here? I seem to remember (it was ages ago when I looked at
inform) that this is set by a "grammar file" which is just a list
specifying input syntax vs. verb routine, in order of precedence. Rather
than having to change the actual program that decodes the input, that is.
John
Daniel Shiovitz
In article <6a0l7c$d2f$1...@bartlet.df.lth.se>,
Magnus Olsson <m...@bartlet.df.lth.se> wrote:
>In article <ant1817361cbM+4%@gnelson.demon.co.uk>,
>Graham Nelson <gra...@gnelson.demon.co.uk> wrote:
>I suppose so; but even today it is (somewhat) helpful for the
>programmer to minimize the number of actions. The extreme case of
>having one action for each verb, and no synonyms, would lead to code
>like this:
>
>object mirror "mirror"
>with
> before [ ;
> Break, Smash, Destroy, Shatter, Hit, Kick:
> "That would mean seven years of bad luck!";
> ]
>;
Of course, if you've got a more object-oriented style of verb
definitions, it's possible to get the best of both worlds (more or
less).
pseudo-TADS:
// assume an "open" verb has been defined that uses the "doOpen" action,
// and an "unwrap" verb has been defined that uses the "doUnwrap" action
class item: object
// ...
doOpen() = { "You can't open this up."; }
doUnwrap() = { "This isn't wrapped up!"; }
;
class door: item
// ...
doOpen() = { "You open up the door."; // followed by other door code .. }
// note that "unwrap" will still give the message from "item", above
;
class package: item
// ...
doOpen() = { "You open up the package."; // followed by other code ... }
doUnwrap() = { self.doOpen(); } // ie, redirect the action to doOpen
;
This lets the default be that "unwrap" and "open" are different, but
it's easy for the programmer to unify them if it's appropriate.
Contrariwise, it's also possible to use an OO style to have verbs
default to being the same, but allow the programmer to easily split them when
appropriate.
// more pseudo-TADS. Assume "punch" and "kick" and "break" have all
// been defined previously
class item: object
// ...
doBreak() = { "It's unbreakable, apparently."; }
doPunch() = { self.doBreak(); }
doKick() = { self.doBreak(); }
;
class breakable: item
// ...
doBreak() = { "Hiyah! You break it in two!"; }
// notice you don't have to worry about doPunch or doKick at all;
// they use this new break code automatically
;
class ninja: item
// ...
doBreak() = { "\"You will never break me!\" the ninja hisses."; }
doKick() = { "You perform the Kick of the Ecstatic Moose. The ninja
is impressed"; }
doPunch() = { "You throw the Punch of the Angry Hedgehog, spraining
your wrist in the process."; }
;
This is not a "perfect" solution, at least not with the current TADS
libraries. There are places where the game compares the verb _object_
to see if it's a certain one, and there (since you have multiple verb
objects for break, kick, and punch) you have to add in extra tests,
but it's, IMO, a pretty good solution to the mentioned problems.
>Magnus Olsson (m...@df.lth.se, zeb...@pobox.com)
--
(Dan Shiovitz) (d...@cs.wisc.edu) (look, I have a new e-mail address)
(http://www.cs.wisc.edu/~dbs) (and a new web page also)
(the content, of course, is the same)
Magnus Olsson
In article <6a2som$h...@spool.cs.wisc.edu>,
Daniel Shiovitz <d...@coyote.cs.wisc.edu> wrote:
>Of course, if you've got a more object-oriented style of verb
>definitions, it's possible to get the best of both worlds (more or
>less).
>
>pseudo-TADS:
>// assume an "open" verb has been defined that uses the "doOpen" action,
>// and an "unwrap" verb has been defined that uses the "doUnwrap" action
>
>class item: object
> // ...
> doOpen() = { "You can't open this up."; }
> doUnwrap() = { "This isn't wrapped up!"; }
>;
>
>class door: item
> // ...
> doOpen() = { "You open up the door."; // followed by other door code .. }
> // note that "unwrap" will still give the message from "item", above
>;
>
>class package: item
> // ...
> doOpen() = { "You open up the package."; // followed by other code ... }
> doUnwrap() = { self.doOpen(); } // ie, redirect the action to doOpen
>;
>
>This lets the default be that "unwrap" and "open" are different, but
>it's easy for the programmer to unify them if it's appropriate.
>Contrariwise, it's also possible to use an OO style to have verbs
>default to being the same, but allow the programmer to easily split them when
>appropriate.
I will not argue against the fact that the TADS library is more OO
than Inform's coutnerpart, because it is, but this kind of behaviour
is very easy to get in Inform as well. For example, define
verb 'attack'
* noun -> Attack;
verb 'kick'
* noun -> Kick;
[ AttackSub ;
! Do whatever is necessary here
];
[ KickSub ;
<< Attack noun >>;
];
This will make the kick verb default to the attack verb's action, but
any object that wishes to override this can put a test for Kick in its
before routine.
Lynn Johannesen
Magnus Olsson (m...@bartlet.df.lth.se) wrote:
: >> Verb 'open' 'unwrap' 'uncover' 'undo'
: >> * noun -> Open
: >> * noun 'with' held -> Unlock;
: >
: >"Unwrap door with iron key" indeed!
: What do people think about this from the player's perspective?
: Does it distrub you as a player if the parser recognizes strange
: commands such as "unwrap door with key"?
This discussion has gotten interesting. Several of the posts make
the point that it's easy to get Inform to exhibit more rational
behavior. I agree that Inform is powerful and flexible, and
it will continue to be my IF language of choice.
However, it still seems to me that something is wrong here. Games
that accept "unwrap door with iron key" are buggy. Inform makes
it easy to create games with this sort of bug; indeed, you have
to exert special effort to do otherwise, because they're
inherent in the library as it stands. IMO this represents a flaw
in the language. Of course it may well be that the bugs involved
are unimportant enough, and the benefits involved are great enough,
that there isn't a better way to do it. I'm not convinced one
way or the other, but nothing suggested so far seems clearly better.
The real problem is that parsing English is a lot more complicated
than parsing a computer language, as any AI student can tell you.
Looking at verbs and prepositions is not sufficient to determine
meaning. I'll omit several standard AI examples (which you probably
know) in favor of one from Zork.
[spoilers]
Zork I has a rubber raft, and a pump with which to inflate it.
BLOW UP RAFT works as expected. Zork II has an explosive brick,
and a safe that you need to open by exploding the brick.
BLOW UP BRICK and BLOW UP SAFE produce something like "you cannot
inflate the brick."
I find it amazing, actually, that a verb-preposition parser can
do as well as it does in practice.
Graham Nelson
In article <6a2tno$o0a$1...@bartlet.df.lth.se>, Magnus Olsson
<URL:mailto:m...@bartlet.df.lth.se> wrote:
>
> I will not argue against the fact that the TADS library is more OO
> than Inform's coutnerpart, because it is, but this kind of behaviour
> is very easy to get in Inform as well. For example, define
>
> verb 'attack'
> * noun -> Attack;
>
> verb 'kick'
> * noun -> Kick;
>
> [ AttackSub ;
> ! Do whatever is necessary here
> ];
>
> [ KickSub ;
> << Attack noun >>;
> ];
>
> This will make the kick verb default to the attack verb's action, but
> any object that wishes to override this can put a test for Kick in its
> before routine.
Indeed, this is precisely how "kick" is implemented in the Inform
example game "Advent".
Daryl McCullough
In article <lynnjEn...@netcom.com>, ly...@netcom.com says...
>However, it still seems to me that something is wrong here. Games
>that accept "unwrap door with iron key" are buggy.
Why? It seems to me that a bug in a game means that there is a
way for a sensible command to produce a nonsensical result. It
isn't a bug for a nonsensical command to produce a sensible
result. When it comes to nonsensical commands, it seems to me
that the criterion should be robustness; the game shouldn't
crash because of a typo.
>[spoilers]
>
>Zork I has a rubber raft, and a pump with which to inflate it.
>BLOW UP RAFT works as expected. Zork II has an explosive brick,
>and a safe that you need to open by exploding the brick.
>BLOW UP BRICK and BLOW UP SAFE produce something like "you cannot
>inflate the brick."
Now *that's* a bug, when a sensible command produces nonsensical
results. I guess the point that you (and others) have been making
is that the same loose parsing (in particular, the use of loose
synonyms) that allows nonsense like "unwrap the door" also allows
misparsing of "blow up safe". However, Inform allows for the safe
to override the default response to "blow up", doesn't it?
Daryl McCullough
CoGenTex, Inc.
Ithaca, NY
Magnus Olsson
In article <lynnjEn...@netcom.com>,
Lynn Johannesen <ly...@netcom.com> wrote:
>However, it still seems to me that something is wrong here. Games
>that accept "unwrap door with iron key" are buggy.
A point of terminology: if the designer of the game, or of
the design system used to make the game, consciously designed
this into it (or at least was aware of that his/her design choices
would have this effect), then it's not a bug. You might call it
a misfeature, or bad design.
>Inform makes
>it easy to create games with this sort of bug; indeed, you have
>to exert special effort to do otherwise, because they're
>inherent in the library as it stands. IMO this represents a flaw
>in the language.
You must separate the language from the library here. Inform doesn't
make it "easy to create games with this sort of bug", because
Inform the language doesn't know anything about grammar.
However, as you write, the Inform library does contain these flaws.
The simple fix would of course be to try to remove all such things
from the library, so that, say, "unwrap door with key" would be
interpreted as distinct from "open door with key" and handled
accordingly.
However, trying to make a *language* that wouldn't accept such things
would be a very difficult thing. You'd have to put a lot of
understaning of natural language into Inform (and its libraries);
and I simply don't think it's possible with today's state of the art
of language processing. (The Grail we're looking for is a tool
(not necessarily a programming language) that allowed the construction
of parsers that accept only true subsets of English. Quite a tall order,
to say the least.)
No, I think it's up to the game programmer. If you're writing an Inform
game, and don't think your users should be subjected to this kind
of confusion, then rewrite all the grammar productions that accept
such malapropisms, and don't add any of your own.
>The real problem is that parsing English is a lot more complicated
>than parsing a computer language, as any AI student can tell you.
>Looking at verbs and prepositions is not sufficient to determine
>meaning.
Looking at verbs and prepositions is mostly syntactical analysis.
What is need is *semantic* analysis. Which requires some form of
true understanding.
Jeff Hatch
Lynn Johannesen wrote:
> The real problem is that parsing English is a lot more complicated
> than parsing a computer language, as any AI student can tell you.
> Looking at verbs and prepositions is not sufficient to determine
> meaning. I'll omit several standard AI examples (which you probably
> know) in favor of one from Zork.
[ZORK SPOILERS FOLLOW...]
> Zork I has a rubber raft, and a pump with which to inflate it.
> BLOW UP RAFT works as expected. Zork II has an explosive brick,
> and a safe that you need to open by exploding the brick.
> BLOW UP BRICK and BLOW UP SAFE produce something like "you cannot
> inflate the brick."
>
> I find it amazing, actually, that a verb-preposition parser can
> do as well as it does in practice.
Once again, my parser's disambiguator could easily handle this problem.
It can allow the phrase "blow up" to have two possible meanings--either
"explode" or "inflate." In most situations, it would be quite obvious
which one makes more sense, and the parser would interpret the command
correctly. No extra work would be required by the game designer.
For a long-winded, detailed explanation of how this works, see my
"Disambiguation tricks" post. Briefly: My parser would try the entire
command both ways and then do whichever one yielded the "most sensible"
result. (The most sensible result is defined by an error number in the
library--for instance, "The raft is already inflated" would be
considered a better result than "I don't know how to explode the raft.")
Magnus Olsson wrote:
> Looking at verbs and prepositions is mostly syntactical analysis.
> What is [needed] is *semantic* analysis. Which requires some form of
> true understanding.
All the games that are written already have some form of semantic
analysis--enough to run the game, at least. The easy way to give the
parser more apparent intelligence is to let it access the rest of the
game in making its decisions.
-Rúmil
Jeff Hatch
Den of Iniquity wrote:
> On 17 Jan 1998, Magnus Olsson wrote:
>
> >>"Unwrap door with iron key" indeed!
> >
> >What do people think about this from the player's perspective?
> >Does it distrub you as a player if the parser recognizes strange
> >commands such as "unwrap door with key"?
>
> command then there's no problem with it IMHO. This excepts the case in
> which the player tries out daft commands for the purpose of amusement
> because one has been told that they work. Like sticking Xyzzies throughout
> a command.
>
> Sometimes, such a command might conceivably be useful - in which case the
> author should definitely take care of it - if one can "unwrap sardine tin
> with key" (OK, it's strained, but it's the best I can do) perhaps one
> should avoid mapping unwrap_with to anything else. I dunno. This is a
> slightly different question, I think.
I just thought of one more practical reason to disallow such strange
verb matchings. This one doesn't apply to Inform at all, though.
No one would every try "unwrap door with key." But consider this:
>EXAMINE CHEST
The chest is closed. Sitting on the top of the chest is a beautifully
wrapped package.
>UNWRAP IT
You open the chest, and the package falls onto the floor.
Even my system would give this result if "unwrap" and "open" were
synonyms. But my system will allows multiple possible matches for the
word "it," so if "unwrap chest" gave an error message, my system would
instead try to interpret the second command as "unwrap package."
My initial dislike for Mr Nelson's use of synonyms was mostly because I
value "clean" code as a programmer. In most situations, the extra
synonym won't make a difference. But (as always) it's much easier to
expand the program's capabilities if "clean" code is used.
As has been pointed out quite often, it would be easy to split verbs in
Inform. But it would be even easier if Mr Nelson had done the splitting
and had provided "rejoining" functions like "IsViolent." As it is, if
you want to split a verb for one specific situation, you'll have to make
sure that the verbs still do the same thing in all other situations.
(No difficult task, certainly. Any system is easy to modify as needed
-- which is why none of the reasons given for or against Graham's
philosophy are very compelling.)
-Rúmil
Mary K. Kuhner
>Once again, my parser's disambiguator could easily handle this problem.
>It can allow the phrase "blow up" to have two possible meanings--either
>"explode" or "inflate." In most situations, it would be quite obvious
>which one makes more sense, and the parser would interpret the command
>correctly. No extra work would be required by the game designer.
>For a long-winded, detailed explanation of how this works, see my
>"Disambiguation tricks" post. Briefly: My parser would try the entire
>command both ways and then do whichever one yielded the "most sensible"
>result. (The most sensible result is defined by an error number in the
>library--for instance, "The raft is already inflated" would be
>considered a better result than "I don't know how to explode the raft.")
But suppose that you have a rubber raft, a bomb, and a pump? Now
>blow up raft
seems to me to be totally ambiguous--honestly, even a human being
can't be sure what it means. Perhaps you really want to destroy the
raft--after all, there might be a treasure hidden inside--or perhaps
you really want to inflate it.
At some point I think the player needs to be more clear--there is
no way to avoid silly responses if you try to deal with this statement.
No matter which way you assign the error numbers, you may not
catch the player's intended meaning. Best to issue a
disambiguation message and leave it at that. ("What do you want to
blow it up with?")
I do like the idea of your system, though. My only worry is that in
getting rid of one class of errors, it may introduce another; because
it prefers "successful" responses, it may tend to do things that it
shouldn't. For example, trying to blow up the raft when you are
*not* carrying the pump, it seems to me, runs a risk of getting
the bomb, rather than a complaint that you don't have anything to
blow it up with. The parser *still* isn't really grasping the
situation.
Scoring those error messages is also going to be an interesting
design exercise all by itself. I doubt you can do it all in the
library--seems like the author will have to contribute some
scoring, or how can you tell whether blowing up (in either sense)
the raft makes any sense at all?
Mary Kuhner mkku...@genetics.washington.edu
Magnus Olsson
>
>> Zork I has a rubber raft, and a pump with which to inflate it.
>> BLOW UP RAFT works as expected. Zork II has an explosive brick,
>> and a safe that you need to open by exploding the brick.
>> BLOW UP BRICK and BLOW UP SAFE produce something like "you cannot
>> inflate the brick."
>>
>> I find it amazing, actually, that a verb-preposition parser can
>> do as well as it does in practice.
>
>It can allow the phrase "blow up" to have two possible meanings--either
>"explode" or "inflate." In most situations, it would be quite obvious
>which one makes more sense, and the parser would interpret the command
>correctly. No extra work would be required by the game designer.
You can do this in Inform as well, on the parser level. Suppose that
inflatable objects have the attribute "inflatable". Then you can
have the grammar productions
verb 'blow'
* 'up' inflatable -> Inflate
* 'up' noun -> Blast;
>For a long-winded, detailed explanation of how this works, see my
>"Disambiguation tricks" post. Briefly: My parser would try the entire
>command both ways and then do whichever one yielded the "most sensible"
>result. (The most sensible result is defined by an error number in the
>library--for instance, "The raft is already inflated" would be
>considered a better result than "I don't know how to explode the raft.")
This is a more flexible technique. I think the TADS parser works in this
way, though IIRC its definition of "sensible" is a Boolean one: it tries
various interpretations of the input sentence and accepts the first one
where the various "verify" methods don't print any error messages.
>Magnus Olsson wrote:
>> Looking at verbs and prepositions is mostly syntactical analysis.
>> What is [needed] is *semantic* analysis. Which requires some form of
>> true understanding.
>
>All the games that are written already have some form of semantic
>analysis--enough to run the game, at least. The easy way to give the
>parser more apparent intelligence is to let it access the rest of the
>game in making its decisions.
Of course. I didn't mean to imply otherwise. In fact, since naturla
languages are context sensitive in both the grammatical and the wider
sense (i.e. a word's meaning depends both on the rest of the sentence
and on the context in which the meaning was said), I think this is
necessary.
Francis Irving
On 22 Jan 1998 00:17:19 GMT,
mkku...@evolution.genetics.washington.edu (Mary K. Kuhner) wrote:
>But suppose that you have a rubber raft, a bomb, and a pump? Now
>
>>blow up raft
>
>seems to me to be totally ambiguous--honestly, even a human being
>can't be sure what it means. Perhaps you really want to destroy the
>raft--after all, there might be a treasure hidden inside--or perhaps
>you really want to inflate it.
>
>At some point I think the player needs to be more clear--there is
>no way to avoid silly responses if you try to deal with this statement.
>No matter which way you assign the error numbers, you may not
>catch the player's intended meaning. Best to issue a
>disambiguation message and leave it at that. ("What do you want to
>blow it up with?")
So the answer to that is to hook into the scoring the concept of
multiple "winning" interpretations, and then ask amongst them.
This is then starting to sound like what people have been saying about
TADS "verify" - except instead of doing the first "ok" response from
the verify routine, you offer a choice of any of them.
As to what text you use to offer the choice...
Francis.
Work: fra...@ncgraphics.co.uk Home: fra...@pobox.co.uk
Iain Merrick
Jeff Hatch wrote:
[snip]
> Once again, my parser's disambiguator could easily handle this problem.
> It can allow the phrase "blow up" to have two possible meanings--either
> "explode" or "inflate." In most situations, it would be quite obvious
> which one makes more sense, and the parser would interpret the command
> correctly. No extra work would be required by the game designer.
>
> For a long-winded, detailed explanation of how this works, see my
> "Disambiguation tricks" post. Briefly: My parser would try the entire
> command both ways and then do whichever one yielded the "most sensible"
> result. (The most sensible result is defined by an error number in the
> library--for instance, "The raft is already inflated" would be
> considered a better result than "I don't know how to explode the raft.")
(I missed the post you mention; sorry if you've already covered this
point)
What about side effects? Surely the act of 'trying out the command'
could potentially change the state of the program. This could lead to
some strange effects, where 'ghost' commands which the parser
tentatively tried but abandoned still do things behind the scenes.
It seems to me that you'd have to either:
ensure that the relevant part of the parser is purely functional (has no
side-effects). If you're allowing user code to be included in the
trying-out phase, it would have to be purely functional, too.
- or -
'snapshot' the program state before trying out each command and restore
it afterwards.
The former is neater, but involves a large philosophical leap away from
the programming model used by TADS, Inform etc... purely functional
languages can be very nice, but also very strange. I'm not sure how
feasible the latter would be - I'm imagining something like 'fork' under
UNIX, which is a relatively expensive process.
Have you considered this, or have I thrown a spanner in the works? Or am
I overlooking something?
> Magnus Olsson wrote:
> > Looking at verbs and prepositions is mostly syntactical analysis.
> > What is [needed] is *semantic* analysis. Which requires some form of
> > true understanding.
>
> All the games that are written already have some form of semantic
> analysis--enough to run the game, at least. The easy way to give the
> parser more apparent intelligence is to let it access the rest of the
> game in making its decisions.
But (to summarise) how can it access the rest of the game without
_changing_ the rest of the game?
Iain Merrick
i...@cs.york.ac.uk
Lynn Johannesen
Magnus Olsson (m...@bartlet.df.lth.se) wrote:
: In article <lynnjEn...@netcom.com>,
: Lynn Johannesen <ly...@netcom.com> wrote:
: >However, it still seems to me that something is wrong here. Games
: >that accept "unwrap door with iron key" are buggy.
: A point of terminology: if the designer of the game, or of
: the design system used to make the game, consciously designed
: this into it (or at least was aware of that his/her design choices
: would have this effect), then it's not a bug. You might call it
: a misfeature, or bad design.
The designer of the game, yes. The designer of the design system,
no; although in that case the game designer may blame his bug on
the designer of the design system, if his mind works that way.
Since you bring it up, let's see how important an effect this
is in practice. How many of you game designers out there gave
any thought to what "unwrap door with key" would do?
: >Inform makes
: >it easy to create games with this sort of bug; indeed, you have
: >to exert special effort to do otherwise, because they're
: >inherent in the library as it stands. IMO this represents a flaw
: >in the language.
: You must separate the language from the library here. Inform doesn't
: make it "easy to create games with this sort of bug", because
: Inform the language doesn't know anything about grammar.
You can look at it that way, I suppose. I consider the langauge
and the library to be a whole, as I do with C; I'd no more modify
an Inform library file than I would <stdio.h>. You can write
C programs without using the library, but they won't be very
interesting (no I/O).
: However, trying to make a *language* that wouldn't accept such things
: would be a very difficult thing. You'd have to put a lot of
: understaning of natural language into Inform (and its libraries);
: and I simply don't think it's possible with today's state of the art
: of language processing. (The Grail we're looking for is a tool
: (not necessarily a programming language) that allowed the construction
: of parsers that accept only true subsets of English. Quite a tall order,
: to say the least.)
Yes, exactly. I don't think we're going to make much progress in
this area until somebody figures out how to do this. Exclusive use
of the imperative mood gets rid of a lot of the problems that plague
AI researchers, to be sure. You don't have the infamous "which word
is the verb" problem:
TIME FLIES LIKE AN ARROW
FRUIT FLIES LIKE A BANANA
because the verb is determined positionally. OTOH, use of the
imperative in conversation with NPCs is a major stumbling block
to achieving anything remotely realistic. People don't talk that
way, and I don't think we're going to see believable NPCs until
we can speak with them without using the imperative. I'm not
holding my breath.
Jeff Hatch
Magnus Olsson wrote:
>
> In article <34C675...@hatch.net>, Jeff Hatch <je...@hatch.net> wrote:
> >Lynn Johannesen wrote:
> >
> >> Zork I has a rubber raft, and a pump with which to inflate it.
> >> BLOW UP RAFT works as expected. Zork II has an explosive brick,
> >> and a safe that you need to open by exploding the brick.
> >> BLOW UP BRICK and BLOW UP SAFE produce something like "you cannot
> >> inflate the brick."
> >>
> >> I find it amazing, actually, that a verb-preposition parser can
> >> do as well as it does in practice.
> >
> >It can allow the phrase "blow up" to have two possible meanings--either
> >"explode" or "inflate." In most situations, it would be quite obvious
> >which one makes more sense, and the parser would interpret the command
> >correctly. No extra work would be required by the game designer.
>
> inflatable objects have the attribute "inflatable". Then you can
> have the grammar productions
>
> verb 'blow'
> * 'up' inflatable -> Inflate
> * 'up' noun -> Blast;
Sure, that works. Inform is a very good system, so it could easily be
adapted to handle most of my examples of sentences Inform "can't
handle." My system will be better in this particular area--but it'll
need to be at least as good as Inform in many, many other ways before
anyone will even consider using it.
>
> >For a long-winded, detailed explanation of how this works, see my
> >"Disambiguation tricks" post. Briefly: My parser would try the entire
> >command both ways and then do whichever one yielded the "most sensible"
> >result. (The most sensible result is defined by an error number in the
> >library--for instance, "The raft is already inflated" would be
> >considered a better result than "I don't know how to explode the raft.")
>
> This is a more flexible technique. I think the TADS parser works in this
> way, though IIRC its definition of "sensible" is a Boolean one: it tries
> various interpretations of the input sentence and accepts the first one
> where the various "verify" methods don't print any error messages.
You recall correctly.
When I first read the TADS manual, I was amazed at how many of my ideas
Michael Roberts had almost but not quite implemented. Namely, he
created "verify" methods, a multi-turn Undo feature, and a huge
scrollback buffer, but he didn't link these features together to allow
"verify" methods to safely change variables or to allow the Undo feature
to actually erase the last move from the screen.
-Rúmil
Joe Mason
In article <6a5idb$vpd$1...@bartlet.df.lth.se>,
Magnus Olsson <m...@bartlet.df.lth.se> wrote:
>
>Looking at verbs and prepositions is mostly syntactical analysis.
>true understanding.
At first glance, I like Rumil's parser concept. I haven't thought it all the
way through for the implications, but I think a heirarchy of ways which a
command can go wrong may be a good way to impart "understanding" to a system.
In a way, it reminds me of C.E. Forman's reviews: we're all used to giving
points for things that impress us, but he went about it the other way around.
Similiarly, we're used to thinking "how can we get a program to recognize when
something is right?" and giving up. Rumil is saying that, if all
interpretations of a command fail but one, what's left must be the correct
way to parse it. The system need not actually understand what that last way
is, but since failure messages are built into the system anyway, we already
have parser's which know most of the ways an input can come up short.
Joe
Jeff Hatch
Mary K. Kuhner wrote:
> But suppose that you have a rubber raft, a bomb, and a pump? Now
>
> >blow up raft
>
> seems to me to be totally ambiguous--honestly, even a human being
> can't be sure what it means. Perhaps you really want to destroy the
> raft--after all, there might be a treasure hidden inside--or perhaps
> you really want to inflate it.
>
> At some point I think the player needs to be more clear--there is
> no way to avoid silly responses if you try to deal with this statement.
> No matter which way you assign the error numbers, you may not
> catch the player's intended meaning. Best to issue a
> disambiguation message and leave it at that. ("What do you want to
> blow it up with?")
>
> getting rid of one class of errors, it may introduce another; because
> it prefers "successful" responses, it may tend to do things that it
> shouldn't. For example, trying to blow up the raft when you are
> *not* carrying the pump, it seems to me, runs a risk of getting
> the bomb, rather than a complaint that you don't have anything to
> blow it up with. The parser *still* isn't really grasping the
> situation.
>
> Scoring those error messages is also going to be an interesting
> design exercise all by itself. I doubt you can do it all in the
> library--seems like the author will have to contribute some
> scoring, or how can you tell whether blowing up (in either sense)
> the raft makes any sense at all?
My "branch" statement has an "ambiguity" statement to go with it. It
will be able to handle truly ambiguous statements, though I haven't
finished the technical work required to make this possible. I'll go
into a little more detail when I write a technical follow-up to the
"Disambiguation tricks" post.
Yes, assigning the error numbers will be difficult. I hope to do most
of it myself and leave very little work for authors. Some cases are
easy to handle in the library; an attempt to inflate a book would access
the library default message "I don't know how to inflate the book,"
which would have an appropriate error number. I hope to provide some
simple error functions so that authors won't need to use any actual
error numbers. For instance, trying to blow up the raft might be
accomplished like this:
if (verb == Explode) DangerousWarning ("You would die in the
explosion!");
The "DangerousWarning" function would print the message and assign an
appropriate error level.
-Rúmil
Joe Mason
In article <34C74C...@cs.york.ac.uk>,
Iain Merrick <i...@cs.york.ac.uk> wrote:
>
>But (to summarise) how can it access the rest of the game without
>_changing_ the rest of the game?
Aaaaaah! The Uncertainty Principle rears its ugly head!
Curse you, Heisenberg, curse you!
Joe
FemaleDeer
>From: kjf...@midway.uchicago.edu.REMOVEME (Kenneth Fair)
>Date: Tue, Jan 20, 1998 11:26 EST
>>Which reminds me that I'm *really* missing "kick" as a synonym for "attack".
>>It's the first thing I do when I want to attack something (don't ask me why,
>>because I don't know...), and I always get annoyed when it doesn't work.
>
>Me too. I *always* try "kick."
>
>
I always ADD kick as a synonym. (Women tend to use their lower legs more for
violent actions because they have more strength in their legs than in their
arms, usually. Self-defense courses, for instance, teach women to kick because
they know this. Men have more upper body strength.) Which is why I always add
kick.
FD
------------------------------------------------------------------------------
Femal...@aol.com "Good breeding consists in
concealing how much we think of ourselves and how
little we think of the other person." Mark Twain
FemaleDeer
>From: John J Lee <jjl...@york.ac.uk>
>Date: Tue, Jan 20, 1998 13:14 EST
>Surely you wouldn't need to change a library to do that?
No, technically you don't need to touch grammar.h. You use replace or first or
something when adding your own verbs oi splitting up existing verbs and
synonyms.
FD :-)
Iain Merrick
Joe Mason wrote:
Ha!
What next?
> blow up raft
You attempt to inflate the raft, but due to random quantum fluctuations
your alter-ego in a parallel universe gets there first and explodes it
with a stick of dynamite.