[MUD-Dev] Languages for MUD drivers
bossavit at cybercable.fr
Wed Nov 17 22:13:44 New Zealand Daylight Time 1999
Ian Macintosh sez:
> Distributed processing support can be handled by running multiple
> processes and interconnecting them. I've always thought that this is
> a better way of handling large systems and a large number of users.
> ie, segment areas (zones) onto different servers and link them.
There's no really good (read transparent) way to interconnect several
MOO servers in that way. Suppose I'm running the Feral Forest on
server A, the Damp Dungeon on server B; I want the key from the lower
dungeon cell to open the witch's hut in the forest - hence I want the
player to be able to take the key and move from A to B, moving the
key with em - and there's no way AFAIK that can be done with MOO.
Even assuming something like an 'object exchange protocol' that would
let server A open a connection to server B, spit out the key object's
code and properties so that a new, equivalent object can be created
there, and the old key deleted; assuming I have a way to make sure
the key won't be duplicated or deleted altogether if something
happens to the network connection between A and B while this is going
on; assuming I can do the same to the player object; assuming I can
require the player emself to disconnect from A and reconnect to B in
an orderly fashion whenever this happens - which implies a custom
client program, or tech support headaches...
Hmm, I can't assume all of the above anyway since it's far from
realistic, but you see where this would lead - a lot of in-DB code
that deals only with such interconnections. (And what if the key has
a property pointing to another object local to A; and what if the key
has parent objects that are not in B, etc. etc.) It's much better if
such distributed processing is in some appropriate fashion a
capability of the server itself. MOO as it is doesn't fit the bill;
and adding these capabilities to a MOO server wouldn't be a piece of
In fact, my port to Java did include distributed operation support,
based on RMI. One of the first things that became apparent as I was
implementing it was that some MOO-language modifications would be
necessary; the very least I could get away with was a syntactic
representation of remote objects, i.e. the literal
referred to the local #1 whereas
referred to #1 on my.server.com. With these modifications it was
possible to call verbs and read or write properties on remote objects
transparently, as if they were local.
But I soon realized I had in fact opened a very nasty can of worms. I
had to add code to the server to prohibit creation of local objects
that were children of remote objects, otherwise I would have had to
implement a distributed database as well - which was both beyond me
and beyond my time budget. Another problem was the permissions
system; how the Wizard on server A would be prevented from having
wizard access for server B's objects, or if I decided to 'trust'
wizard bits between servers, how to securely authenticate server
To cut a long story short, I eventually gave up on "good"
disitributed support and left it in a fairly primitive state - I had
to ship product and it didn't look as if it would see much use.
> I'm not sure of what you are refering to when you say concurrent
> processing support? I understand the term, but I don't understand
> the context re reactive worlds?
I'm basically referring to support for preemptive (rather than MOO's
collaborative) multitasking. Task scheduling seems to be a primary
cause of lag in MOO servers - true multithreading means a server is
more responsive; at least that's the theory.
> Perhaps you could also elaborate reflective capabilities?
Well, MOO's at least got that - in spades : I mean the ability (in
verb code) to find out what verbs and properties are defined on an
object, and possibly to modify those. This is a central feature, at
least IMHO, of a modern M* server - because it lets you write in-DB
editors. This may seem peripheral to some, but it's crucial to the
notion of a virtual reality : the point of MUDs and MOOs was that
they could be modified 'from the inside', which made them more like
the real world - we don't 'step outside' the real world when we want
to modify it, but modify it we do !
We all live in a yellow subroutine.
MUD-Dev maillist - MUD-Dev at kanga.nu
More information about the MUD-Dev