[MUD-Dev] MUD Design Fundamentals (Was: Looking for books...)
Ola Fosheim Grøstad <firstname.lastname@example.org>
Ola Fosheim Grøstad <email@example.com>
Sat Aug 30 18:14:02 New Zealand Standard Time 1997
>Major data structure changes require a total system rebuild in a non-
>persistent language system, so this is hardly a disadvantage of persistent
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
>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
More information about the MUD-Dev