From: beeman@cats.ucsc.edu (Adam Beeman)
Newsgroups: rec.games.mud.lp
Subject: Re: Distributed lpmud
Date: 14 Dec 92 04:34:36 GMT
Organization: University of California; Santa Cruz
NNTP-Posting-Host: si.ucsc.edu


In article <1992Dec13.231529.5764@cis.ohio-state.edu> mdm@hadrosaur.cis.ohio-state.edu (Michael Moore) writes:
>
>	Hey folks!
>
>	I am curious if anyone is working on a distributed lpmud?
>I know every so often people start talking about how nice it would be
>to be able to hop from one mud to the other via "portals" or whatever,
>so I would think it might be something people would want.
>

Every couple months the topic seems to come up, yes...  I thought it was a 
great idea when I had it, but I guess it has occured to quite a lot of other
people, too.  As usual, I'm flipping my own ideas around about implementation,
but it's not moving all that quickly yet.  The whole project is more than
a little intimidating, when you think about all the different issues it
raises. 

>	What I envision is a mud driver built to have these hooks.
>The central driver keeps track of the player files, and the core
>mudlib, the nexus, or whatever.  And then as the mud adds wizards,
>the administrator authorizes a portal to be placed inside the core
>mudlib which leads to the new wizards realm.  The new wizard would
>create his realm on his own machine, and it would basically be
>a clone of the central driver as far as lpc is concerned, but it
>would be slaved to the central server.  

Well, a mud driver written from scratch that adheres to this goal is probably
ideal, in the long run, and there have been several attempts to move towards
this goal.  Check out CoolMUD and UnterMUD for some examples... they are both
rather well designed from scratch...  I think however both you and I are 
looking for something more like an LPmud that does this, though, or we would
be content with Cool or Unter.  This, then, is not going to be something
written from scratch, but a driver that's been made flexible enough to handle
these things.

If you look at what's going on in the MudOS niche of the LP world, you'll see
that there are probably about 15 muds or more sporting intermud communication,
via tell, finger, and mail.  Intermud wiz channels aren't all that hard,
either.  With MudOS you can use both TCP/IP sockets and UDP sockets to form
connections between several muds.  (Not to leave anyone out, you can do this
with the CD driver, although to my knowledge only UDP sockets are supported.)
There's a growing number of muds on our "intermud network", and the protocols
are being refined all the time.  No doubt, it is possible to achieve some high
level of interconnectedness with the existing MudOS driver, and it's not
unreasonable to assume that people will make modifications in time to add 
better support for this, if needed.

However, one of the major problems here is how to go beyond the level of
"Buddha@Tmi-2 tells you: hey, what's up, dude?" to moving objects back and 
forth between the muds, dealing with network failures, and moving into a room
on a remote mud.  There are several ways of doing this, and the whole process
seems to sound like a nightmare...  I'd be glad to hear proposals on how to
handle this.

So far, there seems to be at least one idea on how to handle this, which is
the following:  All muds involved must share a core of standard objects, and
then the saved data can be transferred between the muds via the sockets.  Then,
it's just a matter of transferring whatever code is necessary and restoring
the object.  With this idea in mind, I've tried to make a very flexible
standard object that holds most of the object's data in a single mapping, so 
that the mapping could be passed from one place to another if needed.  Then,
the only code that needs to be transferred are special cases.

This raises two major issues right here.  First, maintaining a dozen nearly
identical core mudlibs is no small task in a rapidly changing environment.
Where do code upgrades come from and who should authorize them?  Are all
updates of even small areas of code to be done by hand, by the admin?  I would
hope not, as this could be a bit of a pain in the ass.  Second, what about
genre-specific code?  Pretty much every mud wants to customize, which is good,
let's not spit on diversity.  But, in order to move objects back and forth
between these muds, we have to be able to have some standards... where does
the mud-specific bits of stuff go, and how can we make it easily customizable
without destroying the protocols?

A second way to handle this sort of task, as I understand, is used by CoolMUD,
in what it calls the YO protocol (Yell at Object).  In this case, when you
move from one mud to another, you haven't actually transferred yourself to
the new mud, but instead, the local mud knows that your environment is
the remote mud, and vice versa.  Then, there's a little scheme of messaging
back and forth between the two muds, in such a manner as allows 
buddha@tmi-2 to be holding /obj/ball#32@portals while standing somewhere else.
However, it might be really slow, to just drop the ball.

>	My hope would be that this would allow muds to be much freer
>with their wizardships.  And that it would make muds capable of
>handling hundreds of players without slowdown.  Since the wizard
>would be running a gamedriver himself, he could set limits on how
>many players could be using his area at one time, but the overall
>effect would be a distribution of the network and cpu usage to
>sites spread throughout the internet.
>
>	Most students could probably run their mini-driver without
>much concern, since it would only be handling a set number of people
>at once.  I don't think an lpmud with 10 users is going to bother
>anyone.  

Definitely, I've been working all along to help create more, smaller muds,
where it's easier to get a coding spot... I really feel strongly that the more
people who are in "wizard" positions, the more of an intellectual persuit 
mudding becomes, and the more academically viable it is.

>	There would be new problems with this system.  For example,
>if the wizard's host site is in a bad place with relation to the
>player, then they would probably not want to visit there.  But players
>could pick and choose whichever realms they felt were tolerable, and
>avoid those wizard's areas which were to lagged.

Determining when the network is severly lagged or partially unavailable and
dealing with that will definitely be a major part of it all...

>	The administrators of the central driver could control which
>portals they added, and so they could provide quality control, only
>OKing something if it fits in with their theme, or whatever.

This will no doubt turn into a big issue, also, of whether objects can enter
and disrupt the game balance, wreck the genre, etc... and whether a wizard
on one place is a wizard elsewhere, etc...

>	Who knows, if it all worked out you could have a textual
>cyberspace spread accross the internet, with hundreds of coders
>managing their own private realms, and with players free to pick
>and choose among them.  All connected together at the nexus.

And that nexus will be called TMI!  Just kidding... This is a pretty cool goal
to work towards, it's hard to say if there will even be a central hub for all
of this, though...

>	I am interested in any thoughts on this subject, like if
>anyone is interested in the idea, if anyone is working on the idea,
>if there is a reason it simply won't work, further ideas, etc.....

It *will* work at some point, I'm sure... just don't know when.  Let's start
a thread! Or a mailing list! Or something...  I'd like to help hash out the
details in all of this and get it going, it's what I've had in mind for many
months now.
 
>	See ya,
>
>	-Michael ( a dreamer )

Don't be afraid to dream, man...

-Adam
Buddha@tmi-2

-- 
-------------------------------------------------------------------------------
 From the Mind of Adam Beeman       || Flames:      root@localhost
 #include <std/disclaimer.h>        || other stuff: beeman@cats.ucsc.edu
 insert your own witty quote here   || NeXT Mail: adam@samsara.santa-cruz.ca.us
-------------------------------------------------------------------------------