I've been investigating how multiplayer online games work. What I've found is that many simple games are flash based. So, to play them, you've got a flash app running in your browser, communicating with a web server presumably via http sending something like xml back and forth. This seems inefficient.

What I'm curious about is more sophisticated games -- desktop games, with multiple players, communicating with a central game server.

Perhaps the standard way to do that is to use http with mod_perl (or FastCGI)... I don't know. How is this sort of thing usually handled these days?

In general, they follow the old client-server model because of the need to have a custom protocol for updating the graphical elements. This generally entails some sort of half-model-plus-protocol that replicates most of the model information on the client. This allows the server to send very little information to the client for a large effect on the client. Having written one of these in AJAX, this takes either
• A large amount of duplication of effort across two languages
• Two completely different applications that both speak the same protocol
Neither of these is simple to maintain. This is why those MMORPGs suck, have few features, or have a monthly cost.

---

My criteria for good software:

1. Does it work?
2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?

This is why those MMORPGs suck, have few features, or have a monthly cost.

Or all of the above :)

---

I'm a peripheral visionary... I can see into the future, but just way off to the side.

This generally entails some sort of half-model-plus-protocol that replicates most of the model information on the client.

Ok. So, I'm guessing that means maybe something like:

player:position_x=120;position_y=83;orientation=52.2
...
[download]

and so on for other objects or events in the game (though probably in some more condensed format).

Having written one of these in AJAX, ...

Just curious: what format did you choose for sending your data back and forth? XML? Plain text? Something else?

Network protocols for actions games are going to be heavily affected by the demands of the game environment in a way that makes them poor choices for other applications. For example, action games are very concerned about latency and about minimizing network traffic in general. That will lead to very compact binary protocols that are difficult to write and torture to debug.

For other network applications -- a shared spreadsheet, a turn-based strategy game, etc. -- those issues are less of a concern, so an easy and widely-used approach like XML over HTTP makes a lot of sense.

Although I've never written one, I'd guess that modern MMORPGs are commonly written as multi-threaded daemons in a low-level language like C++ with some kind of higher level "scripting" language built in for implementing most of the game functionality. This is very similar to a mod_perl or FastCGI setup where you have a daemon (the web server) handling all of the tricky network stuff and you build the high-level functionality in perl.

If you specifically want to know about certain games, I bet you can find details about their implementation and protocols with a little Googling. The developers usually give interviews with at least general information.

For example, action games are very concerned about latency and about minimizing network traffic in general. That will lead to very compact binary protocols that are difficult to write and torture to debug.

Ah. Ok. You're ringing a bell for me. I bet these sorts of games would use UDP (rather than TCP) also. So for these, you're looking at using Socket or IO::Socket.

Also, your observation about modern MMORPG's with scripting being similar to apache/mod_perl/perl sounds right on. Thanks.

The reason they're flash based and run in a browser is because that way you don't have to develop a client side application. Anyone, from anywhere, with any kind of flash compatible browser can play. It may be inefficient, but it's universal.

For the more sophisticated games, you need to create a client application. Users have to trust you enough to download and run your client software. Given what's on the net these days, that can be a hard sell (who's to say your client isn't another spyware app?). Then you have to support the client, running on who knows what hardware, with who knows what version of operating system, etc, etc. Some users will be excluded from your game by way of what computer they use (Mac, Windows, Linux, other). All in all alot of extra work that takes you away from your real goal of making the best darn game server you can.

Communicating over the net doesn't have to be http. You can use any port and what ever communication scheme you want over a bog standard TCP connection. The client doesn't have to be a browser, the server doesn't have to be a web server, and neither of them have to follow a valid HTTP protocal. If you're not running the client from a browser, then there's no reason to use HTTP, but it does have one particular advantage in that it usually won't be blocked by firewalls (the port that is).