[MUD-Dev] Re: Issues from the digests and Wout's list

[Jon A. Lambert]

> From: clawrenc at cup.hp.com
> 
> Actually I understand current LP's do a mix of a global parser (drink
> is avilable everywhere), and verbs bound to unique objects, but that's
> another matter.

All of my verbs are bound to actor.  Verbs like walk, drink, give, etc
are bound to character.  In your press button example, press is bound
to character while any action the button is designed to accomplish
(ala thwack character with arm) is bound to the button.

Objects have distinct types which may invalid certain actions performed
against them.  This is very similar to the Diku object state flags. 
One advantage to this is maintainability and consistency.  All 'drink'
code is located in one routine along with all state checking.  Very
simple.

Note: I have much to say on the combat matters after I catch up. :-)

> 
> I'm a big fan of having verbs bound directly to their target objects. 
> It works, its simple, its efficient, and it allows useful pre-parsing
> by template ala ColdX.  The disadvantage as you write is the lack of
> global defaults for common verbs like "drink".  
> 
> Happily this can be fixed with a touch of LP's parser layer concepts. 
> Have the same verbs-on-objects that MOO, ColdX, and old LP's use, use
> ColdX's template concept (a grown up version of MOO's), and then given
> such template value weightings.  In my case I assign a weighting to
> templates from 0 - 255.  Matching verbs/templates are searched for in
> the normal manner (player, inventory, room etc), with the first
> matching template which weight is over 128 accepted.  If no matching
> templates are found with weights over 128, then the heaviest template
> (largest weight) closest (least removed ala player/inventory/room) to
> the player is taken instead.

While I love the use of regular expressions in COLD, the enhancements
they have made to context are decidedly irritating.  One's order of verb
processing can easily change by moving about the world and picking
up and dropping items.    I prefer a consistent and fixed context order.
It makes for a more comfortable user interface.

> 
> And thus you get state flags and all the endless horrors and nastiness
> that they bring.  No thanks.
> 
I love flags.  I have never experienced the least amount of queasiness
in using them.  :-)  
They certainly have their place in implementing an object-oriented design.
You can end up with a very deep inheritance tree if every minor difference
between objects causes you to create an abstract super-class with 
descendent classes modeling your minor differences.  The result is object
oriented code that can be as difficult to follow as unstructured code.
The LP and MOO libs I have seen exhibit their own set of horrors along
this line.  While I don't particularly agree with the design goals(?) of the
Mud++ project, the inheritance structure is simple (too simple perhaps?)
enough to allow code to be easily followed and highly maintainable.  

I have been enmeshed in Language design for the the last couple of
weeks.  PCCTS is slicker than one-eyed cephlapods from Paraworld Blue.  
More later.. splub gnog furb Squaz.


JL