mud grammar (was Re: Just a bit of musing)

[claw at null.net]

On 10/03/97 at 08:43 AM, "Carter T Shock" <ctso at umiacs.umd.edu> said: >>
From: coder at ibm.net

>> A good MUD grammar is incredibly context sensitive.  A simple example is
>> the case where the presence or proximity of an object adds verbs to the
>> players.  There is no need for this crap to wander thru the global
>> namespace, or even warp the general grammar.
>> 
>> >As such, one should be able to whip up a command interpreter with
>> >lex/yacc. I've started on it at least a dozen times but never managed to
>> >quite finish. Is this worthwhile? Thoughts?
>> 
>> Nope.  That approach tends to preclude having a dynamic language where
>> users or objects can add, redefine, mutate or delete verbs and nouns
>> freely at runtime.  A Very Bad Idea.
>> 
>
>I think we have a misunderstanding here. There's grammar (the structure
>of a language) and then there's vocabulary (all of the individual words
>that make up the language). I agree that the vocabulary is dynamic. I
>don't think the grammar is.
>
>I'll go one step more and suggest that how you implement the various
>entities (people, critters, and objects) in your mud can influence the
>success of such an approach. 

Note: I don't distinguish in any way between users (people), mobiles,
critters, objects, rooms, etc.  They're all defined and treated in the
same manner, and quite potentially a single object can be any one or all
of them at the same time or change state among them.  (cf earlier
discussion of The Magic Sack").

We're getting into messy territory here.  There are two base arguments:
the "I want to know that PUSH will work on all buttons", and, "I want the
command language's grammar to be logically consistant across the game."

The first I think is valid, but is a social/administrative problem, not a
technological problem.  I don't see MUD servers as despotic grammar
police.  The tack I've taken is to make it fairly easy for someone coding
a button to grab a set of applicable verbs and supporting operation code
for their object.  If they choose to, great.  If they don't, leave it up
to the administration to detect/repair/handle.  

The second is a Good Thing, but I'm not sure if its enforcable/codable
without either binding it into the server, or precluding users from
creating alternate grammars (eg an area which requires all commands in
Klingon with a reversed (subject/object)/(verb/noun) grammar).  While the
alternate grammar bit may be  of dubious value, for the me the requirement
of not binding ANYTHING game specific, such as a grammar, into the server
is absolute.

The tack I've taken is stolen from ColdX, which in turn is lifted fairly
directly from Cold, COOL, and before that MOO (tho its a long way from
Tiny*):

  Everything is an object.
  Objects are defined in a database.
  Objects have Unique IDs.
  Objects may contain methods, attributes and verb templates.
  Objects may inherit from other objects (multiple inheritance).
  Inheritance applies to methods, AND verb templates.
  Inherited methods, and verb templates can be locally over-ridden.
  Objects may define methods and verb templates as unable to be
over-ridden.
  Objects may declare (virtual) methods and verb templates without
defining them.
  Objects inheriting virtual methods and verb templates must define them.

  A verb template is a string which defines a spcific command grammar
which is 
  used to match against commands.  eg A template of "l?ook [at] <this>"
defined 
  on a dog object (note that the template is defined on the target object,
not on 
  the issuer) with defined names "dog", "rusty", and "fido" would match
any of 
  the following:

    l dog             
    l at dog         
    look at dog    
    l rusty
    l fido
    l at fido 
   etc.

  And would result in the method attached to that template being called on
the 
  dog object.

As such a user programming an object with a button would inherit from a
button object to get the requisite verbs and supporting code.  There are
problems with this general approach however:

  You quickly end up with a very large array of base objects intended as 
  components.  (eg button object).  This can present namespace and 
  complexity/learning curve problems (I'm coding a widget, would any of 
  the 800+ component objects already defined really help me here?), as
well
  as the obvious documentation problems

>Lessee... in most mud worlds, the "nouns" are dynamic, but the verbs are
>not. 

Not true for MUDs which support (free) user programming.  

>I put nouns in quotes because often a noun/adjective pairing is
>required to uniquely identify an object (the long sword, the black sword,
>etc.). 

I believe "noun phrase" is the accepted term.

>The verbs in the system are your commands. cast, throw, hit, etc.
>If we want to allow dynamic or generic verbs, now you're getting into
>natural language processing and I definitely don't want to go there. So
>there are some distinct sentence structures that emerge:

><verb> <object>  "hit foo"
><verb> <object> <object> "give gold foo" "cast fireball foo"

I don't have any docs or notes here at work, but you should be able to
find some good references on the basic english-style declaritive grammars
on the Web.

Where <noun> is a noun phrase, which may consist of a series of noun
phrases joined by (implied) conjunctions, and where a noun phrase may
consist of (several) adjective(s) and a noun:

  <verb>
  <verb> <noun>
  <verb> <noun> <adverb>
  <verb> <noun> [<preposition>] <noun>
  <verb> <noun> [<preposition>] <noun> <adverb>
  etc.

>So the first trick is to define your grammar... establish a mapping of
>verbs to appropriate objects. We'll start with "hit". In most codes if
>you "hit foo" the code first sees what the allowable targets are for foo,
>then tries to locate a foo somewhere in the world that satisfies the
>target rules (get_person_room_vis(), get_obj_room_vis() whatever). 

Not for me.  I do a cyclic proximity scan from the issuer, looking for an
object with a template which matches "hit foo".  The basic scanning order
is:  issuer, inventory, removed inventory, items close, items nearby,
items far, and then out thru any levels of containment (room, area, etc).

>An example of where this works very nicely is with magic. Identify the
>verb "cast" as special in your lexical analyzer. Rather than
><verb> <object> <object>
>it becomes
><verb> <spell> <object>

For me:

  Bubba learns a new spell "wugga".

  Bubba's object now inherits from the "wugga" object, adding the
requisite 
  templates and methods.

  Bubba enters, "cast wugga on boffo", or "wugga boffo", and gets the 
  expected result.
  
>Now the question, why bother?
>Well, first off, it can make the mud more user-friendly. Rather than
>simply reporting "huh?" on bad commands, a true parser should be able to:
>
>	1) report the exact location of the error in the command
>	2) offer up suggestions (tab completion of commands)

Hurm

Not arguing, but not clear on what I can't do here.  My system violently
discourages name compleation if only due to its transactional nature
(everything is a transaction which can be rolled back).  Hurm.   I guess
this could fit in by putting a light weight client interface between the
connection object and the socket to allow very light-weight accessor-only
private transactions to get possible target lists.  Hurm.  Could get
*really* ugly fast, but it would work.

The thing I have right now (and am fairly happy with), is the old target
query:

  > get bag
  Do you want the:
    1) Red bag
    2) Tattered paper bag
    3) Mouldy sack
    0) Cancel command
  >> 2
  You take the tattered paper bag.

>Now, we could do all of this without learning lex/yacc, but doing it in
>lex/yacc gives you a standard interface.. not to mention someone else has
>written most of the ugly code for you already. Btw, the newer flavors of
>the GNU lexer/parser software (glex and bison I think) offer up a C++
>version that encapsulates the parser as an object. Nifty side effect is
>that you can have more than one. So, if you really want to screw with the
>user's minds you could conceivably have different command sets in
>different parts of your world. (something along Zelazny's Amber... the
>physics are different in the place you've warped to so the commands,
>spells, etc are different). Wait, it gets better... if we want to link up
>muds, there are ways that one mud could export its parser object to
>another so, if you wanted, you could process commands for a user in the
>remote mud locally (not sure why you'd want to, but hey.... explore the
>possibiliteis :)

cf COOL and its YO protocol.

--
J C Lawrence                              Internet: coder at null.net
----------(*)                              Internet: coder at ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...