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

Ola Fosheim Grøstad <olag@ifi.uio.no> Ola Fosheim Grøstad <olag@ifi.uio.no>
Sat Aug 30 22:49:56 CEST 1997


[some good observations deleted]

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

References were the ones I was thinking about.

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

This is one of the things that you typically would do when you write your
own load/save functions. A persistent object-store should supposedly
"free" you from these kinds of things, but it doesn't.  That's what I
was trying to point out...

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

Because I want control over my object structure.  I wouldn't trust the
persistence mechanisms I've seen as the only way of storing vital
information, like scenery and user-profiles.  I want to be able to make
major changes (perhaps for efficiency reasons) in my datastructures
without too much trouble.  But of course, in a large project you might
be able to use persistance for distribution of entire "meshes" of objects.

[more good observations deleted]

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

Now, isn't that interesting?  Games is probably an area where complexity
is a goal (puzzles etc), but only "fun" complexity.  Ok, so I should make
it more clear:  It is desirable with a lot of variation in a virtual world,
but you don't want more mechanisms than neccessary.  By being "smart" you
may keep complexity down by inventing mechanisms that covers more than
one field. So essentially you want to keep code complexity and use interface
complexity low, without sacrificing the perceived richness of the world
too much.

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

Define "a complex world"!?  A near-random world would be truly complex,
wouldn't it? :-)


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

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

Yeah, it might, although some probably run hobby projects because they want
as many happy users as possible.  Some do it out of research interests.
I've got a feeling most people do it for the sake of getting the power though.
(Controlling a world! Rule... :-)  I think that may be the one big difference
between professionals and hobbyists, a professional wanting to rule the world
and his users ought to loose his job...

If this is the case, then the only way hobbyists can contribute to the field
is by trying out totally new concepts (going way beyond another RPG style
MUD)... Focusing on minor issues like "alignment" is not going to move the
field by an order of magnitude.  I just think it's sad that so many people
spend so much effort into minor issues, when there are so many new things to
explore out there.

Ola.



More information about the mud-dev-archive mailing list