Information on seamless MMO server architecture

Question

I'm looking for any material on seamless MMO servers! I do have a few articles in the "Massively Multiplayer Game Development" books and "Game Programming Gems 5." Has anyone experience on that topic or knows articles about that?

I'm interested in "high-level views" as well as implementations. This might become the topic of my master thesis and I would like to find out how hard it is to write such a system, before I actually start the thesis. Right now I haven't decided which language to use, I'm thinking about Java or Scala. Erlang could be a choice, but I've never worked with that.

Note: Basic requirement would be movement. Any other gamesystems are optional and give "bonus credit."

Now for what I mean with "seamless server": I want so set up a server cluster where every node controls some part of the game world, with static boundaries. Players can now move from one end of the world to the other without switching an instance or hitting some "teleporter". I think WoW does that. In my back-end however the player transitions from one server to the next.

Answer 1

The main complexity in managing such a system comes from just how seamless you need it to be. As Josh has said, solving the problem handing off an entity from one server to another is a key part of the package.

This is not the only problem though - if entities across multiple servers need to interact as part of one operation you now have a synchronisation problem where each system needs data from the other side in order to proceed, but by the time that data arrives it may already be invalid. You can attempt to solve this by breaking the operation down into multiple messages with rollback capability if one side backs out, but as you've seen from Chapter 3.1 in "Massively Multiplayer Game Development", this significantly complicates any game logic that you have to do this with. Scala and Erlang help you get the messaging system right - they do not help you with the decomposition of what used to be a 10 line function into the many different messages and states you now need to track.

Obviously, this problem is not entirely new, and relational databases support this sort of problem by storing all the data centrally and letting multiple clients query and alter it as they need to, rolling back transactions where necessary. This gives you most of your correctness requirements but unfortunately imposes impractical performance problems as well as making game logic implementation awkward (since much of your logic is now written in database stored procedures). A different kind of database might provide a good solution here, especially if you're willing to trade away the reliability requirements that most RDBMSes provide.

Most professional games get around this problem by not even attempting it, by keeping the shard size small enough to put all players on one server, by splitting the world into parts that don't really interact (see the WoW example in the comments above), or by distributing the game across servers based on function rather than geography (eg. all combat happens on one server, all chat on another) so that there are no 'seams' to contend with.

Answer 2

I'm interested in "high-level views" as well as implementations.

Implementations are generally reasonably deeply involved and you probably won't see much talk of them here. The StackExchange software isn't well-suited to that kind of involved discussion, not to mention it would involve a significant investment of somebody's time.

I would like to find out how hard it is to write such a system

No more or less hard than any other system: it will depend on your requirements and the features you intend to drive. You can write trivial implementations trivially, but non-trivial stuff will of course be much harder. One of the bigger problems is that you probably won't have enough real clients to tell if your system actually scales to the "massive" level that WoW and other games operate on.

MMOs are not magical. Most of their technology is nothing special when taken in isolation, it's simply that a number of smaller, simpler bits of technology are combined very intelligently to allow for larger scale, connected parallel simulations of some shared world state.

I want so set up a server cluster where every node controls some part of the game world, with static boundaries. Players can now move from one end of the world to the other without switching an instance or hitting some "teleporter".

Essentially what you're talking about is simulation hand-off. This can be done quite simply and isn't necessarily an MMO-specific technology (peer-to-peer games tend to support all the same underlying mechanisms to implement host migration). The basic premise is to have each server understand the topology of the servers "around" it (specifically, a server for world node A must know about the servers for simulation-adjacent world nodes) as well as to define a buffer around which you consider a particular simulated entity "close" to an adjacent server.

When an entity enters the "close" buffer, you start reporting it to the adjacent server as well. Once the entity crosses the actual threshold, you send a message to the adjacent server with the full state of the entity and a message indicating that the adjacent server should take over the entity. Obviously you want this to be as reliable as possible.