Just a bit of musing

[Adam Wiggins]

> Actually I tend to agree with this quite strongly. Even though I've got
> lots of exceptions in my system. I've played "guess the verb" way too
> many times! However, that said, I think you do want to allow some
> exceptions, else you end up with the different kind of "guess the verb",
> where the player knows that verb "balance" is used to find out their
> balance at a bank, but now they have to figure out what the verb is to
> try to get the see-saw to stay entirely off the ground. If you put
> everything into one complex verb, you end up with *no* modularity in
> your system, and changing anything has ramifications everywhere. Its also
> a lot more painful to change a complex verb on the fly than it is to add
> another simple verb.
> So, I vote for a balanced situation - have a good set of verbs in the
> main grammar, but allow special case verbs and grammars as needed.

Well, this falls into the same category as having two items named "a steel
longsword" but one does 2d5 and uses the 'long blades' skill and the other
which does 3d6 and uses the 'swords' skill.  It's a matter of consistency.
So you can avoid this with good building - ie make people always use
"push" to push buttons, pull to pull cords, break to break tripwires or
doors or whatever.  I'm a proponent of writing the system so that this
is, at the least, very easy, and at the best, impossible to use non-standard
verbs.  Sure, there is overlap...and you can decide things based on context.
Ie, we have a verb, "draw", which is mostly used for drawing weapons
from their sheathes, but also can be used to draw a card from a stack of
playing cards.  Since we keep track of what the user is "doing" and what
objects they have recently interacted with, it's pretty easy to determine
that when they type "draw" and their last targeted object was type "cards",
they're probably more interested in drawing a card from the stack on the
table in front of them instead of whiping out their sword.  (Naturally
they can override this with "draw sword".)  Of course, the trick is to
do all your commands consistently this way; one thing you can end up
with (particularly if multiple people are coding different commands) are
"smart" commands and "not-so-smart" commands; when does it determine what,
etc.  But the important thing here, to me, is that you never type "draw"
and see, "Huh?" or "Invalid command."  Users can get help on the draw command
and it will specify exactly how it works.  I suppose this is a bit
odd with really ultra-specific verbs like "prime" for priming grenades...
but it seems to me that if you have grenades in your game, probably you
have other types of explosives as well and "prime" becomes a pretty important
verb.  The main thing I dislike is the quest-y verbs.  Dikus are pretty
horrible about this; in one room you type "hack bush" to chop through
the foliage, and in another you type "cut path".  In some you type "disarm
tripwire" and others you type "break tripwire", because the first was
a trap of type tripwire which uses the disarm skill, the second is a
room-routine specifically for that, which doesn't show up anywhere else
in the mud and doesn't use any particular skill.  This is bad because
it's "outside" the system; in the same category is having to type "scale
wall" to get up a certain room.  Wait, what if I'm flying?  What if
I have a reverse-gravity spell on me?  What if I have a ladder?  Etc...
which is why I disdain this sort of specialty coding.  I don't see any
reason that all verbs shouldn't be a part of the base system; in this
way you're always sure that they'll use the right skill and whatever else.

I guess it's the difference between making a wall and letting users get
over it in whatever way they can manage (whether it be flying, climbing,
becoming non-corporeal and walking through, or even smashing it down) and
doing a script like:

if token++.Is("climb") and token.Is("wall")
  room_message("$n scale$s the wall.", ch);
  move_char(ch, UP)