[MUD-Dev] MUD Design Fundamentals (Was: Looking for

[Ola Fosheim Grøstad <olag@ifi.uio.no>]

>explain what you mean by "splitting objects". As someone who isn't at
>all in on the current C++ or OOP "scene", terminology used there is
>mostly foreign to me. Explain also what you mean by "change your
>objectsystem". Certainly if you decide to change the whole way your
>use of objects is setup, so that properties are moving, being changed
>from explicit to computed, etc., etc., then you want to redo your
>system from scratch, regardless of what kind of language you are using.

That's what changing the object-system was intended to mean.  To change,
add and remove classes. To do major restructuring. I wasn't talking
about transforming instances, but in a pesistent system you would have
to transform all instances of that class.  I'm not used to discuss OO
outside my university, except for a whort while on a oo newsgroup which
ended in some kind of flamewar between those that only viewed oo as a way
of extending a programminglanguage, and those that viewed it as a
way to build a conceptual model of the problem space (the part of the
world that your program cares about).  According to my OOA book
"object system" is supposed to mean: The coming users perception of what
the computersystem is used to admin, control or supervise.  This
wouldn't make sense in a MUD system however.  When I talk OOP I take it
to mean what concepts are present, and how they relate.  But I use it on
a conceptual level, not on an instance level.

>To clarify for you (old stuff for others on the list), in my system,
>an "object" is just an entity of type "thing", persistently stored in
>the on-disk database, that is a small fixed structure (which includes
>a "reference" to the parent, if any), along with a flexible array of

"Parent" could mean classdescription, superclass or a clone-source,
the object that created the object or a container (as in LPC).
>From what you say, I would think that you mean the part of the instance
inherited from the clonesource (or superclass), except you accept any
inheritance, which in the general case could result in loops.
Personally I prefer static single inheritance class hierarkies as I
think they makes reasoning easier.  Multiple inherithance (which I reckon
you don't do) can usually be avoided by focusing more on the most
important aspects of the design.

>You may feel free to discard this type of implementation as hopelessly
>inefficient, but I have found that it is quite practical for building
>MUD systems.

I'm not discarding any particular implementation that works.  I would
discard it as inefficient in the general case (which would have to deal
with 3D graphics etc).  With only a reference to the parent, you'll
be out of luck if the client is caching and need to be refreshed
when you update a parent that a client cached object references.

>Diku's where zone files are parsed and loaded. We mean something where
>stuff can be written back to the disk representation when it is no longer
>needed (e.g. the caching mechanisms have decided to punt it to make
>space for something else).

OK. I figured quite a few LP's threw things back on disk, though not by
caching. I'm probably wrong then.  Of course most of the stuff in LPs
are generated and not stored, though objects get compiled and cloned
when needed.

>:But this won't work in a dynamic system where "the wind is blowing",
>:where you have global dynamics implemented by solving oversimplified
>:differential equations.
>
>What won't work. And why?

Efficiency.  Say, you are convolving a 1000x1000 matrix with a 3x3
matrix (could be blur as in imageprocessing)  You want that to be
compiled and optimized and you want each element to be of a static type.

>There is more to persistence than saving the state of the entire system?
>Huh? Please elucidate.

You have to deal with realtime information, that changes between runs or
which is invalid between runs, either by not saving, cleaning up before
saving, cleaning up after saving or avoiding.  In a dedicated system, you
may of course hide that stuff.

>:memory, but memory accesstimes and distribution (multiple servers).

>In a word - granularity. The granularity of virtual memory is the native
>pagesize. The granularity of the structures in a MUD system can be more

I know, so that's why I'm having collisiondetection info in a separate
class, stored in one array.  Besides, if you do your own garbagecollector
it would be able to do compaction, move things around. And things that
get used quite a lot could be locked to RAM.

>Actually, as an off-time mental exploration, I've been idly thinking
>about an OS which is heavily based on a persistent language. There are

I'm having fantasies about new OS approaches all the time. Mostly because
all of the current ones are oldfashioned (backwards compatibility) and suck.
I wish somone would pick up Multics and take it to something decent.
The same goes for programming languages and GUI. 

Ola.