[DGD] The future of muds

[Felix A. Croes]

Neil McBride <neil at dogl.net> wrote:

> Agreed.  I've been working recently on a mudlib that makes use of the  
> new WebSockets protocol to provide a purely web based interface.

There may still be hope. :)


>[...]
> My library is currently based off the Kernel library, so I'm curious  
> about how you intend to approach resource management in a manner that  
> is more appropriate for use with Hydra?

The kernel library's resource management system is intended for
collaborative muds.  It imposes quotas on the programmer for things
like the number of objects.  To be able to do that, it must accurately
keep count in a central object (one per programmer); doing so defeats
Hydra's concurrency, unless the update is done via callout, but in
that case the count is inaccurate until the callout executes, which is
easily abused by a programmer with bad intentions.

Hydra is designed for commercial users, where quotas are largely
irrelevant (Skotos uses the kernel library, but most objects belong
to a single owner with unlimited quotas).  Keeping track is much
more important than imposing restrictions.

Another thing that makes concurrently adding objects belonging to
the same owner impossible, is the double-linked list of objects
per owner.  Again, very useful in a collaborative mud, not so much
in a commercial game.

I considered changing the kernel library to better suit Hydra, but
then realized that the way things currently work is best for most
muds.  And it can still be used with Hydra, even if it prevents
concurrency in some cases.

Regards,
Felix Croes