Comments on: Patching the Game (Part III)

By: Game Retail Store » GameSetLinks: Gaming Stances For Victory!

Game Retail Store » GameSetLinks: Gaming Stances For Victory! — Tue, 28 Apr 2009 07:46:39 +0000

[...] Patching the Game (Part III) @ Imaginary Cogs A multi-part series on actually hosting MMOs in data centers – v.interesting. (Via Zen Of Design.) [...]

By: Brian 'Psychochild' Green

Brian 'Psychochild' Green — Mon, 27 Apr 2009 03:39:19 +0000

This was an interesting series of articles.

Meridian 59, being older, had a very simple system. On the server side, the gameplay code is in byte-compiled files generated from script. We updated the source on a build server, built the game, then let QA pound on it as appropriate. When it came time to patch the server, we dropped the new files into a “patch” directory and the game loaded up the new files automatically. It also changed the in-game representation of the objects as well during the update.

On the client side, we put all the files into an archive and then put them on an FTP server. The client automatically grabs the files and replaces them. We don’t have binary packed files on the client end, except for a special format for our sprites.

One thing I’ve been thinking about lately is just keeping it simple. M59 isn’t super-pretty, but the back end is pretty solid. It can hold servers with several hundred people on hardware that’s going on 10 years now. You don’t get “massive” shards, but the upside is that a team of 2-3 people could update the game and patch without many problems. Focusing on the “indie” side of things, this is valuable as well.

Some thoughts.

By: Eolirin

Eolirin — Sun, 26 Apr 2009 08:41:16 +0000

Have you looked at how Guild Wars handles patches? It seems like it would have to do most of things you’ve mentioned, at least in a general sense. The servers don’t come down for patches for instance, just a client message to reboot for an update, and new zones that the client hasn’t seen before are downloaded and then run without a client restart.

By: Bryant

Bryant — Fri, 10 Apr 2009 19:55:35 +0000

That’s a good point. Come to think of it, I remember Islandia’s connection manager back in the days of file descriptor limits. You’d need to cluster the connection manager for obvious reasons, but that’s not too bad.

Login servers could be connection managers or they could just handle the initial connection and authentication, then pass the client off to the destination server — Turbine’s login servers work more like that. Either way you have the same effect you’re describing.

By: Greg

Greg — Fri, 10 Apr 2009 19:21:37 +0000

You can avoid the need for a connection handoff protocol by using a connection manager. A process on receives many client connections, handles the authentication step, and then communicates with the game server over a single pipe.

At higher scales, the connection manager can be on separate hardware, allowing game servers to be rebooted without breaking client connections. You need some kind of handoff between the connection manager and the game server, but not on the client.

I think World of Warcraft may do this; sometimes the “login servers” are hosed while people who have current connections to the game are just fine. I don’t know if it has anything to do with hot-patching capability; they may just not want to be messing around with multiple client TCP connections in their game server code.