[MUD-Dev] common server design

[Martin Keegan]

On Tue, 1 Jul 1997 clawrenc at cup.hp.com wrote:

Ok ... one month later, I finally have a chance to reply to some of this
stuff ...

> In <33bc2b5e.28988475 at relay.mnsinc.com>, on 06/26/97 
>    at 08:59 AM, caliban at darklock.com (Caliban Tiresias Darklock) said:
> 
> >On Wed, 25 Jun 1997 19:25:38 PST8PDT,
> >cg at ami-cg.GraySage.Edmonton.AB.CA (Chris Gray) wrote:
> 
> >>Here is one from me: (using pseudo-BNF type stuff)
> >>
> >>    Don't use		page <who> '=' '"' message
> >>    Instead, use	page <who> <message>
> >>	where <message> is the rest of the input line
> 
> >I made this exact same observation earlier in the discussion, along
> >with the associated mention that this precludes the use of spaces in
> >names. No response was ever made on the matter.
> 
> One approach is to make command parsing a question of simple and
> uniform expression evaluation.  Make the rules simple and easy to
> learn, and the rest should be almost automatic.  

Another approach is to model it as closely as possible on natural English,
to the extent that typing in

prompt> how do i fight

should bring up the appropriate help section.
 
> The simplist approach is defining that an ID string is a single
> continuous string of non-white space characters, or a string of any
> characters enclosed by quotes.  Its ugly, but it works.  

shoving quotes and equals signs into the syntax are anathema to me.
 
> More workable, but tougher to implement is automatic attempted parsing
> of names as the command is parsed.  There are obvious ambiguity traps,
> but it can be done.  The rule then becomes: an ID string is defined as
> the shortest possible sequence of tokens in a given command which can
> be used to uniquely identify a an indentity given the command's
> context.  A lot more runtime work, you'll need ambiguity trapping, but
> it also works and works predictably. 

so long as you don't have too many addressable players and monsters in the
game, the pruning and disambiguation is not all that hard. It's worth it
though.
 
> >>This isn't super user friendly, but after a bit of practice isn't bad -
> 
> >It's the user friendliness that I think we need to QUIT IGNORING.
> >We've done it far too long. 
> 
> User friendly for A != user friendly for B.

Hear hear.

Mk