[MUD-Dev] Re: TECH: Distributed Muds

[Colin Coghill]

On 09 Apr 2001 12:26:23 -0700, Jim Craig wrote:
 
> I trying to build a mud that allows someone to quickly get their own
> realm up and running, hook it into an existing network of realms,
> and start adding content to the networked realm with as little pain
> and setup time as possible.

This is exactly what I've been playing with over the last few weeks in
my spare time.  I've gotten as far as a couple of Python scripts to
handle the networking side of things - not much more yet. I'm using
Python because I'm just experimenting and it's a very quick language
for that kind of thing :)

> A networked realm is attractive as it has inherent load

> balancing and scalability, e.g. 10,000 users distributed across 10
> worlds seems attractive:

You still have to watch out for the flash-flood effect. A major event
in one realm (a wedding, a bug giving out free stuff, etc) can change
that to 9900 users on one world and 100 across the other nine.

> So the plan is to build a lightweight game engine with distrubted
> capabilities that can run just about anywhere. Then build a
> scripting language and GUI tools for adding content.  The last mud I
> built in 1992 was 90% coding 10% content.  I'm shooting for the
> inverse now. Not for myself but for others.

An excellent goal IMHO. 
 
> The particular problem I'm trying to work through has to do with
> player's moving from remote realm to remote realm.  All of the
> player & object state changes must be persisted to a database
> residing on the player's home server.

I was hoping to solve this by having a "gateway" server. This is what
the players telnet/connect to. (There could be many gateway servers,
as load demands) This is where their "permanent" details are stored.

The gateway also does basic command handling and passes the "clear,
condensed" version of what the player typed to the appropriate realm
server.

The gateway also handles recovering the player if a realm server dies
or loses contact.

> There seem to be numerous issues and race conditions that can occur
> during logins, logouts, jumps from one world

> to another, crashes, etc. a-la the days of duping characters in UO
> when crossing over server boundaries.

You also need to worry about the more game-world related effects.
Someone could code a horrible realm that basically zeroes all the
players accomplishments (perhaps by accident). Or maybe one realm
gives out far too much "loot" too easily.

You can do some basic management of this effect by maybe having a
gateway administrator who decides which realms to allow in their game,
but it's still a difficult thing to balance.

Carrying objects from realm to realm is also an issue that needs dealt
with.

> I'm going w/Java, UDP & proprietary messaging and potentially a JNI

> drop to C for socket mgt.  Wasn't too impressed with the overhead of
> RMI nor the complexity of CORBA.  While the game engine need not be
> as performance critical, the inter-server messaging layer need to be
> pretty snappy.

Yep, reducing the amount of information passing over the network to a
minimum is important too.


I was pondering a "world" of seperate realms, each loosely connected.
Perhaps a special portal or something between realms. Something the
player is very aware of.  I was also hoping to restrict the flow of
items between realms to ones that are trusted by the receiving realm.
When a player steps from Realm A to Realm B, Realm A would pass all
the objects the player is carrying to the gateway, which would do some
kind of backup-save, then pass them to Realm B and shift the players
connection over to B.  Realm B might go through the objects, disable
some of them, and maybe even convert some to objects more appropriate
for that realm. (Some simple digital signature type stuff would help
here)

If a realm crashes the player will lose everything they gained in that
one realm but no more.

It does require quite a rethink of traditional game design though. 

One that fascinates me.

- Colin



_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev