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

Chris Gray cg at ami-cg.GraySage.Edmonton.AB.CA
Sun Aug 31 13:05:05 New Zealand Standard Time 1997


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

:				  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. Its possible in several of the systems done by people
in this list. On some, there will be no other action needed, on others
there will be some rebuilding needed, which may be done right away, or
whenever needed, in a "lazy" fashion.

: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. A
core dump is of little use. It's also not available on systems other
than UNIX, which some of the people here target.

:>Thats a totally different issue. NOTHIGN repalces the need for backups.
:>period. The end.
:
: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. Actually, with my little
server online, it was used to protect me when the system folks there
decided it was time to move the machines around, and just turned mine off.

:(I don't think we'll ever agree, I'm not going to waste a lot of time
:on convincing you. I've had a similar discussion before.  All I'm saying
:is that persistence is not as useful, advantagous and easy as one first
:may think it is.)

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.

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



More information about the MUD-Dev mailing list