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

[Jon A. Lambert]

> From: clawrenc at cup.hp.com
>    at 11:03 PM, "Jon A. Lambert" <jlsysinc at ix.netcom.com> said:
>
> >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.
> 
> Mind detailing exactly what you like and dislike about their changes
> to the definition of context?  (Been a while since I looked)
>

This is in the ColdX core.  There is a dictionary called "context" attached to
the $user object.  The command_parse searches this dictionary for best(?) 
matches when one uses a verb that could be used with multiple objects.
For instance,  the "look" command's context might not be resolved to the 
current location as one might reasonably expect assuming a missing direct
object.  It can be finally resolved as "look Bubba" by picking up an object
who's methods insert entries into the user's context dictionary.    

An interesting side effect for sure.  We had discussed earlier the prospect
of players perverting other players namespaces.  This brings up the problem/
feature of objects and locations perverting a users default context search in
their command interface.

I don't particularly care for this.  But it is interesting nonetheless.
  
> Absolutely.  However those are not quite the forms of state flags we
> have been discussing.  I've no problem in using flags to distinguish
> among cleanly iterated functional sets, but using them to define
> arbitrary states from an analog spectrum is silly.
> 
OK, more on that combat stuff and why I use a state flag and not
a combat object.

I don't consider combat to be an analog state, so I do use a flag to
represent this condition.  While in this "state" the behavior of the user
interface changes, the rate of energy expended by a character changes
and behavior of certain skill sets change also.  I guess where I differ 
from current implementations is the player can voluntarily enter and exit
this state at any time.  If attacked a player is never forced into automatic
retaliation.  Any of the potential participants in a melee may chose to
exit the combat state at any time.  This need not involve "fleeing" in the
traditional sense.  Many times it is apparent that an opponent is crippled
or otherwise ineffective, and its often not in the best interests to press
such an attack.  Most of my action "socials" actually perform the attended
action with the expected result, thus slap, thwock, punch can and will do 
damage to their victim.  Assuming no retaliation by your victim you can
certainly at least render them unconscious without ever entering the combat
state.  
       Entering the state has its advantages and disadvantages.  Primarily your 
full skill potentials are used and combat is partially automated (insert combat 
scripts here - something yet to be developed)  Most, if not all, normal actions are
available to you, although the difficult rating increases depending on the
skill being exercised.  Some awareness skills are enhanced and some are
severely crippled.  Some skills cannot be utilized unless actively engaged
in combat (ala parry).  Expenditure of exhaustion points increases to due
adrenaline rush and intense concentration.  It is certainly a possibility for
two heavily armored and otherwise evenly matched warriors to collapse
from exhaustion before resolving the battle to a successful conclusion 
especially on a very hot day.
      Of course it might be nice to have some sort of combat state threshold
configuration to allow a character the ability for auto-retaliation.  And of
course when to exit (ala wimpy).  

> >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.  
> 
> I see more of the horrors as sourced in contributants to the library
> being unfamiliar with the library as a whole, or its basic design
> approach.
> 
This is probably the source of much of what I have seen, since most of 
the mudlibs in release have been team efforts over a long time frame.

A key OO concept is blurred here.  The distinction between class
and object instance.   In Cold this has led to the $frob and what I
would call the prototype object or more properly the class descriptor
object.   For example there exists a $connection object which contains
all the methods and attributes necessary for handling a socket 
connection.  When a new connection is made a new object is created
that inherits $connection instead of an instance of $connection.
Instancing is can only be done through inheritance.  The inheritance 
tree depth can easily double and since methods can be protected, private 
or public the "instanced" object is not neccessarily like the object that
spawned it (and attribute variables also since the last release)
It is difficult to determine the order of calls in multiple inheritance
for like named methods.  trace() reveals it when they exist, however
it's currently only documented by looking at the server internals.
(for variables, it is different and I haven't checked it out yet)

Now all of this is not necessarily a bad thing, but it does require a
significantly different approach to implementing an OO design than
other OOP languages.  


JL