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

[coder at ibm.net]

On 30/08/97 at 09:47 PM, Ola Fosheim Gr stad  <olag at ifi.uio.no> said:

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

Persistance can be handled in various manners.  Within the membership
of this list, most of those manners are being used.  As mentioned
earlier, my approach, common on this list, is to not distinguish
between code and data, and to render them both persistant in a shared
persistance mechanism.

Mechanically this translates into defining an internal OO language for
the MUD server, implementing the world in the OO language, and then
making the objects rendered with the OO language persistant.  I
stretch this a little further than several here in various regards,
but the principle remains.  

You apparently consider that this cretes a performance concern (taken
from later messages from you than the one quoted above).  I disagree. 
The Tiny-* family, the various MOO derivatives, ColdX, and similar
would seem to demonstrate otherwise.  Add in a good byte-coding engine
and an efficient mini-VM, and a lot can be gained back.  Allow
world-authors to devolve functions back to machine-native code which
then act as built-ins to the server (ala MOO) and the sore spots can
largely be addressed.  ColdX acts as a good current model in this
regard.  LPC (if you exclude the persistance aspect) acts as a very
good example of a well tuned (even over-tuned) language system with
features that cahllenge some commercial optimising compilers.

LPC has been demonstrated effective on high-end Intel PC's with
simultaneous user loads up to the 800 range and and active world of
over two million objects.

I don't have stats for ColdX.  BrandonG or Miro know more there than
I.

Doing the arithmetic, and in simplistic testing here on a not-very
high end machine, I am content that allowing MUD world code to be
written in an internal server-specific language can generate
acceptable performance for large complex worlds (10 Million objects,
1Million active objects), with very large user loads (1K+) is possible
without excessive effort.

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

The concetration of this list is not virtual world theory.  It is an
acceptable topic within the list, but the list and the list's
membership is not constrained to that.  Please see the welcome message
for the definition of topic for the list.

I would also note that even within Virtual World attempts, there is no
requirement for the world created to actually resemble this world or
its mechanics to any significant extent.  Of course this can be an
escape route to avoid complexity, but it can also be used to create
something with entirely different mechanics.

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

That's a very limited definition of metaphores.  Scenarios can also
act as metaphors in that they present an encapsulated model which
drives the is-like relationship, as vs a real-world object.  

--
J C Lawrence                               Internet: claw at null.net
----------(*)                              Internet: coder at ibm.net
...Honourary Member of Clan McFud -- Teamer's Avenging Monolith...