[MUD-Dev] Embedded languages, object persistance... ack.

[J C Lawrence]

On Wed, 29 Dec 1999 01:03:00 -0800 
Joe Kingry <jkingry at uwaterloo.ca> wrote:

> I want a mud server on which I can change the code online of say a
> skill, a spell or something else. I understand that this is the
> purpose of having an embedded language that runs "on top of" the
> mud's driver. i.e. MUF for MUQ, Python for AR3 etc.  

What you are talking about we commonly call "runtime morphism",
which is just the ability to edit the object heirarchy at runtime,
and to have the effects of those changes appear during the same
runtime (there may be a delay) without an interruption in service.
However the use of an internal scripting language in a MUD is rarely
driven by the need to support runtime morphism More often the
driving factors are things like ease and rapidity of world
development and suitability for non-programmer users/players.
Adding runtime morphism is not necessarily an automatic or trivial
task once you have an internal scripting language. 

  Consider a deep object heirarchy, where a large number of objects
  which are in common use in the game all inherit from a common
  shared object.  What happens if I come along and edit the methods
  and/or attributes on that shared object?  What happens if I
  totally redefine it?  What happens to all the objects that descend
  from it?  What happens to the commands people have or are issuing
  which affect the child objects?  What happens if the changes cause
  mass breakages such that few to no objects actually work any more?

For me some of the driving reasons behind internal languages are
Rapid Application Development (implementing the game world or world
features), suitability for non-professional programmer use, ability
to tailor to world building versus general programming problems,
ease of extending the language in "interesting" directions, and so
forth.

> So in general I know this code is to be compiled since you don't
> want to be executing "scripts", but is this code an object? and
> then is the byte-code stored? ack.. I'm confused.

Not so fast.  The majority of MUD servers out there with internal
scripting languages don't actually have an internal Virtual machine
(VM) to which they byte compile their internal scripting languages
(eg the Tiny-* clan).  Having a VM and building a byte code compiler
can significantly increase performance, but it is also a non-trivial
programming task that many have foundered on.  

More simply: Language design is not easy and is very easy to get
wrong.  This is why many of the new rash of MUD servers are (very
intelligently) avoiding this problem entirely and using the Java VM
and then using Java, JPython, or similar to produce the appropriate
byte codes.  There area certain trade-offs of course.  Your ability
to redefine and tailor the language to your task at hand is gone,
your selection of possible languages to use is heavily limited
(especially for us by non-programmers), etc.

Another distinction which needs to be made here (which most of the
object oriented servers fail to do) is between a class definition
and an object.  A class definition describes and defines how
something would be and would work if it existed.  It _defines_
something, it doesn't actually create one of those things.  An
object is an "instance" of a class.  It is a created example of the
class definition.

Why is this important?  In systems which make a distinction between
classes and objects, you can compile the class definitions and store
the results with with class, and then merely have the various object
instances refer to that definition to access their defining code.
You can also build different systems to handle class definitions
than you use to handle objects, tailoring each system to handle its
data type (class or objects) best and not the other.

However, most current MUD servers do not define the difference
between a class definition and an object instance.  They are one and
the same.  (eg MOO, ColdC, etc).  What this means is that an object
usually also defines its class.  Often programmers for such systems
try and install an artificial distinction by only doing programming
(class definitions) in objects that they never actually use
anywhere, and just inheriting children from those object when they
want to create intantiations (ie the objects players actually use).
Not making the distinction makes things simultaneously a little
messier and a little easier in implementing the system.  You now
have only one type of thing to deal with (objects), but you now also
have to deal with a mess of class heirarchies amd objected
heirarchies which are intermingled.  Depending on how you approach
things, the difference can be large or quite small.

Now as to how the bytecode is actually stored, there are lots of
ways,  if you think about the bytecode really is just another data
stream associated with a class or an object.  You could even do
something as simple as:

  class class_definition {
    attribute *attrs;
    method *methods;
    byte-code compiled;
  };

and keep them all together, and handle them all together in whatever 
your persistence system is.

> Here, I'll try to demonstrate what I little I think I know from
> MUSH type enviroments. A MUSH allows you to create an
> object. Great. This object is unique and persistent. Ie. it will
> be there when you get back if you so desire. You can assign code
> to execute based upon certain defined actions on the object, or
> you can create a new action for this object. Going by this model
> then, does that mean every single object in these "new" muds is a
> class and is inherited from a previous object? But then it's
> executed how?

See the above dinstinction between classes and objects.  MUSHes fail 
to make that distinction and thus every object has the potential to
both be an object _and_ a class definition for other objects and
classes.

Yes, it is kind of confusing if you come from a strict OO
background.

As mar as execution is concerned (which only ever properly occurs
for objects, not classes), that occurs by having something call one
of the methods on that object:

  class X {
    void poke () {
      print "Hello there!";
    }
  }

  Object Y is an instance of class X.

  You then have something call Y.poke () to invoke and run that
  code.

> I think I have my object/class/code/driver concepts all muddled.

That's really easy to do with most MUD server implementations.

> -doesn't require me to learn it's "own custom embedded
> language"...

Realise that no matter what language it uses, for someone it will
require learning a whole new language as they won't know it.
Doesn't really matter if its Java, Python, NetREXX, or whatever.
The advantage with chosing a generic programming language here is
that your audience of people who do know it increases, and they have 
some chance of being able to exploit that skill elsewhere as well.  

Note however that once you have a language chosen, the real learning
pain is in your class heirarchy -- which is expressly NOT portable
and NOT leveragable to other systems.

> -somehow allows for security and access levels while coding
> -somehow allows for an event type system 

This is a bitch and a minefield.  You are caught right in the middle
of usability requirements on the one hand, and the need to keep
things secure on the other.

> Muq seems to have most of these except for MUF, I got tired of
> programming backwards ;).  

I'm no fan of RPN either (or lisp for that matter).

> Then there is Momoko, it uses Java which would be great, but I'm
> not quite sure how to go about things and if it insists on having
> everything in memory or not and file management etc and i'm
> unclear if every unique object is it's own class on a persistent
> system.

I haven't looked at Momoko in any detail yet.  Would someone care to
point out MUD-Dev to the authors?

--
J C Lawrence                                 Home: claw at kanga.nu
----------(*)                              Other: coder at kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--


_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev