Resets and repops

[Jon A. Lambert]

[Chris Lawrence said:]
> I don't distinguish between any sort of objects, be they rooms, mobiles,
> dumb objects, or players.  They're all the same, all do the same things,
> and outside  of the IO going to a connection object for players, all run
> exactly the same  code.

I do distinguish living objects as as separate and distinct class from
non-living objects.  The class heirachy does not have a common root
object.  As such there is some redundancy in code but not as much
as you would suspect.  Plant-life happens to fall in the non-living
class for many reasons.  My class heirachy is probably much flatter 
because of some of these distinctions.

> 
> What I don't do is bind player characters or non-player objects to using
> the parsed command line.  Any object may directly call any method, with
> any set of arguments, on any other object.  Of course it is then up to
the
> receiving object's  security criteria as to how and if it accepts the
call
> (stolen straight from COOL).  As such the automation code for mobiles
> (that's all a mobile is: a normal object with an event chain that causes
> state changes in the mobile) can directly call the relevant methods to
> affect the subject mobile, or it can lodge command strings to be parsed
> into a direct method call (which in truth is just another method call
with
> the command as an argument).
> 

This certainly is an approach which leaves you with the greatest degree of 
flexibility.   My server is more tightly bound to objects found in rpg's
and
would be of little use in progamming other sorts of simulations.  I have
sacrificed this genericity (is that a word?) to the particular games i wish
to simulate.

> Part of the neat aspect of this is that I expect players to augment
> themselves and their character objects with home-grown, purchased,
stolen,
> or otherwise acquired code to implement various neat features.  Earlier
> discussion focussed on the Combat Packages aspect of this (more or less
> intelligent user-written combat AI libraries), but I can also see it
> happening with socials, naming cards (objects which
> auto-register/de-register names on teh recipient), mana factories/sinks,
> etc.
> 
> BYOC takes a whole new meaning.

This brings up other thoughts which we had briefly touched upon in
earlier Email and maybe others would care to comment.   

It is my opinion that many of the players/builders that I wish to attract
are 
decidely non-programming types.  A language like LPC or ColdC is 
significantly beyond their patience/threshold to bother to learn.  I am 
attempting to make the user-programmed language as close to the actual 
command parser as possible.  Such a language would inherently reflect the 
commands implemented in the mud and would probably be much closer to a 
tiny version Tcl/Tk.  I prefer a minimalist approach here.   

1) Locally implicit variable declaration and assignment (strictly
variant-types like REXX)
2) An IF THEN structure (ELSE optional)
3) A simple conditional looping construct (WHILE (cond) END-WHILE comes to
mind)
    or DO with CONTINUE and EXIT/BREAK.
4) Perhaps a GOTO/LABEL mechanism (who says mud players need to
    be structured programmers )
5) A minimal operation/function library.  (+,-,*,/) Some essential string
functions.
6) Access to object attributes in context only.  Those attributes that
would
    normally be exposed in game context.
7) The executable meat and potato functions are exposed in in the
    same grammar as mud game commands. ( thus the game construct
   'drink water from canteen' is present exactly in the same manner in the
   language construct)
8) Input to such a program could be driven by standard mud output. 
   (response to above command would be indicated by read access to a
condition
   code structure or the actual output buffer text)

> cf the original Gods system.  You can find a passable description in
> Bartle's original MUD survey.

Really!  I wasn't aware of this, although I suspected this terminology had 
some similar roots in early muddom.  Someone had posted a large mud
specification that included this concept about one year ago on r.g.m.a
I cannot remember their name although I do remember they were 
associated with Case Western.  This is where my concept of this 
originates.   Couple this with my devotion to Homer and Hesiod it is
a natural interest for me.  My chief builder happens to be very fond of
Norse mythology and we have been having lively discussions of how
to integrate control of these differing pantheons of dieties.  If  Dawn is
held back one hour in Ithaca by Athena's plea, does Dawn occur at the
appointed hour in Beowulf's lands.  I think we settled for local control.
Basing this on physics would be a strain on suspension of disbelief. ;-)