The Problem of Shards, Servers, and Queues In MMOs

An editorial at GamesIndustry takes a look at a couple of problems many MMOs have failed to solve as the genre has evolved over the last decade: log-in queues and a split player base. The most recent example is Aion, which launched in Europe and North America a few weeks ago. Players on some of the game's servers had to deal with lengthy queues until enough people left the starting areas and spread throughout the game. To NCSoft's credit, the queues are mostly gone already, and it wasn't simply launching with too few servers that was the problem (nor was simply launching more servers a perfect solution, as Warhammer proved). In fact, several servers had no queues at all, but many players had set their sights on the more popular ones — a problem facing other MMOs as well. At this point, it becomes a matter of programming — how can the developers for these MMOs build the networking aspect of the game such that more hardware can easily be allocated when it's needed, and also make it easier for people to play together without the restriction of different shards or servers? EVE Online has done well with a single game universe, but it's not clear how far that model can scale upwards.

Comments

Eve online runs Windows Server

[DAldredge]

http://www.microsoft.com/casestudies/casestudy.aspx?casestudyid=4000002990 Just FYI

Re:Computational Problem

[Bat Country]

This fellow was inadvertently correct. Representing space (volume) by putting sections of it onto single computers is a bad idea. Inevitably, no matter how good your design or how well-ordered your content is, some areas are going to become more popular than others. Hence, you're going to get congestion.

A much better model is representing player (and non-player) actions as work units then distributing them evenly across a network of linked computers then getting an integrated result for each "region" (zone, map, city, whatever) each server frame. Make the server frames something like 50 frames per second and have player actions lag about 2-3 frames behind server-side action and you'll see little delay on the client machines but help mitigate potential race conditions between player actions (both players simultaneously attacking and reporting that they attacked on server frame 2,348,342 and both score a fatal blow on the other).

To mitigate player lag you can distribute update packets based on the density of the update vs the distance of the events from the player vs the player's average data rate.

Of course, that's just my two cents.

Why not go fully peer-to-peer?

[Richard W.M. Jones]

We designed a "peer-to-peer" MMO many years ago, although I have to say we didn't implement it and the devil is definitely in the implementation. Anyway, you can read the design docs here. After it was clear we weren't going to write it, I published the docs just to give a priority date (1998) to invalidate any stupid patents ...

Rich.