[MUD-Dev] Re: MUD Development Digest

[Dr. Cat]

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

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 
100.  :X)

> 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:
*-------------------------------------------**  http://www.bga.com/furcadia
  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.