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

[Chris Gray]

[Ola F:]

: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.

The fact that a system is built on a persistent language doesn't mean
you *can't* throw it all out when you want to. I do that all the time
during world development. Its only when a system is up and running, and
you want it to stay that way, that you want to avoid rebuilding the
world from scratch. A persistent system makes long-running systems
easier, since you can often do more without the shutdown/rebuild.

:"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.

Well, my language doesn't have classes, it only has objects ("things").
When one thing inherits from another, any properties on the "parent" are
also readable on the "child". Any that the "child" has specifically will
override any values on the "parent". Updating a property on the "child"
will create a new override if one wasn't there already. Updating a
property directly on the "parent", will update the value on all "child"
things that don't override it. Deleting a property from a "child" will
expose any value for it on the "parent". Think flexible arrays of
properties, not structs - nothing is fixed. Oh yes, when you do SetParent,
I scan up the parent chain for the new parent, and don't let you make 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.

I agree. I added "SetParent" to my system because it was easy, and
because someone in a newsgroup was saying it was important. I've never
actually *used* it in my worlds.

: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.

I *think* I'm right there, but don't count on it - I'm quite out of
date on things like LP's, having not worked with one for several years,
and then only a very little bit.

: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.

Certainly. If I ever need to do something like that in my MUD system, I'll
think about on-the-fly compilation to native code. Since my system is
strongly typed, I can likely get close to unoptimized C code without
too much trouble. Heck, right now I don't really have arrays - just
flexible arrays (AddTail, AddHead, RemTail, etc.) that can be indexed.

: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.

I'm still not following you here. Can you give an example? I *do* have
special "un-savers" (sort of) in my current world, but I don't think that
is what you are getting at. For example, I have a quest area where there
is a single unique object needed to solve it (I know, that's icky!). The
world code keeps track of who has it, and where they are. If the world
is restarted from a backup, I take the object away from the character,
and move the character outside of the area. I then politely attach a
temporary action to the character, so that when the player next logs
on, they are informed of what happens.

:>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.

Sure, that's good to do, but is a bit lower level than I want to go in
writing a world. My database code *could* attempt to do compaction, but
I've never gotten around to doing it. It's also hard to judge which link
from thing A is the one most likely to be followed - how do you compact
a graph optimally, without keeping usecounts on all arcs?  :-)

: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.

Well, we definitely agree on those issues! It's a long time since I read
about Multics in my OS course, however, but I think my ideas might be
somewhat further out than many people would like!

--
Chris Gray   cg at ami-cg.GraySage.Edmonton.AB.CA