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

[Adam Wiggins]

[Ola:]
> coder at ibm.net wrote:
> > 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:

Persistence of a world doesn't necessarily map to persistence of a language,
although it certainly may.

> 1. even minor changes in datastructure may require a wipe, or some
> extra    coding effort

I should think that any good database would be able to handle this.  My
personal choice is to do human-readable files, so that additions or changes
to the database doesn't affect existing objects.  If a field is not
specified, it is just set to default.  Also all the units in the file
need to be specifiable; this has two nice benefits - one, you can make
distance, time, weight, and temperature meassurements in real-world units
you are comfortable with which will then be converted to mud units; and two,
if you change the mud units, the data files are unaffected.
The second choice, if you want to do binary (non-human-readable) files, is
to implement versioning on objects.  Thus you can have a version 2 sword in
the data file which is read in and converted to version 3 which features
four new fields.  This tends to make code size bloat a bit in the long
term, however, since you need to keep track of every version you've
ever had.

> 2. reloading may not give you what you want, it is easy to make blunders

Hum...assuming you have good base functionality (resolving references/pointers
to other objects is a prime issue) it should be difficult to make blunders.
In fact, you should ideally be able to pretty much ignore the fact that
the object is persistent.

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

Well, possible, but simple sanity checking on load should take care of
most problems.  If a field was set to an out-of-range value, that should
be rememdied when it's loaded back in.  This is just a good idea in
general, in case the data files get corrupted by external means.

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

Why?  Unless the base system is not sound, it can take large projects
from impossible to merely daunting.

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

True, although it generaly makes it a lot more fun to actually work on. :)

> 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

I think it's important to consider these things, ie: "I'll make the spacial
DB be a sorted linked list for now, I can always go to r-trees if that
becomes a performance problem."  You want to design the system to be
semi-independant of the actual mechanisms so that you can replace them at
a latter time, even if you don't have a specific mechanism in mind.

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

The most frustrating thing is realizing you don't need a piece of code
you sweated over trying to optimize, or realizing that the way your
server is working out that you wasted your time optimizing THAT piece of
code, since it's THIS piece of code that's bogging the system down.
That's what profilers are for.  These sorts of programs are just a little
too complex nowadays to be able to sweat over the performance of every last
system, since it's only usually a couple that actually matter.

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

This seems to imply that a complex world is bad thing?
I write PC games at work; I get a bellyfull of super-simplified worlds.
With my spare time I want to do something *really* interesting.
Of course, complexity of a world doesn't necessarily trace back to
complexity of code.  My own goal is to create as complex a world as
possible with as simple and elegant a system as possible.

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

If I'm one of the 5%, that's when.  I'm writing my mud for one reason, and
one reason only: personal gratification.  I don't care one whit if someone
else dislikes my personal tastes and methods.  Naturally, of course, I
always like others to participate, including my partner, without whom I never
could have gotten this far, and those folks who share similar tastes with
my own such that when they play the game they are impressed and/or excited.

And of course, this is what defines a hobby project vs a professional one:
the later actually requires that attention be paid to the users, since
they are no longer users, but rather customers.