[MUD-Dev] Re: TECH: Distributed Muds

[Jim Craig]

> From: Emil_Eifrém <emil.eifrem at windh.com>
> On Friday, April 06, 2001 11:24 PM, Jim Craig wrote:

>> I've been working on a distributed java based mud.
  
> Why do you wish to distribute your mud? Do you anticipate such a
> high (player- or other) load that one machine can't handle it?

This may sound ludicrous but the ultimate vision is to bring realm
building to a larger base of people.  To date building, managing,
building a player base has typically been reserved for developers with
a lot of time on their hands, $, a place to host the world, and... did
I say time.  I think there are many people who would love to build,
run and operate a virtual world but getting there is usually somewhat
painful. Someone going from being a gamer to game operator is a
significant investment.

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. The effort is two-fold: 1. Tools & scripting
language for building world. 2.  Ability to plug world into existing
network.  A networked realm is attractive as it has inherent load
balancing and scalability, e.g. 10,000 users distributed across 10
worlds seems attractive:

- Great for worlds where the CPU utilization and bandwidth *must* be
kept light, e.g. cable modems, mom&pop ISPs - The code doesn't have to
be as performance-sensitive as a world that needs to support 10,000
users which usually means more features and lower reqirements as a
language (i.e. java instead of C). This contradicts the first point to
some degree I guess.  - Hardware requirements are lowered.  I'm
thinking Linux/NT instead of a honkin' (new tech term?) 4cpu Solaris.

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.

I don't know/care (ignorance and apathy in one :-)) if there's a
market for shrink-wrapped setup.exe virtual worlds but I woke up one
morning and just started coding it anyway.

>> There are numerous issues to deal with regarding > the persitance
>> of player data not to mention a slew of other issues.  I'm sure
>> I'm not the first person to run into these...
 
> Rather than persistance of player data, I think the real challenge
> should be to design and implement a framework for transparent
> distribution of your server. Once you have that in place, you
> shouldn't ever have to think about whether your objects are
> distributed over several machines -- it will be handled
> transparently by your server's backend distribution layer.

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. 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.

> Of course, if you choose to use an existing framework you're
> sidestepping that design challenge, but on the other hand you will
> have to learn a new (potentially quite complex, since it solves a
> complex problem) framework and how to program within it.
 
>> Does anyone know of any resources where I might be able to read up
>> on technical/architectural aspects, i.e. design patterns for
>> distribute worlds?  White papers, Web sites, etc?
 
> It depends on whether you've decided to go with J2EE or roll your
> own distributed framework using e.g RMI or CORBA. (I don't know of
> any other alternatives for a Java-based mud, but I haven't looked
> extensively into third-party frameworks for distribution.)

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.


> Roll your own:

> I suggest you pick up a good book on the topic.  > POSA2 is a good
> choice, at least if you're comfortable reading > C/C++ examples.
> Check it out at > [http://www.cs.wustl.edu/~schmidt/POSA]. Dough
> Schmidt has (IMHO) the best repository for CPD > patterns at >
> [http://www.cs.wustl.edu/~schmidt/patterns-ace.html].

> Also, I'm fairly certain that PLoP (Pattern Languages of Program
> Design) volume II covers some distributed patterns but since I don't
> have it here at work I can't verify that.

Thanks.  These look like a good place to dig in.

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