[MUD-Dev] Next gen MUD wishlist

J C Lawrence claw at kanga.nu
Fri Feb 18 22:56:26 New Zealand Daylight Time 2000

On Sun, 20 Feb 2000 02:04:36 -0800 
Bruce  <bruce at puremagic.com> wrote:

> So?  If the commercial games support 1000+ players currently and
> can only be expected to support more in the future, any effort at
> an open source game engine should aim to supercede that.  We
> certainly plan on it.

  ObNote: I really don't think that 1,000 is a realistic inflexion
  point for scalability judgements with current architectures.  My
  guess (sucked out of my thumb) is that a better figure is around
  two to three times that before you start having to get interesting.

Assuming a non-simplistic text mode world, supporting a 1000+
players (and a suitably large and active environment to match) is
not difficult _if_ you are willing to dedicate a small cluster of
machines to the task _and_ are able to mandate their configuration
and use.  Such design decisions are typically not made in OpenSource
projects for the simple reason that the resources are not available
to develop, test, or roll out such products.  The alternative of
attempting to support 1000+ players on a single machine (current
market) requires some level of rocket science or significant corner

The question is:  Do you want to plan for the architectures that are 
available today, or what you think will be available in a couple

Its not an easy decision.  

My own figuring is that for a text based game (which tends to have
far simpler and less significant player state concerns as well as
lower internal IO requirements) you can currently easily support up
to around a 2,500 - 3000 player world on a single $9K machine.

Once you add any level of complex world rendering/physics atop that,
complex player states, and significant IO levels (and tracking
multi-level IO states with remote intelligent clients is
significant) -- all the things you start getting as side effects
with graphical world presentations -- it starts getting expensive
(and boy am I embarrassed by some of my early posts on the area on
the list now).  While its tough to get a real handle on the problem
scale without having designed and rolled out systems of that calibre
(is Rick Delashmit or Damion Schuster still on the list?), my gut
feel guess is that a three to four node cluster of 50 SpecInt nodes
would probably do just fine __if__ internal memory and internode
bandwidth were high enough (NUMA and/or NUMA type architectures are
only just starting to become atttractive in thsi space but are
certainly not cost effective for that small a problem).

My faint memory is that UO uses 5 node clusters of Sun Ultra 60's or
something similar.  UO were pretty well first on the block for that
sort of problem space.  I suspect that EQ and AC (outside of having
significantly different internal designas and in AC's case a
mandated platform due to MS involvement) being second on the block
may be able to get away with something a little lighter (tho AC is
attempting to solve a slightly larger problem in terms of load
balancing and seamless world presentation than either UO or EQ
(which will mostly hit their internal bandwith requirements rather
than raw SpecInt needs).

>> Hmm, okay.  I specified this mostly because I know everyone has
>> their own favorite scripting language, and that deciding on a
>> single language can be hard.  For instance, I might perfer
>> Python, but someone else want Mercury, Guile or Perl (or worse!)

There's always the simple approach: define a VM to which scripting
languages can compile their bytecode Jave has done this to good
effect with half a dozen or more language out there which compile to
JVM bytecode (I think NetREXX was the first after Java itself).  

> The core game engine is but a small piece of the pie.  

A well fleshed server (network handling, DB handling, etc) for a
text mode MUD that doesn't attempt to handle world mechanics has
little need of more than 20,000 lines of code and can be
accomplished in less than half (cf COOLMUD).

10K lines of not very intricate code is not all that big a problem.

> The game mechanics and everything needed to flesh out the game can
> be far larger.  

It is easy to have your world definition be an and order or two
magnitudes larger than the server.  What's the current stat on
lambdaMOO (whole thing, not just core)?

>> What would you suggest as good challenges to undertake?

> Read the list archives!

You are evil.

J C Lawrence                                 Home: claw at kanga.nu
----------(*)                              Other: coder at kanga.nu
--=| A man is as sane as he is dangerous to his environment |=--

MUD-Dev maillist  -  MUD-Dev at kanga.nu

More information about the MUD-Dev mailing list