[DGD] DGD/MP & OpenMosix revisited?

Ragnar Lonn prl at gatorhole.se
Mon Feb 9 01:06:37 CET 2004


Hi everyone,

Some of you may know me ("Groo" on Genesis and IgorMUD) since old. I'm a
nowadays not-so-active mudder that works in a game development company,
developing games and network software of various kinds.

I'm interested in server clustering, like Kevin mentioned in the
"Multi-CPU support" thread late last year. I've always thought it a
shame noone has made a serious effort to marry the best of text-based
MUDs and modern MMORPGs to create something that would be as big a
step forward from what we have today as the step taken with the birth
of LPMUD. MMORPGs are hugely popular - did you know that the largest
one, Lineage, has over 4 million paying subscribers?  A community-built
MMORPG could be something really cool, I'm pretty sure of that.

DGD/MP sounds good but we also need some kind of clustering in order to
create really large game environments. For operational and cost reasons
you want to be able to host a service on many cheap servers, rather than
a single gigantic one. RAID-based storage is a good analogy. If DGD isn't
suitable to run with a clustering solution such as OpenMosix, what
alternatives are there?  What about creating a mudlib that does it?
Possibly with some slight modifications to DGD itself where needed. I've
had basically the same ideas as Kevin I think. I've been imagining a
system where you have an arbitrary number of game servers. Each server
maintains state for a number of game objects. You have an inter-server
call_other() function that lets an object on server A call a function in
an object on server B. Each game object resides on two servers but only
one server is authoritative - the other maintains as up to date a state
as possible for the object in case the first server goes down. Like
Kevin, I thought about master servers also. I think they might be good
to have. They can keep track of what servers maintain state for what
objects and they can also be responsible for assigning objects to servers,
both initially when an object is created and initiate failover when
a game server goes down. They respond to queries from game servers and
clients who want to know where to find objects.

I don't like the idea of dividing a game world into different areas
hosted by different physical machines. It is too static. I would like
to be able to e.g. do accounting on the inter-server call_other()
calls, and migrate game objects between servers depending on their
inter-object communication patterns so that objects that call member
functions in eachother a lot will reside on the same server. The goal
is to minimize the number of inter-server funtion calls as they are
slow and resource-consuming. Where objects are hosted will then change
over time and adopt the least resource-consuming model.

Wouldn't it be nice to do away with "shards" and similar workarounds
and have a truly expandable game for once?

  /Ragnar

_________________________________________________________________
List config page:  http://list.imaginary.com/mailman/listinfo/dgd



More information about the DGD mailing list