MUD Design Fundamentals (Was: Looking for books...)

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

A late response..

coder at ibm.net wrote:
> On 19/08/97 at 09:55 PM, Ola Fosheim Gr stad <olag at ifi.uio.no> said:

> >Do you really need any advanced database design in a mud? Do you
> >really need real persistence, or is saving the most vital attributes
> >enough? (ought to be)  Persistence isnt always very cool if your code
> >has bugs (depends on the approach I guess).
> 
> Many, not all, of us here are discussing creating full worlds with no
> concept of object or world resets.  As such persistance of objects,
> and object changes are implicit to the world design.  The base
> assumption thus changes from "save what we have to" to "everything is
> saved by default, explicitly not-save what we don't want".

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
2. reloading may not give you what you want, it is easy to make blunders
3. fixing a bug in the code may not be enough if the bug is present in
   the stored structure.

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.

> >>    Tree algorithms (esp R-Trees, et al) (all I can find are general
> >>    algorithm books that discuss binary trees - sigh)
> 
> >What is an R-tree, why bother with more complex things than binary
> >trees (or a self-balancing tree (splay?)) and hashtables if those are
> >sufficient?
> 
> Because when you move from a room based model to a fully coordinate
> based model your data set grows exponentially.  A significant problem
> then becomes determining what the working ste of objects for a
> particular event is with the least amount of computational overhead.
> Various tree form data structures, such as R-Trees, R*-Trees, V-Trees,
> Oct-trees, K-trees etc offer various perfomance and manipulation
> returns here which can then be selected from for best performance on
> *your* loading.

> >The compiler book covers parser design, though for a
> >startup project a simple approach would be sufficient, dont you
> >think?
> 
> A lot of us are a long ways beyond startups.  We also have several
> contributors from well known MUD server bases, and from commercial
> offerings like Ultima Online, the TEN Network, etc.  The idea is to
> extend the state of the art by at least an order of magnitude of more.

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.

> >MOO was
> >written as a research project and the author is with Xerox Parc...
> 
> MOO was written by Stephen White, and was some of the worst code I've
> seen.  He then rewrote MOO and set it up at Xerox PARC with Pavel

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

BUT I do believe, with the help of whatever libraries being available,
some general programming knowledge and the major reference books, that
"hobby" projects will be able to provide running systems exploring new
concepts, provided that the designteam is able to focus on a few
concepts.  I don't believe it is lack of specialized knowledge (such as
NLP design) that prevents them from surfacing.


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.

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

3. To force a change of metaphores. To explore more than one concept
continuously throughout the designprocess.


(1)I've kept an eye on the discussions on the list and there is A LOT of
talking about more or less trivial game mechanics issues, like alignment
and such, but I've seen few posts in the past week that talked about
game mechanics based on a desire to create a better social environment
or even a more FUN environment or USABLE.

(2)The thought "I am designing a world" is your best friend and worst
enemy.  It is difficult to keep complexity down to a reasonable level
(in all respects) when you are thinking WORLD.

(3)Metaphores is an important aid in design, but forcing oneself to
using more than one is rather difficult.  I was recently stuck in a 
barbie-dollhouse metaphore for some very good reasons, but discovered
that ball-floating-on-ocean was better for what I am trying to do.


You said "The idea is to extend the state of the art by at least an
order of magnitude of more", but I'm afraid that won't happen soon
unless there is a radical change in attitudes to design among even the
"hobbyists".  The search-space is vast.  I think it would be rather nice
if at least one started to think in terms of "utilizing the resources to
the benefit of 95% of the users", who cares about features that only the
last 5% have strong opinions on? (I'll make an exception for features
that adds building/maintainance capabilities)

--
* Ola Fosheim Groestad  (http://www.ifi.uio.no/~olag) *