[MUD-Dev] Re: MUD-Dev digest, Vol 1 #286 - 13 msgs

[Dr. Cat]

-- Start of included mail From:  J C Lawrence <claw at kanga.nu>
> Subject:  Re: [MUD-Dev] Next gen MUD wishlist 
>
> 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.

This sounds like a very pessimistic assumption to me.  There's a text
based MUCK that I play on that regularly gets over 500 players online,
running a single machine.  It's not hard to imagine that it (or one of its
better managed rivals with a smaller DB, which gets nearly as many
players) could handle 1000 players on a single machine without needing to
go to a cluster.  Even if they needed to beef up a little from what they
run on now.  Of course I know this list many talks about the combat muds
as opposed to the social or the RP muds - I don't know whether Dikus or
LPs or the like use up a lot more computing resources than MUCKs do.  But
I seem to recall BatMUD getting pretty large numbers of users on a single
machine some years back.  Don't know what the biggest free combat muds get
for usage levels these days, but I heard a rumor that it's higher than the
top social muds now.  (In the early 90s I believe the top three in terms
of simultaneous connections were LambdaMOO, FurryMUCK, and PernMUSH - but
that's ancient history, back when 200 users online was a big deal.)

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

This might be accurate for more "typical" text and graphic mud servers, I
don't know.  I certainly know that there was one design decision made on
Ultima Online (one seamless world rather than a bunch of small discreet
linked maps) that I wouldn't dream of, and I know that 3D polygon worlds
have a bunch of overhead issues tile based worlds don't.  (Though I wonder
how many of them do things like conserving bandwidth by using dead
reckoning and only sending a packet when the client's expected prediction
will be too far form the actual correct position.)  But I certainly think
it's possible to run a graphic mud without the kind of muscle you're
talking about.  Especially if the game design is focused on efficiency as
well as playbility - and if you focus on just putting in the elements that
really do the most to make the game more fun, rather than throwing in
anything, so you can get away with a focus on efficiency without being
boring.  (Of course this requires you to be able to know which parts are
really the most fun, which is a rare skill.)

Anyway Furcadia currently has 432 players online, on a box that cost me
about $1800.  It's a P2-400 with 256 megs of RAM and two mirrored 9 gig
hard drives.  Right now the load average is around 0.66, and top displays
the CPU as ranging from about 30% to 60% idle.  Vmstat reports a little
bit of swapping.

The game has more major overhead issues that scale close to linearly at
this point than ones that don't, and I'm going to rework the main one
that doesn't in the next major architecture shift.  There are a lot of
game features yet to be added, but most of them won't add very appreciably
to the I/O or CPU or disk overhead.  I'm sure this box could handle over a
thousand users in a graphic mud with decent performance - if I added more
RAM it wouldn't surprise me if it could handle 2000 or 3000 users, maybe
more.  Won't really know till I try, of course.

To me it's mainly a question of whether efficiency is a major priority, a
minor priority given lip service and inadequate attention, or not even a
priority at all because "Ooooh, we can put in a bunch of Game Features!!!"
We used to handle up to 350 users on a Pentium 90 with 48 megs RAM.  I
consider high performance to be a virtue - especially if your upper limit
to the number of users might eventually be determined by some performance
bottleneck somewhere or other.  It's my understanding that games like
Everquest and UO can only have a few thousand people per world before they
need to go set up a second world, and a third, and a tenth, each totally
sealed off from the others in terms of interaction of game elements.  If
you're going to have a limit on your population at all, it should be as
high as possible.

Of course better is to have a very good distributed model, where you can
theoretically scale to any size by just plugging in more machines.  But
who do you think would be more likely to scale to support a million online
users in practice - a game that supports 500 users per server machine, or
one that can support 10,000 users per machine?  The more efficient your
system is, the better off you're going to be dealing with the inevitable
issues that arise when you try to scale huge and all kinds of new problems
pop up.

And we will see a day within our lifetimes when some game, or
"environment", or something, has a million people or more logged into it.
I want to be making environments of that scale - and I think I could do
it with today's levels of computing power.  It's just a matter of focusing
on the right priorities in one's design.

Mind you, I should admit that voice chat changes all the math, and that I
think voice chat will be ubiquitous and necessary to be a major
communications app or multiplayer game in the future.  And also I'll admit
that I don't have a feel for how much that's going to increase the I/O and
CPU overhead for servers.  So feel free to ignore everything I just said.

I do have a gut instinct that the future of voice chat is going to involve
a ton of peer to peer traffic, though, and not much more server traffic
than we have now, to enable people to locate each other initially.  Kind
of like ICQ and Napster.  I had an idea last year for a voice-chat startup
based on this and some other thoughts, but I decided I didn't have the
heart to play that whole cheesy venture capital game, mainly because it
involves a few years of making technology before the infrastructure is
there for it really to work well and smoothly, and telling everyone it
does anyway, and collecting the IPO jackpot based half on snake-oil and
half on the fact that your product may well be high quality a few years
after you've left, when it's really possible for such a product to be done
well.

I prefer working on reliable, smoothly performing, high quality products.
Call me old-fashioned - and call me not a millionaire yet, too.  But I'm
very happy with the things I'm making, and most of the players seem to be
too.

*-------------------------------------------**-----------------------------* 
   Dr. Cat / Dragon's Eye Productions       ||       Free alpha test:
*-------------------------------------------**  http://www.bga.com/furcadia
    Furcadia - a graphic mud for PCs!       ||  Let your imagination soar!
*-------------------------------------------**-----------------------------*



_______________________________________________
MUD-Dev maillist  -  MUD-Dev at kanga.nu
http://www.kanga.nu/lists/listinfo/mud-dev