[MUD-Dev] Re: (fwd) Re: command parsers: a modest proposal (with apologies to J. Swift)

[Adam Wiggins]

On Wed, 8 Jul 1998, Richard Bartle wrote:
> Chris Gray <cg at ami-cg.GraySage.Edmonton.AB.CA> wrote:
>  >I don't actually build lists of matching nouns and then restrict based on
>  >adjectives - I do my searching with the adjectives in effect. Consequence:
>  >I don't currently support notions like "all but".
>
>         This is a good technique for databases in general, as it can mean the
> entire database doesn't get searched twice. In a MUD where locality gives a
> reasonably small data structure, though, it's not a problem.

Are you aruging that there is a gain somewhere by using this method, or
just that the actual implementation is irrelevant since it's the same to
the player and doesn't signifigantly affect performance either way?

>  >In "drop rock", it seems MUD2 would drop all rocks.
>         That's right, it would.

Egads!  How does one manipulate a single item?

Examples:

% i
You are carrying a bow and ten arrows.
% nock arrow
You attempt to nock ten arrows at once, but end up just dropping them all
over the place.

Or to extend your example: frequently I find myself in a maze made of
wrap-around rooms (how area builders love those).  Usually I bring along a
large pile of inexpensive (hopefully free) items which I can drop to
indicate to myself which rooms I've been in.  Sometimes, if the maze is
confusing enough, I drop piles of a certain size (ie, 1 rock in the first
room, 2 in the next..)
If "drop rock" drops all rocks, how do I drop only one, or two?  "drop one
rock"?  This seems somewhat counterintuative.

>  >What are the choices here:
>  >   - drop all of them
>  >   - complain about ambiguity
>  >   - drop some "random" rock
>  >   - allow the user to choose
>
>         Of these, the second and fourth get in the way of the game.

I'd say that this choice is very specific to a given person.  Luckily for
those of us in our exalted positions :), we get to choose.
I agree the 4th is pretty distracting, although it can be phrased subtley
(see my reply to Chris G. on this topic).  The second I find hard to
dismiss so easily: I suppose it depends how important command accuracy is.
That is - is it better for the player to type "get rock" and have them
attempt to pick up 507 rocks, the three rock monsters they are fighting,
and the sign reading "Rock-n-roll, baby!" stuck into the ground next to
them, then have them attempt to cancel the command while it is executing
(if you have such a dely on your commands, like I do), or issue
counter-commands (such as "stop trying to yank signpost out of ground",
"stop trying to pick up this rock monster that is trying to kill me", "put
down 506 of those rocks, I only needed one")?

Honestly it probably hinges quite a bit on the layout of your game world,
what sorts of keywords your objects have (such as whether the sign, above,
would respond to "rock"), how broad your commands are (does "get" work on
sentient beings such as rock monsters?), and so forth.

Personally I find the third option the best, mostly because it's what is
found on most muds I've played.  In some cases it drops the top item, in
some cases the last, but either way you get what you ask for, which is one
rock.  In most cases, if you have a big pile of something that all answers
to the same keyword, they are all the same anyways and you don't care
which one you get (in the case of the arrows, above, for example).

> The real
> choice is between the first and the third. I chose the first because it fell
> naturally from the way I was processing adjectives and so on as operators
> applied to sets of candidate objects. Once players got used to it, switching
> to another version was not an attractive option.
>         If I were to rewrite the parser for a new MUD, though, I think I'd
> take plural forms into account, ie. DROP ROCK drops one, DROP ROCKS drops
> them all. There would have to be some minor messing about for cases like
> DROP EVERYTHING, but nothing intractable.

Commonly this is handled as:

% get rock
You get a rock.
% get ten rocks
You get ten rocks.
% get all rocks
You get twenty rocks.
% drop third rock
You drop the third rock.

In the last case (specific naming of items) there is once again some
disagreement over whether this should be the third from the top or the
third from the bottom.  I have come to prefer the top (despite seeming
counterintuative when I first started mudding) since it makes the most
sense in the case of getting things out of a container such as a chest.
Secondly, it makes it easy to modify commands that didn't do exactly what
you wanted, since it leaves the last operated on object on the top of your
list.  For example:

% get red rock
You get the large red rock.
% get blue rock
You get the large blue rock.
% get green rock
You get the small green rock.
% grumble
You grumble.
% drop rock
You drop the small green rock.
% get large green rock
You get the large green rock.

This becomes more and more useful as more adjectives come in: if you're
sorting through a huge pile of swords, all of which have slightly varying
names like "a long thin blade made of silver" or "a long thin blade made
of silver and etched with runes" or "a thin, single-edge blade" and you
accidentaly grab the wrong one, you can always assume that "drop blade" or
"drop sword" will rectify your mistake, instead of re-typing all the
adjectives or recalling them from a command history (which is not always
availible, anyways).
Finally it makes this situation work well:

% look
You are in a room containing yourself, Bubba the Troll, and a hundreds of
swords.
%
Bubba drops his sword.
% get sword
You get the sword.

In this case, you (the player) may know that Bubba has a sword which looks
exactly like many other swords, but happens to be charged with some sort
of magical power, or whatever.  It's reasonble to assume that you can keep
your eyes on the sword long enough to pick it up right away, even if it
does look the same as all the other swords in the room.

>  >it had never occurred to me that "drop rock" would drop more than one rock,
>  >and I would have been surprised by that behaviour.
>         Not as surprised as the players who type KILL RAT when there are
> 18 of them in the room...

ACK!  Surely you must have a method or specifying just one?

>  >Either you avoid more abbreviations because they *might* conflict, or you
>  >have to do a lot of searching and checking at runtime, to see what an
>  >abbreviation should refer to.
>
>         No, abbreviations aren't created dynamically, I use them as secondary
> names for specific things. In other words, I add abbreviations manually and
> state what they point at. If I later add something which could have the
> same abbreviation, I may decide to switch the abbreviation to it but more
> often than not I'll stick with the original. Abbreviations which the game
> figured out on its own and associated with objects at the time of use would
> be very dangerous, especially if player names were candidates for such
> abbreviation.

Indeed.  Check out the archives for lots of discussions on this, if you're
interested.  For instance, the system my partner and I built looks like
this:

% g swo
You get the sword.
% dr
You drop the sword.
% kill bubba
You attack Bubba!
Bubba flees north!
% n
You walk north.
Bubba is here.
% kill
You attack Bubba!

Not only does it compile abbreviations on the fly, but it stores objects
that you were recently interacting with in order to keep you from having
to retype them, or from getting foiled by lag, such as:

% look
The room contains you and a sword.
% look at sword
The sword looks like a good weapon.
% get sword
[player lag]
Bubba arrives from the north.
Bubba drops a stick of dynamite shaped like a sword.
Bubba leaves north.
[player un-lags]
You get the stick of dynamite shaped like a sword.
BOOM!  You're dead.

Some folks on the list prefer the pronoun notation:

% look at sword
The sword looks like a good weapon.
% get it
You get the sword.


Adam