[MUD-Dev] Re: (fwd) Re: command parsers: a modest proposa

[Adam Wiggins]

On Wed, 8 Jul 1998 Michael.Willey at abnamro.com wrote:
> >Chris Gray <cg at ami-cg.GraySage.Edmonton.AB.CA> wrote:
> >>[Richard B:]
> >>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.
> >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.
> 
> I would disagree with that - As a player, I'd rather have the game
> abort a command than perform an unwanted command.  I'd rather it
> do nothing than do the wrong thing.  For me the dividing line
> between choosing method 2 or 4, then, would depend on how cleanly
> #4 could be implemented.

We've debated this one pretty hard a few times over the years.  I think JC
was the big proponent for:

% get rock
Which rock would you like?
  1) the big rock
  2) the small rock
  3) the cracked rock
 >> 

Where an entry of anything but 1, 2, or 3, aborts the command, or some
sort of escape character (such as '!', mimicing the UNIX method) sends
your command to the parser one level up the stack.  (You could potentially
be asked for multiple clarifications, which would accumulate into a
stack.)

Personally I despise these things; I want a homogeneous parser, for a
lot of reasons I've detailed before (lag being one of the main ones).  At
best there's the old infocom thing:

% get rock
Which do you mean?
% the cracked one
Okay, you get the cracked rock.

In this case you don't go to any sub-menu, it's just that you get a single
command chance to enter something which normally would do nothing, but in
that case acts as an answer to its question.

Adam