Re: Code/etc: Command interpreter improvements ...

From: Daniel Koepke (dkoepke@CALIFORNIA.COM)
Date: 05/25/98


On Mon, 25 May 1998, Magik wrote:

->Well, just taking the perspective of the players point of view, they would
->never use the long text format since it would take too long to type in
->comparison.

Well, if you know how to use the short format and are comfortable with
it.  Personally, for a lot of people (myself, included), typing a
complete sentence doesn't really take that long, anyway, and if I were
more comfortable with, "Take the big, red, rubber ball from my large
leather sack, and bounce it," rather than "take big-red-rubber-ball
large-leather-sack | bounce", I wouldn't object to typing it all the
way out.  From my experience, a lot of people don't like "get 2.bread
bag", but they don't have any alternatives -- and first time MUDders
almost always want to know "If I have two of the same thing, how do I
get the second one?"  If they could use a complete English sentence
and still get by, then it's all the better.  At least, until they
learn the short notation and become comfortable with it.

->A player should be able to type something like:
->  get leather-shield                       To get the shield on the ground.
->  get ball-blue large-backpack    To get the blue ball from the backpack.
->  wear leather-shield                    To wear the shield (after gotten of
->course).

Hmm, there's not much need for the dashes, really.  If you seperate
adjectives from nouns (e.g., the long, curved, Japanese sword would
have nouns: "sword blade katana tachi", and adjectives: "long curved
Japanese"), and you know that adjectives preceed nouns, you can
eliminate the need for the dashes.

  > get [the] long, curved, Japanese sword [from the] wooden sheath

We would scan forward for the first noun in the command (easily done
by just checking every word to see if it's the noun of any object).
Once we locate a noun, we can go back and look at any adjectives we
ran into in order to narrow the search (we can either stop parsing
adjectives after we have just one object left, or we can continue to
make sure we've got an exact match [e.g., we don't want to get the
machette(sp) when it's been specified we want a Japanese sword] -- or
we can let players control this behavior).  Hence, we have just
successfully figured out that we were talking about the katana, not
about any other sword.  After 'sword' we scan forward for another
noun, and we find "sheath".  We repeat the search for adjectives and
narrow it down again to the wooden sheath, not the leather
sheath/scabbard.

This actually wouldn't be _that_ difficult to code.  You'd need to
seperate nouns and adjectives in your object files, which would be the
biggest part of the job.  The rest is easily handled by tokenizing and
waiting until we run into an object's noun.

The only problem I can see with this simplistic approach is that if
you have a lot of adjectives and/or a lot of possible items you run
into a problem.  Also, the parsing order will be a little weird,

  > get long, curved sword wooden sheath

We parse the arguments _backwards_ for reasons of efficiency.  We go
to the last argument "sheath", which we know is a noun and create a
linked list of all sheathes in the room and player's inventory/eq list
(we haven't got the "wooden"  argument yet, so we haven't narrowed the
search, yet).

After we have that list of sheathes we go backwards and get "wooden".
Here we scan the list of adjectives for all of our sheathes and remove
from the (linked) list any which do not apply.  We go back again to
the word "sword", which isn't an adjective ("sword sheath"? hmm...),
so now we search _in_ all of our wooden sheathes for swords.  We build
this list and continue backwards through the arguments, throwing out
swords which don't have matching adjectives ("long, curved").  We
should have only one object left in the list by the time we finish
with the first argument -- if we don't, the player was ambiguous and
we can deal with this situation in a number of ways:

  o Do like CircleMUD does and just grab the first one you see.
  o Report to the player that the parser couldn't determine what they
    meant and give them tips on how (or even a menu :) to select the
    one they meant

Hmm ... this seems so elegant and simple.  There has to be something
wrong.

The one problem being when nouns are adjectives, like the case of
"sword sheath".  In this instance, we will have to do a bit more work
to resolve the collision.  We will eventually get to the point where
none of the sheathes apply any more (unless all of the adjectives
belong to the sheath, too -- there's still more we can do, though).
At this point, we would remove the disqualifying adjective from the
sheath linked list.  In our case ("get long, curved sword wooden
sheath") this would (probably) be "curved".  Now we see if "curved" is
the noun of anything in our "sword wooden sheath" objects.  If not, we
treat "sword" as the disqualifying word, adding back in sheathes which
didn't have the adjective "sword", and now see if we can build a list
of objects that have the noun "sword" and are in our wooden sheathes.
In this case, we have just resolved the collision and now look for
"long, curved swords" in "wooden sheathes".

If all of the adjectives belong to the sheath (e.g., "get sword
sheath") we can see if there's any "sword sheathes" to get within the
room.  If not, we will assume that player meant something else -- so
we treat "sword" as the disqualifying word and see if we have any
"sheathes" in our inventory or eq list.  Now we do as above, resolving
the collision of "sword".  If we don't have anything left, then we
say, "There is no sword sheath here, or no sword in a sheath."

Like I said, it sounds too easy.

-dak


     +------------------------------------------------------------+
     | Ensure that you have read the CircleMUD Mailing List FAQ:  |
     | http://democracy.queensu.ca/~fletcher/Circle/list-faq.html |
     +------------------------------------------------------------+



This archive was generated by hypermail 2b30 : 12/15/00 PST