What would you expect from a good parser?

247 views
Skip to first unread message

Pontus Wickholm

unread,
Sep 3, 2000, 6:13:15 PM9/3/00
to
I'm currently writing an IF game in C++. I know there are more suitable
languages to program IF than C++ (Inform, TADS...) but I'm more interested
in improving my C++ skills than lerning an entirely new language. So why did
I choose IF? Well, I simply think that IF is a very good implementation of
OOP.

The parser I'm working on is, at this stage, able to make sense out of
sentences with multiple nouns

->examine table,lamp

dividing the above statement into
1. examine table
2. examine lamp

It can also "understand" sentences with multiple verbs

->open,examine,close box

dividing the above statement into

1. open box
2. examine box
3. examine lamp

A macro function gives the user the ability to define his/hers own commands

->define "peek" as "open,examine,close"

now

->peek box

will have the same effect as

->open,examine,close box

The parser is also able to distinguish homonymous nouns

->examine file cabinet

"The file cabinet has two rows of drawers, one on the left, the other on the
right. Every row has three drawers; an upper, a middle and a lower one."

by typing

-> examine upper left drawer

the description of the upper left drawer is produced

The parser can also manage the plural form

->examine drawers

will produce the descriptions of all the six drawers.
This can also be done in conjunction with adjectives

->examine left drawers

will produce the descriptions of all the three drawers that are situated in
the left row.

This is how far I've got. I know there is a *lot* of work to be done before
I have something even resembling a good parser. If you have any comments I
would be glad to hear them.


Pontus Wickholm

unread,
Sep 3, 2000, 6:14:46 PM9/3/00
to
> It can also "understand" sentences with multiple verbs
>
> ->open,examine,close box
>
> dividing the above statement into
>
> 1. open box
> 2. examine box
> 3. examine lamp

Should be "close box"

Jonadab the Unsightly One

unread,
Sep 15, 2000, 3:00:00 AM9/15/00
to
"Pontus Wickholm" <pontus_...@hotmail.com> wrote:

> I'm currently writing an IF game in C++. I know there are more suitable
> languages to program IF than C++ (Inform, TADS...) but I'm more interested
> in improving my C++ skills than lerning an entirely new language.

Fair enough. I hope you're also more interested in improving your
C++ skills than writing IF, because you'll be spending a lot of
extra time just because you're writing in a language without an
extant IF library. That's okay, if what you really want is to
exercise your C++ abilities. As I've said, IF is a pretty
advanced exercise, with plenty of room to stretch you.

> So why did I choose IF? Well, I simply think that IF is
> a very good implementation of OOP.

Yes, IF just *screams* OOP. (OTOH, C++ is not my idea
of good OO, but nevermind; I think part of the problem
there is that my attempts to learn C++ have been thwarted
by the poor documentation I found.)

> The parser I'm working on is, at this stage, able to make
> sense out of sentences with multiple nouns
>
> ->examine table,lamp
>
> dividing the above statement into
> 1. examine table
> 2. examine lamp

That's a good start. Besides the comma, you'll want it
to handle "and", of course. If you have both a comma
*and* "and", then you want to check to see if it's
already in a comma-separated list; if so then you
parse it the same as just "and"; if not, then you
want to treat the remainder as a new clause.

> It can also "understand" sentences with multiple verbs
>
> ->open,examine,close box
>
> dividing the above statement into
>
> 1. open box
> 2. examine box
> 3. examine lamp

Hmmm... that's not very much like standard English
(although with "and" it gets a lot closer). The functionality
would be cool, but how is the user going to think to type that?

> A macro function gives the user the ability to define his/hers own commands

That's good.

> ->define "peek" as "open,examine,close"
>
> now
>
> ->peek box
>
> will have the same effect as
>
> ->open,examine,close box

At some point you're going to have to decide how to
handle prepositions.

> The parser is also able to distinguish homonymous nouns
>
> ->examine file cabinet
>
> "The file cabinet has two rows of drawers, one on the left, the other on the
> right. Every row has three drawers; an upper, a middle and a lower one."
>
> by typing
>
> -> examine upper left drawer
>
> the description of the upper left drawer is produced

Good.

When you're ready for the next step, make it distinguish
the phone, the phone book, the phone booth, and the novel
(which can also be called simply "book" if the phone book
isn't present). (Yeah. If this newsgroup ever runs out
of suggestions for your parser you will have learned
the language you're using *really* well by sheer amount
of practice gained.)

> The parser can also manage the plural form
>
> ->examine drawers
>
> will produce the descriptions of all the six drawers.
> This can also be done in conjunction with adjectives
>
> ->examine left drawers
>
> will produce the descriptions of all the three drawers that are situated in
> the left row.

Nice. The standard Inform library needs an extra grammar
line added to do that.

How does your parser handle special cases of object positioning,
such as removing objects from a box (preferring to match only
items that are in the box), dropping (preferring to match only
things the player is holding), et cetera? There are a lot of
different cases of this, but in general you have an action that
makes the most sense for objects for which some condition is
true, the object's location being the most frequent condition.
You do have an object tree for determining where an object is,
right? Besides object location, sometimes other state is
interesting. If the player types "open the door", you want
to prefer the closed door over the open one, all else being
equal... of course, if the player types "open the red door"
then you only consider doors that are red; I think from what
you've said that you already have that part handled.

> This is how far I've got. I know there is a *lot* of work to be done before
> I have something even resembling a good parser. If you have any comments I
> would be glad to hear them.

If you eventually want to do something that is hard for some
existing parsers, including the Inform parser, allow multiple
objects two places on the same grammar line -- such as a
compound direct object *and* a compound indirect object.
Inform can only do this with a complicated routine token
that has to do a lot of the parsing of the line by hand; I've
never seen it done. However, you should probably hold off
on that sort of thing until you have the stuff that existing
parsers *can* do, first. But you might keep it in mind and
build your design in a way that makes it possible to add
stuff like that later.

Another thing existing parsers don't do terribly well is
handle other conjunctions, like "but". Something to work
toward in the long term.


--

Forward all spam to u...@ftc.gov

Pontus Wickholm

unread,
Sep 15, 2000, 3:00:00 AM9/15/00
to

Jonadab the Unsightly One <jon...@bright.net> skrev i
diskussionsgruppsmeddelandet:39c20590...@news.bright.net...

The parser treats "and" as synonymous with a comma. Commas, and "ands", are
used to disambiguate sentences like the following.
->examine and plant plant in pot
The rule is that the word to the right of the comma (or the "and") is of the
same type as the word immediately to the left, thus the first "plant" is
treated as a verb and the second as a noun. If there is no comma (or "and")
the word to the right is presumed to be of a different type than the word to
the left. The same rule applies to nouns and adjectives.
->examine bathroom,door
The line above will produce the descriptions of "bathroom" and "door"
whereas
->examine bathroom door
will produce the description of "bathroom door"

>If you have both a comma
> *and* "and", then you want to check to see if it's
> already in a comma-separated list; if so then you
> parse it the same as just "and"; if not, then you
> want to treat the remainder as a new clause.

Do you mean something like the following?
->open,examine upper left drawer and close it
In this case the parser will treat the "and" as synonymous with "then" thus
"close it" will be treated as a new sentence (is that what you meant by "new
clause"?). The parser does so not because there is an and but because there
is a noun preceeding the "close" verb.

> > It can also "understand" sentences with multiple verbs
> >
> > ->open,examine,close box
> >
> > dividing the above statement into
> >
> > 1. open box
> > 2. examine box
> > 3. examine lamp
>
> Hmmm... that's not very much like standard English
> (although with "and" it gets a lot closer).

I agree it looks somewhat strange but it's a necessary feature in order to
make the macros work.

> The functionality
> would be cool, but how is the user going to think to type that?

This is not something the player *has got* to know in order to solve the
game. It's more like a special feature for "advanced users" who, by the way,
are presumed to have carefully read the "ReadMe!" file.

> > A macro function gives the user the ability to define his/hers own
commands
>
> That's good.
>
> > ->define "peek" as "open,examine,close"
> >
> > now
> >
> > ->peek box
> >
> > will have the same effect as
> >
> > ->open,examine,close box
>
> At some point you're going to have to decide how to
> handle prepositions.

The parser currently recognizes five pepositions; on, in (inside), by (next
to), under (underneath), behind. They are treated as "aspects" of objects,
"on" being the "default aspect".
->examine desk
will produce the following description
"It's an imposing desk made out of oak. There is a lamp and a notepad on the
desk."
while
->examine underneath desk
will produce
"There is a note lying under the desk."
The sentence
->examine desk, inside desk, by desk, underneath desk, behind desk (I've
thought of allowing the use of multiple prepositions "examine
on,under,behind desk" but it's too complicated at this stage.)
is equivalent to
->search desk

> > The parser is also able to distinguish homonymous nouns
> >
> > ->examine file cabinet
> >
> > "The file cabinet has two rows of drawers, one on the left, the other on
the
> > right. Every row has three drawers; an upper, a middle and a lower one."
> >
> > by typing
> >
> > -> examine upper left drawer
> >
> > the description of the upper left drawer is produced
>
> Good.
>
> When you're ready for the next step, make it distinguish
> the phone, the phone book, the phone booth, and the novel
> (which can also be called simply "book" if the phone book
> isn't present). (Yeah. If this newsgroup ever runs out
> of suggestions for your parser you will have learned
> the language you're using *really* well by sheer amount
> of practice gained.)

It's done.

> > The parser can also manage the plural form
> >
> > ->examine drawers
> >
> > will produce the descriptions of all the six drawers.
> > This can also be done in conjunction with adjectives
> >
> > ->examine left drawers
> >
> > will produce the descriptions of all the three drawers that are situated
in
> > the left row.
>
> Nice. The standard Inform library needs an extra grammar
> line added to do that.
>
> How does your parser handle special cases of object positioning,
> such as removing objects from a box (preferring to match only
> items that are in the box), dropping (preferring to match only
> things the player is holding), et cetera? There are a lot of
> different cases of this, but in general you have an action that
> makes the most sense for objects for which some condition is
> true, the object's location being the most frequent condition.
> You do have an object tree for determining where an object is,
> right? Besides object location, sometimes other state is
> interesting. If the player types "open the door", you want
> to prefer the closed door over the open one, all else being
> equal... of course, if the player types "open the red door"
> then you only consider doors that are red; I think from what
> you've said that you already have that part handled.

Objects that are "out of scope" are automatically excluded. If there are
several objects called "door" only the ones that are at the same location as
the player will be considered. Also "invisible" objects will not be taken
into account. This is basically how far I've got with the "out of scope"
thing. Currently the parser is not able to make "out of scope" decisions
based on logical context. It will not presume that "open the door" refers to
the closed door and not the open one. It's nonetheless a good suggestion.
I'll try to incorporate it.

> > This is how far I've got. I know there is a *lot* of work to be done
before
> > I have something even resembling a good parser. If you have any comments
I
> > would be glad to hear them.
>
> If you eventually want to do something that is hard for some
> existing parsers, including the Inform parser, allow multiple
> objects two places on the same grammar line -- such as a
> compound direct object *and* a compound indirect object.

Do you mean something like this?
->examine note and hundred dollar bill with magnifying glas and ultra violet
lamp
At this stage the parser can only handle one indirect object. This could be
amendet, of course, but it will not be easy.

> Inform can only do this with a complicated routine token
> that has to do a lot of the parsing of the line by hand; I've
> never seen it done. However, you should probably hold off
> on that sort of thing until you have the stuff that existing
> parsers *can* do, first. But you might keep it in mind and
> build your design in a way that makes it possible to add
> stuff like that later.

Here's how the parser looks "under the hood".
First a function called the "preparser" is called with the user input as
parameter. It divides the input into sentences.
->examine drawers then examine brass key
will be divided into
->examine drawers
->examine brass key
Then it checks every sentence for plurals and exchanges them with their
singular counterparts. The first sentence will look something like this.
->examine upper left drawer, upper right drawer (and so on)
The processed sentences are then sent to the "parser" function which tries
to identify the elements (dissolving ambiguities with the help of commas,
adjectives and the like). If identification is succesful (no ambiguities are
left) the parser function produces four integer matrices containing the
id-numbers of the commands, objects, directions and prepositions. These
matrices are then used by the "execute" function. The "execute" function is
based on two nested for-loops. The first one is the command loop, the second
one is the object loop. This way every command is treated as a function
using an object as parameter.

> Another thing existing parsers don't do terribly well is
> handle other conjunctions, like "but". Something to work
> toward in the long term.

Do you mean something like this?

You're standing outside Piccadilly Circus. There must be thousands of people
here.
->drop all but hat
Done.
->examine people
There must be thousands of people here.
You notice the pedestrians are giving you some really strange looks.
->north
While you try to enter Hyde Park Corner you are approached by a policeman
who wonders why you are walking around in nothing but a hat.

Joking aside I think the "but" conjunction is a practical and powerful
thing. The question is how does one avoid misunderstandings like the above
one?

I've had some problems finding internet resources concerning parser
development for text adventure games. Could you recommend some?

Jonadab the Unsightly One

unread,
Sep 16, 2000, 3:00:00 AM9/16/00
to
"John E" <john...@NOSPAMearthlink.net> wrote:

> I think the real problem comes from trying to tame
> new players need to say
>
> "go towards those trees"
>
> instead of
>
> "n"

I have a family member who absolutely cannot resist
the urge to "walk to" things that are already present.

SOME ROOM

You are standing in a room. On one wall a window
looks out on a beautiful view of a large walled
flower garden.

A young boy sits at a desk calculating some differentials.

> Walk to window

[Some error message.]

> Walk to boy

[Some error message.]

> Walk over to the young boy

[Some error message.]

> Go to the desk

[Some error message.]

> Walk over to the window

[Repeat a few more iterations.]

> quit


In all my games I have to put in a "walk to" verb
that simply says "You're there" or the equivalent
for anything in the room.

This is different from approaching distant
scenery. Distant scenery, of course, should
be approachable (unless there's some barrier).
If the player wants to go toward the trees,
why not let 'em?

11dig...@my-deja.com

unread,
Sep 21, 2000, 3:00:00 AM9/21/00
to
In article <39c2148f...@news.bright.net>,
..................

Simple. Put in something saying, "If you want to go somewhere, type in a
compass direction. You can also use UP or DOWN if there are exits in
those directions."


Sent via Deja.com http://www.deja.com/
Before you buy.

lysseus

unread,
Sep 22, 2000, 3:00:00 AM9/22/00
to
<11dig...@my-deja.com> wrote in message
news:8qcq3i$cce$1...@nnrp1.deja.com...

An interesting situation. I don't think this is something an author should
address literally. In other words, <<walk to foo>> or <<go to foo>> when
the foo is in the same room as the actor should do what? Should elicit some
response, obviously. But that response doesn't necessarily need to be an
acknowledgement of physically moving toward the object. <<walk to foo>>
could produce an examination response at a closer level of detail.

>walk to foo
As you draw closer to the foo you notice...

Likewise, with NPCs this kind of command can be used to illicit a response
caused by entering the NPC's personal space.

>walk to Sheila
Sheila turns to you in annoyance, "Can't you see that I'm busy?"

Don't think in terms of simulated action, but instead examine the action
from the angle of dramatic content. In a story you would hardly expect
<<walk to the window>> without "and ..." being a reaction, not an
acknowledgment of a completed task. The last thing you want to see is <<walk
to the window>> "Done.".

What we need here is emotional content.

--Kevin

Jonadab the Unsightly One

unread,
Sep 24, 2000, 8:01:22 PM9/24/00
to
"lysseus" <lys...@email.msn.com> wrote:

> > > In all my games I have to put in a "walk to" verb
> > > that simply says "You're there" or the equivalent
> > > for anything in the room.
>

> An interesting situation.

Indeed. It never would have occurred to me.

> I don't think this is something an author should
> address literally. In other words, <<walk to foo>> or <<go to foo>> when
> the foo is in the same room as the actor should do what? Should elicit some
> response, obviously. But that response doesn't necessarily need to be an
> acknowledgement of physically moving toward the object. <<walk to foo>>
> could produce an examination response at a closer level of detail.

It could, but I didn't want to make it a part of the game, as
such, mainly because most sane players don't think of walking
"to" something that's already described as at hand. I think
for the moment I'll stick with the "It's already here" message.
That's a far more sensible error message than what he was
getting by default ("you can't see any such thing" IIRC) but
avoids the need to do special case code for "walking up to"
each and every object in the entire game; my games have ENOUGH
special case code without THAT.

Jonadab the Unsightly One

unread,
Sep 24, 2000, 8:01:23 PM9/24/00
to
"Pontus Wickholm" <pontus_...@hotmail.com> wrote:

> The parser treats "and" as synonymous with a comma.

Seems reasonable.

> ->examine and plant plant in pot
> The rule is that the word to the right of the comma (or the "and") is of the
> same type as the word immediately to the left,

Also seems reasonable.

> ->examine bathroom,door
> The line above will produce the descriptions of "bathroom" and "door"
> whereas
> ->examine bathroom door
> will produce the description of "bathroom door"

Nifty.

> >If you have both a comma
> > *and* "and", then you want to check to see if it's
> > already in a comma-separated list; if so then you
> > parse it the same as just "and"; if not, then you
> > want to treat the remainder as a new clause.
>
> Do you mean something like the following?
> ->open,examine upper left drawer and close it
> In this case the parser will treat the "and" as synonymous with "then" thus
> "close it" will be treated as a new sentence (is that what you meant by "new
> clause"?).

Effectively, that is what I meant, yes, essentially, except
that I was talking of cases where comma and and come together...

Take the table, the lamp, and the book.

vs

Examine the ocean, and wave.

vs

Examine the ocean and wave.

The first is clearly just a series of three objects.
The second is probably a compound sentence, "wave"
being a verb. The third is probably a compound
object again, "wave" being a noun. All else being
equal. This assumes that "wave" is defined as both
a verb and a noun; if the game only knows the word
"wave" as a verb then you might interpret the third
sentence as compound, for example.

> The parser does so not because there is an and but because there
> is a noun preceeding the "close" verb.

What about verbs that optionally take two objects?

Throw the troll the axe.
Throw the troll and the axe.
Throw the ball and the axe.
Throw the axe.
Throw the axe to the troll.
Throw the axe at the troll.
Throw the axe and kill the troll.
Throw the axe to kill the troll.
Throw the axe, then ask the troll about the bridge.

> > > ->open,examine,close box


> > Hmmm... that's not very much like standard English
> > (although with "and" it gets a lot closer).
>
> I agree it looks somewhat strange but it's a necessary feature in order to
> make the macros work.

If the player substitutes "and" for the comma, it makes
better sense. I'd say, advertise this with "and" in your
examples instead of the comma, at least at first. Later
you can then say that comma is a handy shortcut for and,
and people will think "ooh, cool, shortcut" rather than
"ugh, gross syntax".

> This is not something the player *has got* to know in order to solve the
> game. It's more like a special feature for "advanced users" who, by the way,
> are presumed to have carefully read the "ReadMe!" file.

Come to think of it, if you advertise this (with "and" rather
than the comma, at least mainly) in the "how to play" tips,
it might be a feature other parsers will scramble to add, perhaps.

> > At some point you're going to have to decide how to
> > handle prepositions.
>
> The parser currently recognizes five pepositions; on, in (inside), by (next
> to), under (underneath), behind. They are treated as "aspects" of objects,
> "on" being the "default aspect".
> ->examine desk
> will produce the following description
> "It's an imposing desk made out of oak. There is a lamp and a notepad on the
> desk."
> while
> ->examine underneath desk
> will produce
> "There is a note lying under the desk."
> The sentence
> ->examine desk, inside desk, by desk, underneath desk, behind desk (I've
> thought of allowing the use of multiple prepositions "examine
> on,under,behind desk" but it's too complicated at this stage.)
> is equivalent to
> ->search desk

At least three people will *hate* this, but those
same people don't care for the "search" verb in other
systems, either.

But some verbs in English tend to get seemingly random
pronouns associated with them...

Put down the box.
Put the toys away.
Look over the manuscript.
Dance with the moonlight.
Listen to the fingernails on the chalkboard.
Think about the grue.

There are also less-seemingly-random pronouns,
particularly when verbs have two objects...

Steal the candy from the baby.
Let the cat out of the bag.
Set the blaster to "medium well".
Truncate the number to seven decimal places.
Spread the mint icing around the chocolate cake.
Distribute the Icy Hot throughout the underwear drawer.

> > When you're ready for the next step, make it distinguish
> > the phone, the phone book, the phone booth, and the novel
> > (which can also be called simply "book" if the phone book
> > isn't present).
>

> It's done.

Wow. It's really starting to arrive, then.

> Objects that are "out of scope" are automatically excluded. If there are
> several objects called "door" only the ones that are at the same location as
> the player will be considered. Also "invisible" objects will not be taken
> into account. This is basically how far I've got with the "out of scope"
> thing. Currently the parser is not able to make "out of scope" decisions
> based on logical context. It will not presume that "open the door" refers to
> the closed door and not the open one. It's nonetheless a good suggestion.
> I'll try to incorporate it.

There are, as I said, a number of cases of this. You could
special-case-code all of them, or you could provide a
more general way for the various verbs to prefer one kind
of object over another based on the state of the object,
which is the approach Inform takes. Then again, Inform
has a nice object structure to work with, and its grammar
line structure is a bit different from your part-of-speech
approach, so you might not be able to do this in exactly
the same way Inform does it (although you should be able
to get the same effect as far as the user is concerned,
I think, with a little work). Some other examples
of this kind of situation include removing items from
a container (preferring items that are in the container),
talking (preferring animate objects), dropping items
(preferring held ones), donning and doffing (preferring
clothing, and especially preferring clothing that is
not already worn (for don) or is not (for doff)),
taking (prefering things not already held), ...
if you finish with these, I'm sure there are more.
Also, if this parser is to be one that other games
may reuse, a game author may want to add cases like
this; an Inform game I'm writing adds a complex
system of fire; "light [something]" prefers first
held unlit matches and candles, then unlit matches
and candles, then held unlit flammables, then unlit
flammables, then if none of those are available to
match what the user typed, any old thing (in scope,
of course) that matches what the user typed. Or
something like that. (I'm not looking at my actual
grammar lines at the moment.) If you release your
parser to the general public, some perverse twisted
soul may want to make it do something complicated
like that, so it would be nice if the programmer
could supply a routine for weighting the objects
somehow for each verb.

> > If you eventually want to do something that is hard for some
> > existing parsers, including the Inform parser, allow multiple
> > objects two places on the same grammar line -- such as a
> > compound direct object *and* a compound indirect object.
>
> Do you mean something like this?
> ->examine note and hundred dollar bill with magnifying glas and ultra violet
> lamp

Yep. That's what I mean. AFAIK none of the existing parsers
provide for this. (You can *do* it in Inform, but you have
to write the parsing code by hand, as the existing parser
code doesn't support it.)

> At this stage the parser can only handle one indirect object. This could be
> amendet, of course, but it will not be easy.

The Inform parser can handle a compound indirect object, but
ONLY if the direct object is a singleton. For example, it
can handle this:

Open the door with all the keys.

(The default grammer does not allow this, but if a game author
wants to make this possible it only takes one grammar line.)

However, it cannot handle the example you give with
the magnifying glass and the ultraviolet lamp, because
the direct object is multiple, and it doesn't know how
to handle more than one multi token in the same sentence.
(Perhaps in Inform 7...)

> Here's how the parser looks "under the hood".
> First a function called the "preparser" is called with the user input as
> parameter. It divides the input into sentences.
> ->examine drawers then examine brass key
> will be divided into
> ->examine drawers
> ->examine brass key

What happens to this:
examine the drawers then the brass key

> Then it checks every sentence for plurals and exchanges them with their
> singular counterparts. The first sentence will look something like this.
> ->examine upper left drawer, upper right drawer (and so on)

Okay, so what you call the preprocessor *is* doing some
noun recognition, then?

> The processed sentences are then sent to the "parser" function which tries
> to identify the elements (dissolving ambiguities with the help of commas,
> adjectives and the like). If identification is succesful (no ambiguities are
> left) the parser function produces four integer matrices containing the
> id-numbers of the commands, objects, directions and prepositions. These
> matrices are then used by the "execute" function. The "execute" function is
> based on two nested for-loops. The first one is the command loop, the second
> one is the object loop. This way every command is treated as a function
> using an object as parameter.

Interesting.

> > Another thing existing parsers don't do terribly well is
> > handle other conjunctions, like "but". Something to work
> > toward in the long term.
>
> Do you mean something like this?
>
> You're standing outside Piccadilly Circus. There must be thousands of people
> here.
> ->drop all but hat
> Done.

Hmmm... no, Inform does that. I guess I'm not sure what
I meant. Maybe that "but" as a conjuction separating
clauses doesn't tend to occur? I'll have to give some
more thought to this.

> Joking aside I think the "but" conjunction is a practical and powerful
> thing. The question is how does one avoid misunderstandings like the above
> one?

"drop" generally prefers objects that aren't worn, when
it has the choice. (Not sure if it does implicit doff,
but maybe it should if only worn objects match the input...)

> I've had some problems finding internet resources concerning parser
> development for text adventure games. Could you recommend some?

Best I can say is, look at some of the existing parsers. The
trouble is, each one is written in a different language...
except, wasn't the TADS2 parser written in C or C++? I'm
thinking maybe it was. But usually the parser is written
in the language... the Inform library parser is written
in Inform, for example.

OTOH, you could at least look at what the existing parsers
can *do* by playing around with existing games. Figuring
out how to make your parser do those things... well, you
*could* try to mimick the way existing parsers do them,
but fundamental world-model and parser-structure differences
(and even language/VM issues) may get in the way sometimes.
Sometimes the Inform parser works the way it does because
of features of the z-machine (especially the dictionary
data structure). You probably don't want to copy that
since you're not aiming for the z-machine. OTOH, you might
want to find different ways to get the same functionality.

OBTW, have we talked about "oopse" yet? What about
save and restore and undo? These features need the
parser's cooperation, but they involve more than
just the parser...

Reply all
Reply to author
Forward
0 new messages