[MUD-Dev] MMORPG/MMOG Server design

J C Lawrence claw at kanga.nu
Fri Feb 21 16:36:30 New Zealand Daylight Time 2003


On Fri, 21 Feb 2003 15:41:52 -0600 
Weston Fryatt <wfryatt at muuf.com> wrote:
> From: "J C Lawrence" <claw at kanga.nu> 

>>> What is the best design for an MMORPG Server?

>>> Single Massive server? The whole game run on one multi-processor
>>> machine with gigs of ram.

> The more I do my research.. The more it looks like a single server
> approach is just out for an MMOG.

Then define your abstraction points and interfaces so that they don't
care if they are all running on the same system, or across multiple
systems.  In the general case distribution is a provisioning problem,
which system design helps but doesn't decide.

  There are exceptions, for instance in the cases of components needing
  specialised hardware or software.  A very typical example is Oracle
  (or DB2 et al) simply requiring its own standalone non-x86 box for
  reasonable scalability and license-cost mitigation.  Why?  Because the
  DB is limited to the transactional rate it can sustain on a single
  system (as multi-system same-DB licenses are big-$$$) and getting that
  scalability often requires more RAM and more CPU's than you can
  affordably stick in an x86 chassis.  Ergo, you buy a big Solaris or
  AIX box to handle that end...  

But, that doesn't define that the DB runs on a separate system, it
merely defines that the DB must be able to run on a separate system, and
that your transports (ODBC, OCCI, whatever), are properly transparent.

>> Segmentation into "zones" makes for abrupt and very opaque zone
>> transitions.  This can be jarring to the player and requires careful
>> design and implementation to not expose exploit paths.

> This is the idea that I keep thinking about..

It is the most obvious and simplest to begin to implement.

> The users client will connect to a login server the login server just
> verifies the users account and assigned a session ID to this
> users. This session ID is also put into a active session table in the
> database linking session to this users profile.

> There will be at least 3 login server to help support redundancy and
> failover.

Don't define provisioning before you're defined implementation.  That's
backwards and will rapidly marry you to mindsets which guide you into
rat holes.  Provisioning design, just like solution design, is based of
requirements and the satisfaction of those requirements.  Its the exact
same process all over again, just with different constraints and
masters.

> Each major land mass will be a "zone" in the game world and managed by
> it own cluster of servers.  This cluster of server will manage the
> game logic, map data, presentation and other event local to this zone
> only.  Each zone will have its own independent database server.

That's one approach, sure, but why marry yourself to it this early in
your design process?

> Thanks alot again!!  

Welcome.

--
J C Lawrence                
---------(*)                Satan, oscillate my metallic sonatas. 
claw at kanga.nu               He lived as a devil, eh?		  
http://www.kanga.nu/~claw/  Evil is a name of a foeman, as I live.

_______________________________________________
MUD-Dev mailing list
MUD-Dev at kanga.nu
https://www.kanga.nu/lists/listinfo/mud-dev



More information about the MUD-Dev mailing list