[DGD]Melville Mudlib

[Par Winzell]

In response to Dworkin's recent stirring posting about the interesting
times ahead and a new generation of mudlibs, here's an outline of some
of the constituent parts of the lib we're writing at Skotos, including
discussion and motivation.

By far the most influential factor on design has been persistence; the
idea of a state space that is cold-booted only once and then stays up,
potentially forever. Core support for this has been in DGD for a long
time; much of Dworkin's kernel library is designed with these demands
in mind, and people have been -talking- about peristent Muds for a long
time. So why aren't there any yet?

Well, it's damn hard. One of the basic problems, a recent topic on this
list, is program upgrading which requires LPC support in the form of a
object-database. More generally, the necessity of basic consistency is
upped brutally. If after a year of precious uptime you find some vital
datastructure to be corrupted, you're going to be very sad. When this
happens to the mudlib you wrote, you'll be glad you based it around the
kernel lib -- which still runs, and lets you do an emergency login and
poke at the guts of your broken world.

So we use the kernel library, unmodified. Easy decision to make.

Incidentally, the -game- effects of persistency are of course enormous.
That's another discussion entirely.

The ~System level is small. It has three major components -- the object
database; a second-level auto object which adds some protection against
destructing clonable objects that have clones; and some API translation
to the rest of the lib of kernel services which only ~System is allowed
to directly access.

The guts are in ~SkotOS. This means they get the benefit of the ~System
level restrictions and clone book-keeping. Here we have,

 * HTTP service. Text is great, but a browser interface can be used to
great advantage, especially for administration and development. This is
especially true in a persistent game, where manipulating state in one
way or another is much more important than in a rebooting Mud, where it
is the LPC (and save_object) files that really determine what the world
is. We're flirting with HTTP 1.1 compliance.

 * Standardized functionality for the export and import of object state
through XML. To use this system, the object describes its function-call
interface for query() and set() style operations. With this description
we are able not only to fetch the object state and transcribe it to XML
but also to generate for it a true DTD (Document Type Definition). With
the help of this DTD, which describes precisely the possible structures
of the state, external XML authoring software will be able to construct
word-processor quality GUI's for any object that uses the system.

 * An XML parser (and generator) which uses parse_string(). XML is just
a data storage format, so just parsing it does little. The data may be
object state as per above, destined to be squeezed back into an object
somewhere. In addition to this static structure, however, we use XML to
do an active mark-up of text fields. In SGML/XML terms this is "PCDATA".
   - In-game descriptions may be marked up to vary depending on server
state; for example, a room description may vary by light level relative
to the looker's night-vision stat, or variables associated with players
or rooms or other objects may be embedded in the text.
   - We also generate HTML from the XML, and thus automatically have a
powerful system for server-side generation of dynamic HTML. We'll ship
the lib with a set of such XML-HTML pages.

 * A decent command parser which should understand a sensible subset of
English. We have chosen to completely forbid guess-the-verb puzzles, by
centralizing the parser entirely. If a verb does something anywhere, it
does something everywhere. Successful commands are turned into actions
or sequences of actions taken by objects in the virtual world. We tried
for as much separation between client-interface and world as possible.
These sequences of actions could equally well be generated by clicking
on things in some isometric graphical client. While we try to keep that
door open, we're concentrating on text as the primary interface; though
we expect ambitious developers to allow for e.g. stat-showing graphical
client-side panes, scrolling (and clickable) maps, and more.

 * A pretty intricate system for expressive/emotive stuff; while there
is no emote-command, the social verbs are plentiful and come with lots
of adverbs. That's nothing new; the interesting stuff are stances and
poses, which are tied into the world simulation to a higher degree than
I have seen elsewhere. I am able to e.g. kneel before an altar in quiet
repose, or lie on a table, or stand next to Dworkin in a room with more
effect than a transient statement of fact -- these ways in which things
can relate to each other is used in describing the environment. Certain
socials break certain stances and poses.

 * There's the idea of a prox -- something one can be in the proximity
of. Dropped gear will be lying 'near Zell' instead of in the usual big
collective heap. If I walk away from my battle-axe, it simply lies on
the floor. One of the things we hope to do is to kill off this ancient
truth that LPMuds aren't very good for social Mudders.


Phew. Then, finally, there is the virtual world itself. We separate the
world objects from things like command parsing and text generation much
more than does e.g. 2.4.5; this helps the world state to be independent
of client interface, as discussed above. We just took a step further in
this direction and utterly slew the time-honoured sub-classing approach
to physical objects. There is now only the ur-thing, and it can be room
or sword or bag of gold -- or all three -- depending only on its state.
Thus everything is really a clone of /base/obj/thing, everything can be
eaten (possibly with great discomfort) or used as a weapon (possibly a
very bad weapon). Of couse, that effect is equally possible to achieve
with traditional sub-classing. The difference is again the trend toward
the data-driven, which seems to happen naturally around persistence.


It should not be difficult to tell that the early part of this document
details things that are pretty much settled, while the mutations of the
/base directory are recent and somewhat shocking.

So. When will all this be available to play with? I'm unsure. October?

Comments requested!


Zell

List config page:  http://list.imaginary.com/mailman/listinfo/dgd