[MUD-Dev] Re: Verb binding

[Adam Wiggins]

> This whole idea, seemingly used by many here, of having many variants
> of a verb searched for and triggered, bothers me. The net result is that
> a global failure ends up with a generic error comment from the parser.
> That's not likely to be very informative. E.g. as a user, I would greatly
> prefer to see "There are no apples left on the tree" rather than something
> like "There is no apple to pick here". A custom reply,
> indicating that the system understood what I was trying to do, is very
> reassuring. I'll repeat my first experience on an old LPMud: I knew it
> was a combat MUD, so when a saw a "stick", I picked it up and tried to
> wield it as a weapon. The system simply replied "Huh?" to all of my
> attempts, leading me to wonder how to use a weapon. It never occurred
> to me that the system would fail to understand a commonly used verb
> just because there were no appropriate objects nearby. (It turned out
> that the stick was a dead torch.) I suspect that most new users would
> have exactly the same response.

I agree, which is why I dislike verb-binding.  First of all, I quickly
grew extremely tired of this method from all the dikus I've played.
Ie, you're in a room and you type "push button" and it says something
to the effect of, "You push on thin air and fall over.", which was the
'push' social, since the button had the "press" verb for activation.
Not to mention the number of times I've played guess-the-verb...

> l device
It seems to have a small handle protruding from it.
> pull handle
Huh?
> turn handle
Huh?
> move handle
Huh?
> push handle
You push on thin air and fall over.
[group members laugh at you for a while]
> tug handle
Huh?
> twist handle
You twist the handle to the right..

I don't consider this fun, but in any situation where you've got multiple
builders workin on complex areas, it's just going to happen.  I vastly
prefer a small number of simple verbs which I can quickly learn to use
(ie, if the button doesn't respond to "push", then it's not going to
respond to anything).
One example someone mentioned was the flame-thrower.  Having a 'burn' verb
seems like a cool idea, but what if I don't know it's a flame thrower?
To me it's just a metal devices with some buttons on it.  If I just use
the standard activate command (which could be something vague and general
purpose like 'activate' or 'use', or something more specific like having
to press a button or pull a trigger), I should see gouts of flame fire
from the end of the device.  At that point I'll probably alias 'burn' to
be 'pull trigger on flamethrower'.  If I type 'burn' after I've lost the
flamethrower, I then see something to the effect of "You don't see a
flamethrower here", which makes perfect sense, as oposed to "huh?".
This is simple to program, easy to understand as a user (although perhaps
looses a slight bit of coolness factor for the interface, sinec you have
to manually alias the commands), and forces your builders to build consistantly.
Ie, they actually have to put a trigger on the flamethrower which responds to
'pull', instead of attaching some random verb they pulled out of their ass.

So far the only downside to this implementation that I've seen is confusion
of terms, like 'draw' mapping to both 'draw a card' and 'draw my sword'.
Still, you can easily think of other terms to cover different functions
(we make good use of 'webster -t'), or just code the thing to look at the
target object/situation, which is a small amount of extra work but makes
the interface nicer from the user's point of view since it seems less
stupid.