[MUD-Dev] Re: (fwd) Re: command parsers: a modest proposal (with apologies to J. Swift)

[Chris Gray]

[Richard Bartle:]

 > >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.

OK. To clarify, however, I should say that what I meant for the fourth
choice is that the user could set the policy for themselves, choosing
once among the other alternatives. I do have some sort-of question-and-
answer stuff in my game, but I wouldn't want it used a lot - its just
too confusing to users and scenario writers.

 >        Not as surprised as the players who type KILL RAT when there are
 >18 of them in the room...

Hmm. I could get used to that! (My current scenario happens to have
a room that comes equipped with a lot of rats, which aren't really
dangerous. Typing only one command to attack all of them would be handy!)

 > >Dr. Bartle speaks of "compiling", which suggests that his entire system
 > >is a single compiled binary.
 >        Wellll...
 >        It's several compiled binaries. The game itself is written in MUDDLE,
 >which is interpreted by an interpreter written in C. However, the code
 >which is interpreted is an intermediate code, to which the MUDDLE original
 >has to be compiled. If I add new words to the vocabulary, that's where I
 >do it, and that's why it needs to be recompiled. If I change any of the
 >stages up to the parsing stage, I need to change the C code instead.

Sounds similar again. My server is now in C (initially in my own
language called "Draco"), and supports an internal language which the
scenario is written in. The server supplies a bunch of "builtin"
functions to help in parsing, however.

 > >Are there in fact possibilities of adding to the vocabulary at run time?
 >        Yes, there are.

How does that work? Can normal players do it, or is it only available
to administrators?

 > >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.
 >        No, abbreviations aren't created dynamically, I use them as secondary
 >names for specific things. In other words, I add abbreviations manually and
 >state what they point at. If I later add something which could have the
 >same abbreviation, I may decide to switch the abbreviation to it but more
 >often than not I'll stick with the original. Abbreviations which the game
 >figured out on its own and associated with objects at the time of use would
 >be very dangerous, especially if player names were candidates for such
 >abbreviation.

OK, understood and agreed. I've done much the same, but it sounds like
I haven't gone anywhere near as far as you have. It was only recently
that I went and made sure that all NPC's had uniform 3-character
abbreviations. It's all been terribly ad-hoc. Do you have any kind
of human algorithm, etc. that allowed you to decide what abbreviations
to use? Similar for handing misspellings?

Lots of stuff on my system has been in this list before, but I'll mention
one relevant aspect here: I can add/remove any kind of vocabulary at
run-time, simply because the dictionary stuff is all created and
manipulated by "builtin" functions, which any player who has a
"wizard" character can access. However, the main dictionary is owned
by the "SysAdmin" character, so no-one else can directly modify it.
Much of my programming background has been the compilers universe, so
I've approached MUD-building from a programming language bias.