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

[Chris Gray]

Apologies in advance for an typos, etc. - I'm in a hurry this morning...

[Ola G:]

:Uh, well, in my opinion, persistence support (compiler/language/library)
:is great for rapid prototyping, especially if you have a graph-like
:object system, but there are some downs:
:
:1. even minor changes in datastructure may require a wipe, or some
:extra	  coding effort

Major data structure changes require a total system rebuild in a non-
persistent language system, so this is hardly a disadvantage of persistent
systems. The point is that with a persistent system, it can be possible,
though likely a lot of effort, to make such changes without takin gthe
system down. That might be important for a major commercial setup that
simply cannot afford downtime.

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

:3. fixing a bug in the code may not be enough if the bug is present in
:   the stored structure.

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. So, no real
difference. One slight difference is that in a long-uptime persistent
system, the bugs accumulate, whereas if you keep shutting down and
restarting your system, you might have fewer symptoms present at any
given time.

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


Here is one real disadvantage of a persistent language system versus
a more traditional "save character stats to a file" system. In the
former, problems in the underlying system, or to the overlying
scenario code can result in character structures getting mangled. That
mangled-ness persists. If you have a very simple save structure, then
you can fix your code problems, and then reload your characters from
the simple files, without loss of any information that you are supposed
to save about the characters. Such kinds of fixes are possible in a
persistent system, but they are more work.

:Well, actually, the guy with the original post seemed to ask for
:information on A LOT of fields,and quite specialized ones, and was still
:talking about "hobby" projects.  I don't really think that is the right
:"mood" for getting a project done (my own experience).  What I tried to
:get through is that you don't really have to get into all the messy
:optimizations or advanced parser stuff right from the start. It's a very
:bad idea for a startup to use more advanced techniques than needed for
:running a small scale server.	The only main issue is to design the
:object system and make components (like binary trees) independent and
:replaceable.  More advanced approaches usually results in increased
:codesize, more bugs, more interdependencies, longer compiletimes, longer
:development times, difficulties when making major changes etc.

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, I knew it was written without any connection to Xerox, but that
:was not the point.  What I tried to get through was that the basic
:designs for new approaches to MUDs are typically done by professionals.
:That is at least my impression. (I don't like MOO or any of it's
:decendants, but that's another issue) Although most MUDs are run as
:"hobby" projects, which is a different thing...

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?

:I think there is at least 3 major MUD designproblems:
:
: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.

:2. To cut down the project constantly. To collaps several concepts into
:one concept.  To force onself into NOT adding another feature. 

I'm an incessant trimmer and optimizer, but sometimes you have to add
features to, well, add features.

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

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