HTTP As Communication Layer for a Game

Question

I've just started dabbling in some game development and wanted to create a simple multiplayer game. Is it feasible to use HTTP as the primary communication protocol for a multiplayer Game. My game will not be making several requests a second but rather a a request every few seconds. The client will be a mobile device.

The reason I'm asking is, I thought it may be interesting to try using Tornado which reportedly scales well and supports non blocking requests and can handle "thousands of concurrent users".

So my client could make a HTTP Request, and when the game server has somethign to tell it, it will respond to the request. I believe this illustrates what some people call the COMET design pattern.

I understand that working at the socket level has less overhead but I am just wondering if this would be feasible at all given my game requirements? Or am I just thinking crazy?

Thanks in advance.

Answer 1

With the target platform being a mobile device (and the limited bandwidth that entails) HTTP wouldn't be the first tool I would pull out of the box.

Answer 2

WRT:

"my client could make a HTTP Request, and when the game server has somethign to tell it, it will respond to the request."

This is not how HTTP is supposed to work. So, no, HTTP would not be a good choice here. HTTP requests timeout if the response is not received back with the timeout (60 seconds is a common default but it would depend on the specifics).

Answer 3

Please read RFC 3205: On the use of HTTP as a Substrate, which deals with this.

Answer 4

If you just fancy playing with all this technology, then you could give it a go. Tornado seems like a reasonable choice, if the example on the web site is anything to go by. But any simple server-side web language would suffice for serving up the responses you need at the rate you have mentioned. The performance characteristics are likely to be irrelevant here.

The COMET method is when you leave a HTTP connection open over a long period. It is primarily there for 'server push' of data. But usually you don't need this. It's usually much more straightforward to make repeated requests and handle the responses individually.

Answer 5

Q: Is it feasible to use HTTP as the primary communication protocol for a multiplayer Game.

A. Using HTTP as a communication protocol may make sense for your game, probably not, but that's for you to decide. I have developed applications for Windows Mobile, Blackberry, Android and iPhone for just over 10 years. All the way back to CE 1.0. With that in mind, here is my opinion.

First I suggest reading RFC 3205 as Teddy suggested. It explains the reasons for my suggestions in detail.

In general HTTP is good because...

• If you're developing a browser based game - flash or javascript where you don't create the client, then use HTTP because it's built in anyway and it's likely all you can use.
• You can get http server hosting with decent scripting super cheap anywhere
• There's a ton of tools available and lots of documentation
• It's easy to get started

HTTP may be bad because...

• HTTP introduces huge overhead in terms of bandwidth compared to a simple TCP service. For example Omegle.com sends 420 bytes of header data to send a 9 byte payload.
• If you really need comet / long polling you'll waste a lot of time figuring out how to make your server talk right instead of working on what it says.
• A steady stream of http traffic may overload mobile devices in both processing and bandwidth, giving you less resources to devote to your game performance.
• You may not think you know how to create your own TCP server - but it really is easy.

If you're writing the server AND the client, then I would go straight to TCP. If you already know python then use the twisted networking library. You can get a simple server up in an hour or so just following the tutorials.

Check out the LineReceiver example for a super simple server you can test with any telnet client. http://twistedmatrix.com/projects/core/documentation/howto/servers.html