[DGD]New mudlibs

[John W Pierce]

 > Tim Vernum
 >
 > The mudlib should ... perform object interaction, generate
 > outcomes [and] provide output in some form of markup (XML perhaps).

Yes, this is exactly what should happen. However ...

 > Then you provide a "client_renderer" object on the DGD side
 >  that converts the internal markup into a format that users
 >  can handle....

It depends on what you mean by "...on the DGD side...". Really, direct
communications with users should be handled by a totally separate process.
The MUD should be run by a "mud server" - e.g., DGD and a mudlib. It should
talk only to "comm servers" - that is, separate processes, possibly on
separate machines, that deal with the vagaries of end-user communications
(login, formatting, etc). A "mud server" and its "comm server(s)" exchange
messages in some canonical form.

All verbs (and, ideally, all nouns, adjectives, adverbs, and prepositions)
should be known globally within the virtual environment, and the mud server
should pass those lists to a comm server when their connection is first
established. That allows all parsing to occur in the comm server process.
Thus, if the user types "catch fish" and the verb "catch" is unknown in the
entire virtual environment, the comm server can reject the input
immediately;
likewise if "catch" is known but there is no object that will identify as
"fish" anywhere in the virtual environment. When the mud server finally
receives the input, it is already parsed into a canonical form; the mud
server is responsible only for determining if there is an object that
identifies as "fish", to which the verb "catch" can be applied, in the
user-avatar locale.

I coded a prototype system for DGD several years ago, and it worked quite
well.
Unfortunately, we didn't get a piece of the action on the research project
for
which that work was done (the DARPA CAETI stuff), and I didn't have time to
do
anything further with it. I was also too dumb to get a commercial DGD
license
when they were only $100/month. Now that I once again have time to muck with
this stuff, the cost of a DGD license is too high (in my opinion) for very
small
commercial usage (100-200 subscribers) so we're building a driver. This
isn't particularly difficult, but it's annoying because it's the mudlib
that's actually the interesting part of this business.

-- John W Pierce, R2 Systems, San Diego
   jwp at r2systems.com



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