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

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

>[Ola F:]
>
>:		All textbased MUDs currently existing are higly discrete
>:and static in nature and would map nicely onto a traditional database
>:system, but the systems I am interested in would not.	They are way to
>:iterative, dynamic and fluid-like in nature.
>
>I think you need to stop and hear about some of the systems that people
>in this list have implemented before you go making blanket statements
>like that.

So why don't you tell me?!

>
>:				  And the fact remains, if you change your
>:object-system (class-hierarchy if you like)  you need a wipe if the data
>:stored in the internal structure is reflected on the secondary storage
>:device. (which it will if you use straight persistence)
>
>Nonsense.
>
>    SetParent(AThing, NewParent)$
>
>Done.

????

>You are thinking only in terms of the C++ style of "objects". When all
>objects are indirectly referenced (what "objected oriented" meant before
>C++ came along and clouded the issue), such changes in the hierarcy are
>fairly trivial.

I think you need to pick up a book on computer language history. Simula67
has references much like C++, which is natural since Stroustrup is of
Simula breed.  Indirect referencing won't help you much if you split
objects, does it?  If you change your objectsystem there is trouble in
any conceivable efficient language.  Some changes are easier to do in
some languages, but for the general case, you are in trouble.  Indirect
referencing is of course great for a lot of things, and probably a
weakness in C++ compared to the languages you use.  But not in this
case.

Of course, if you care about efficiency/compiler optimization then
dynamic resolving is shit.  If you use C++ (which sucks) you better
care about efficiency.  I would think most people using algol-type
languages care about performance.

>:Anyway, if realtime information is no problem, why don't you just use
>:plain core-dumping for saving your data between executions?? Tell me!
>:Core-dumping would be the most efficient and easy way to do persistence,
>:wouldn't it?
>
>Again, you need to hang around and read what people here are doing before
>jumping to conclusions. Several of our systems are disk based, with only
>a recently used subset of the data actually in memory at any time.

You know, diskbased systems is one of the traditional approaches to
MUDs... :)

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 I was pointing at with coredumping was that
there is more to persistence than to freeze the systemstate, so in a
general programming language (OS-level) you somehow have to differentiate
between those things that are valid between runs and those that are not.

I personally cannot see why anyone would design a diskbased system when
RAM prices seems to be cut in half every 8 months or something, and
most UNIXes have decent virtual memory systems.  In 4 years I'll probably
have 1GB of RAM and 3GB of swapspace, what bothers me is not lack of
memory, but memory accesstimes and distribution (multiple servers).

Then again, I am of course coloured by my own attitudes towards design
of virtual worlds.

>:No, it is not. If persistence is totally reliable and did what it should
>:ideally do, you would not need to store information in two ways.
>:Period.
>
>Depends on what you mean by "backup". For my system, a backup is a fully
>consistent copy of the MUD persistent store files, made in another
>directory. This protects against system crashes.

I wrote "backing up vital information like scenery and user attributes" or
something like that.  The idea was to back up against datastructure bugs
that has remained in the system for a while, even from the start, hence
bugs that calls for a wipe.

>Agreement does indeed seem far away. However, having worked with a
>persistent store MUD system for about 5 years now, I come to value its
>persistent nature more and more as time goes by. There are so many
>things I just don't have to worry about.

But, I have nothing against a persistent store MUD system.  What I warn
against is using persistent store general language support (OS-level)
without making separate load/save functions for the most vital information.
The only reason I pointed out some downs with a persistent object-store
is that I recommended someone on the list to look up a persistent
object-store library instead of building his own.  Later I felt obliged
to warn against some downsides that this approach usually will bring
with it.  Which I guess some die-hard persistence guys took personal.

I've used the persistence system in Beta, which was ok for
prototyping.  I think their approach is fairly ok, as it doesn't affect
anything in your design, and it allows for sharing of objects among
servers (beyond remote function calls). It takes a snapshot, which is what
I want in a MUD system (not in a banking system though).
It doesn't hamper the language in any way either, but is an add-on (with
knowledge of language internals) that you can add to an exisiting system
with little effort. The main problem is that you have to tell it where
to stop and that it cannot save components (objects with their own
runtimestack) and that it is sensitive to class modifications due to a
simple implementation.

Ola.