[MUD-Dev] Re: MUD Development Digest
cat at bga.com
Fri Apr 24 17:30:53 New Zealand Standard Time 1998
> Yet again it's one of your points that prompts me to actually post. Or mabie
> I just like picking on you. The world may never know. ;)
> But really, I see both sides of this particular argument. This is because I
> can invision a game where 10,000 or even 100,000 people can play the game on
> a single "server" (single world entity, don't pick my words apart, I know
> it's possible to have a game distributed. But that's an argument for another
My server has been intended to handle those kinds of numbers since long
before I even started coding it. With my current architecture, though,
there's only one component that needs to have information about all the
players currently online. My expectation is that it will have to be
rewritten with better and better architecture, hardware, etc. over the
years ahead as usage goes up by (hopefully) orders of magnitude. It is
the most failure-prone component of the system, and I'm certainly going
to stay open to using "fancy" data structures, database programs,
licensing something like Ichat's server that already does some of what I
need, or just plain hiring someone else to program it for me. :X)
Still, I think the map servers will stay very much like they are now,
will comprise the bulk of the processing that's going on, and provide
most of the fun. And I think my current programming philosophy is 100%
correct for them. The interface between them and the central server
process (or group of processes) will be kept as identical as possible
every time I re-architect that monster, so they shouldn't have to
change. And if the thing gets slow sometimes, they're set up to have all
the most speed-critical functionality (moving, talking to people around
you), while the central process has stuff that you wouldn't mind waiting
a few seconds for (list of which of your friends is online), and that you
can still play the game without even if the thing crashes and burns.
I think as the usage gets up into thousands or tens of thousands I'll
probably put an artificial limit on each local map, not allowing more
than a few hundred people on each one. Otherwise we'll probably have
"flash crowds" that'll make things break. I think my current code could
handle 500 on a map pretty cleanly already, though it hasn't been tested
above 80-90 or so. The real bottleneck with the current code is how much
I/O the machine it's on can handle, not CPU or disk, so the main issue is
getting it onto better server hardware than the current donated Pentium
> As a rule of thumb, on pretty much ANY O/S, you really don't want to have
> more than 1/3 your memory be in swap.
We are in agreement here, but I'd go farther and say zero percent is what
I really want. As J. C. pointed out, I may have to look around for a
Unix that doesn't assume things should be swapped out even when there's a
surplus of RAM - or at least one that can be tweaked to act that way.
> At the point where you exceed what physical memory you wish to use by a
> significant amount (without having to add anymore), you do need to start
> being smart about both how that memory is arranged relative to it's
> utilization and exactly what data you decide to keep in memory.
> This is where the 'fancy' memory algorithms come in.
This translates in my mind to "You are right, Dr. Cat, you don't need
those fancy memory management algorithms". As I mentioned in an earlier
post, it's my intention to make sure that I *don't* exceed the physical
memory, ever. I don't see any reason why I would have to. With a fixed
amount of memory allocated for each map server, and a fixed number of
servers launched on each machine, the memory usage can't "catch me by
surprise" and go over what I wanted it to, as it can on systems that
allocate stuff dynamically. More users and more player building just
means more map server processes, which means periodically buying more
machines for the network to stay ahead of demand. As for the cost of
RAM, (plus the cost of the CPUs, hard drives and other things that have to
be connected to that RAM to make it do anything useful...) Well, under
any business model that brings in any significant amount of
revenues-per-user, I can't see where it would be it being any kind of
problem affording plenty of RAM-per-user.
If I had any interest in setting up a game with thousands of simultaneous
users that generated no revenue, I'm sure I'd rush right out and study up
on all the latest data structures and memory management techniques. For
now I'll stay mostly with my old friend the array. Kinda like I used in
BASIC in 1978, only with more datatypes available. :X) They're not
elegant and beautiful and graceful like triple-sideways-linked-lists of
handles to structures... But like an old reliable car, or an old
reliable horse, they get the job done. We've got about 400,000 player
hours logged on our server now so far, and it's rolling along pretty
smoothly most of the time.
Dr. Cat / Dragon's Eye Productions || Free alpha test:
Furcadia - a new graphic mud for PCs! || Let your imagination soar!
P.S. The real trick is figuring out what parts would contribute the most
towards "making the game fun", and then *only* implementing those parts.
If you take any other approach, odds are good you'll never get your game
done - indeed, most people that try to make a game never do get one done.
MUD-Dev: Advancing an unrealised future.
More information about the MUD-Dev