[MUD-Dev] MMORPG/MMOG Server design

[Weston Fryatt]

From: "J C Lawrence" <claw at kanga.nu>

Wosh! I never expected a detailed reply like this! Thanks!

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

>> Server Groups: A group of servers runs a sub-set of the game
>> world with a max user count of 2000. Each server group would be a
>> unique part of the game world.

>> Redundant Servers: Multiple Servers doing the same job all
>> persisting the game world/game state into a common database
>> cluster server. Each server has only a specific task. (ie: map
>> server, login server, game logic server, npc server, etc) You may
>> have 10 map server running, 35 game logic server, etc running.

> In the typical clustered server case the cluster is not
> homogenous, but rather several are specialised.  Typically there's
> a connection proxy which handles all user connections and
> represents them internally to the currently appropriate internal
> box.  Then there's authentication, billing services, CMS and all
> the rest of that crap which usually take a box or three.  Behind
> all that you have something that is "running the game".  Within
> that space there are multiple approaches, all with large
> tradeoffs.

> A common approach is to segment the space.  Breakdowns I've seen:

>   -- presentation, logic, backing store
>   -- geographical segmentation of the game world into "zones"
>   -- player processing, automation processing, backing store

> Segmentation of the backing store away from processing leads to
> high transactional rates, and coherency issues should multiple
> nodes attempt to process the same data.  Resolving those problem
> can rapidly lead to code and design complexity.

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

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.

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.

> On the homogenous back end cluster side there are several
> different approaches, each with tradeoffs in hardware expense,
> code complexity, etc.  You can go for SGI-style CC:NUMA clusters
> with fully virtually VM and CPU resources such that processes and
> VM blocks freely migrate about the cluster according to your load
> distribution algorithms.  Without significant support from your
> system vendor and an experienced development team this can be
> expensive and difficult to get right, but works beautifully when
> it does.

I couldn't even begin to afford something like
this... Unfortunately, the server side is going to have to be x86
based. At least this version.

> Figure out your requirements.

> Figure out what you're doing first, then design to satisfy those
> requirements.  Architecture is almost entirely a question of
> context.  A decent way to approach that is to start out by list
> system behaviours.

>   The system must....<something>

> Segment that list into three sets:

>   1) The project is dead if it doesn't do...

>   2) The project is devalued if it doesn't do...(and define the
>   impact in detail)

>   3) The project is improved if it does... (and define the scope
>   and bounds of the improvement carefully).

> Fight hard to have an empty list for #1.  It never will be empty
> (or you don't have a job), but try and make it empty.

> Now try and make #2 even emptier by pushing things into #3.

> Repeat aggressively.

> Figure out the absolute minimum architecture that can handle #1
> (ie the one that requires the fewest decisions, the fewest
> definitions, the fewest control points, etc).  > Work over it a
> few more times making it simpler.

> Now go back and see what you can migrate from list #1 to list #2,
> and then work back over your architecture again.

> Repeat until it hurts and all your sentences defining the
> architecture are very simple and contain as few adverbs and
> adjectives as possible.  Keep going until your paragraphs are as
> short and obvious as your sentences.

> Review that against your list in #2 and see if you can't make your
> approach even cleaner by accomodating items from that list.  It
> sounds counter-intuitive, but it usually works that way.  A
> frequent sign for me for when I hit the sweet spot with a design
> is when my design definition suddenly collapses both in volume and
> complexity while the feature set rises dramatically.

> Try and shove as much as you can from the #2 list into #3.

Wow, This is great!  I'm going to have to get with my team.. and
work out a list like this and see what we can come up with!

Thanks alot again!!
Weston Fryatt



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