[MUD-Dev] Re: TECH: Distributed Muds
archer at nevrax.com
Wed Apr 18 10:40:12 New Zealand Standard Time 2001
According to Derek Snider:
> A distributed zone design should be set up so that each "zone" is
> the process that handles all the NPC's and ongoings in that zone, so
> that there does not have to be one massive process handling
> everything going on all over the entire world.
Ooops. Maybe I wasn't clear. So, to be precise, there are now 128
(hmm, interesting number) zones in EQ, and each is managed by one
single process, for a total of 128 distinc processes. If I remember
right, these processes are distributed over 14-15 quadri-processor
boxes. So each processor runs 2 or 3 zones only.
> A zone should not necessarily be designed to handle a certain
> capacity of players. It should be designed to handle a certain
> capacity of NPC AI and related events.
> If you have a game that you expect to handle 100,000 players, and
> you have 500 "zones", you cannot expect that each zone will have a
> maximum of 2,000 players. If you want your game to handle 100,000
> players, you'd better make sure each zone (especially starting
> zones, hometowns and popular locations) can handle at least 25% of
> your game capacity
Hmmm, no way. If you do so, you waste a lot of capacity. Since you're
running on a distributed system, you cannot lend one spare processor
to another zone - well, not in a geographical discrete model like the
one outlined above. So you end up with processors that remain idle 90%
of the time, but can support a population 10 times bigger than what
you usually have.
> Ideally you'd have a system set up where you have network management
> servers that handle little more than authentication and network
> connections. Basically you'd have a bunch of boxes that accept
> connections from the outside world on one network interface, and
> stream concentrated packets to and from the zone servers.
> Player0001 <--------> +---------+ <======> [Zone-Server1]
> Player0002 <--------> | Auth/ |
> Player0003 <--------> | Network | <======> [Zone-Server2]
> ... | Server |
> Player1000 <--------> +---------+ <======> [Zone-Server3]
Wasn't that UO's model? If I remember right, UO had two tiers of
systems. One was managing the player (who connected to an available
player box), which then in turn communicated with a bunch of
(rectangular) world zones.
But they had enough bandwidth that a 2nd network interface was
unnecessary, and they ended up using the same network card for
Player<->FrontEnds and FrontEnd<->Zone connections.
Vincent Archer Email: archer at nevrax.com
Nevrax France. Off on the yellow brick road we go!
MUD-Dev mailing list
MUD-Dev at kanga.nu
More information about the MUD-Dev