[MUD-Dev] common server design
martin at cam.sri.com
Sun Aug 3 19:17:18 New Zealand Standard Time 1997
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
> 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
> >>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.
More information about the MUD-Dev