[MUD-Dev] Re: (fwd) Re: command parsers: a modest proposal (with apologies to J. Swift)
Chris Gray
cg at ami-cg.GraySage.Edmonton.AB.CA
Tue Jul 7 19:59:15 CEST 1998
[Richard Bartle writes, via Chris Lawrence:]
[Lots of good stuff on parsing.]
I found myself nodding through most of Dr. Bartle's description. What
he describes has lots of similarities to what I do, and some interesting
differences, too. I don't actually build lists of matching nouns and
then restrict based on adjectives - I do my searching with the
adjectives in effect. Consequence: I don't currently support notions
like "all but". Another is the choice of what to do when you end
up with multiple matches. In "drop rock", it seems MUD2 would drop
all rocks. In my system you'd get a complaint about ambiguity. What
are the choices here:
- drop all of them
- complain about ambiguity
- drop some "random" rock
- allow the user to choose
Is any choice bad? I suspect most preferences by players would come from
familiarity - what they are used to happening. I'll admit that it had
never occurred to me that "drop rock" would drop more than one rock,
and I would have been surprised by that behaviour. Actually, I think
I don't like that particular choice.
Dr. Bartle speaks of "compiling", which suggests that his entire system
is a single compiled binary. Are there in fact possibilities of adding
to the vocabulary at run time? If so, then abbreviations for things
becomes a lot tricker. Either you avoid more abbreviations because they
*might* conflict, or you have to do a lot of searching and checking at
runtime, to see what an abbreviation should refer to. I find the latter
distasteful for a couple of reasons. One, it puts quite a bit of load
on the server for little gain; and two, you have the potential for
doing something dangerous that the user hasn't requested, just as
Dr. Bartle mentions.
--
Chris Gray cg at ami-cg.GraySage.Edmonton.AB.CA
More information about the mud-dev-archive
mailing list