[MUD-Dev] Re: TECH: Distributed Muds

Vincent Archer 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 mailing list