What is the best architecture for multiple game servers that need to talk to each other?

Question

The game is a low graphic (SVG) strategic game. Each server represents a Game Domain with its players. All servers should be able to talk to each other, as players can move (in the game) from domain to domain/send "diplomatic messengers" etc..

We have chosen this idea as it enables us to enlarge the world map endlessly, it enables second parties to connect their game servers to us and those enlarge the world even more. If one server (and its backups) fails, the game will still continue to run (a real distributed environment).

We are only at the beginning. What are the platforms out there which we should look at, that will help us develop such a world?

Answer 1

XMPP, previously known as Jabber, might be a good place to start.

Answer 2

A lot of this depends on how much data you want to share between servers. You want each server to handle it's own domain, but what about account database, data about who owns what information, topography of domains, are these data going to be central and/or distributed and how do you keep them synchronized. So aside from the workings of the game, there is another set of metadata, which the servers need to communicate about. As for the game data, you will probably pass around events, data objects and information about data ownership and control. On top of this there has to be some in-game clock metadata to keep domains time synchronized.

I would probably use a system of asynchronous queues with different priorities for metadata, requests and response messages. Protocol like XMPP on top of exchanging messages can bring you presence information, authentication, encryption and other advantages. But at the start, the delivery protocol itself is not as important as the structure of the messages and the exchange of the data. In essence delivery protocols are interchangeable.

Example: One player sends a game unit X from domain A to domain B. Domain A server sends message with event to domain B server. While processing queue of events, B receives message and sends a requests to a request queue on A for data about unit X and permission to control/modify data of unit X. Request queue has higher priority and will be handled before other events on domain A. Domain A sends requested data and control token to domain B response queue with highest priority. Meanwhile domain B server already processed 3 other events, not waiting in session.

• Note: A should obsolete, version or remove data about unit X at this point. If a request comes for data from domain C, it should forward this request to server B from now on.
• Note: The above example can be optimized to send data about unit X directly with corresponding event, but I wanted a simple example to illustrate.

The important thing is that you will have to design the data encapsulation protocol, probably some XML schema. The protocol for event handling. List of events, allowed responses, error messages, recovery. Those are all game specific.

Answer 3

I'd seriously consider Erlang and CouchDB, or implementing it under Google AppEngine.

Answer 4

If it's truly distributed then I'm guessing there are no plans for a central server. That means that what you're really looking for is a communications mechanism between the various servers. REST and XML-RPC are both really simple mechanisms for the servers to be able to talk to one another to communicate that a user needs to move from one to another.

You could also use something like XMPP as Daniel said but that means you've got to hook another set of server software into the mix alongside whatever you've got running the game itself (which I'm guessing from your description is probably a web app server of some kind).

From a development standpoint, any language/framework that is strong for developing web apps should work. Ruby on Rails, Python on Django, numerous frameworks plus Java, or even Cake w/ PHP (ick) would work for the development work.

I've considered something like this in the past but the issues of vetting the various servers (i.e. how do you handle a server that is either broken or malicious and lets a player simultaneously move the same piece onto two or three other servers), dealing with dropped out servers (what happens to players who last existed there), etc. seemed very challenging.

Answer 5

I think the first question to answer is whether the game is real-time or event driven, and whether the client is the browser or not. It sounds like it's event-driven but remember that the server can't push results to a plain HTML client effectively, only to a Java applet, embedded Flash movie, etc. If you have a custom client then there's no need to use a HTTP-style system on the server, meaning server->server and server->client communication can be done in the same way.

Answer 6

You should have a look for "Interest Management" papers about p2p games, you will face really interesting approaches. Google Schoolar will present you really good papers.

But be warned, developing distributed applications is much much more complex than simple single-server-approaches.