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

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

>Major data structure changes require a total system rebuild in a non-
>persistent language system, so this is hardly a disadvantage of persistent
>systems.

Depends on the system, some would punish you with a wipe even for adding
an attribute to an object.

>That might be important for a major commercial setup that
>simply cannot afford downtime.

Yes, but I think there are better and more reliable ways of doing that.

>:2. reloading may not give you what you want, it is easy to make blunders
>
>Ah, sure, but I don't see the point. Blunders are blunders, whether your
>system is persistent or not.

Actually, no.  During the development phase, you are likely to make
"too much" persistent compared to a "flatfile" approach. If you then fix
a bug or extend the system, the bug may still stay in that "too much"
part of the system.  During development you do want some test data, a
lot even.  My experience is that I resort to adding my own load(/save)
functions anyway, for primary data, possibly in a format readble by
humans.  Thus, I have more reason to trust the "cleaness" of the testing.

>True. HOwever, I've noticed that bugs are cause by code bugs (gee!). So,
>if you have a bug in a non-persistent system, then it will affect the
>same things there as it would in a persistent system.

I don't agree. In a non-persistent system you are likely to store your
data in a very simple and comprehensive way, which would be extremely
inefficient during the execution of your program.  In a persistent
system, you are likely to save a structure that is optimized of efficiency.
Big difference, in my opinion.

>:etc. I only have some experience with persistence, maybe there are
>:approaches that are better, but I know for sure that I wouldn't rely on
>:persistence alone in any long term project.
>
>Again, I don't see your point. Certainly you have to have something in
>yoru system besides persistence, but that is hardly a disadvantage to
>having persistence.

Uh?

>Depends on what the hobbyiest wants. If the areas they are interested
>in exploring are the advanced features, then that's what they will have
>to put in and work with. Not everyone just wants to put up a MUD of
>some kind in the shortest time possible.

Well, with MUDs you are likely to end up with "too much" no matter what
you do. (At least if you have a reasonable imagination. I do :)

>Very few of us here are "MUD professionals". We are mostly computer
>professionals, or perhaps even RPG professionals. Is that what you
>are referring to?

CS professionals, yes.

>:1. To have a reason for every feature and concept based in either of the
>:two fields social-psychology and userinterface design.
>
>Not something I ever even considered in mine. THen again, as a hobbiest
>in the area, I was interested in different aspects of the MUD world.

But then you aren't really interested in virtual world design theory,
but either a technical issue (which probably could be explored in a
different field) or creating a fantasy.

>:3. To force a change of metaphores. To explore more than one concept
>:continuously throughout the designprocess.
>
>Persistence is one such thing. So is multimedia.

Well, I wouldn't call persitence and multimedia metaphores, not very
useful ones anyway.  Metaphores in design, is for instance: looking at an
email application as a library, or as a telephone, or as a radio, or as
a typewriter etc.  It's a tool that is intended to make you explore more
concepts/ideas than by just saying "I'm designing an emailapplication".

Then there is metaphores in userinterface design. We all know the
desktop metaphore..

Ola.