Server-client communication: Quick and verbose or involved and compact?

Question

TL;DR: Does the short development time required for HTTP/XML offset its size issues compared to developing a custom protocol?

As some of you might have divined; I'm currently working on a turn-based strategy game of the massively multiplayeriffic variety. The target turn-length is anywhere from 6 hours and up, so synchronization will be, on the whole, a bit easier than, say, an FPS or an MMORPG.

The issue then, is how the clients connect to the server. As I see it, I have basically two options: HTTP using some manner of XML exchange, or direct socket communication using some arcane protocol.

Because casual gaming is the "big thing" nowadays; the idea is that the game will be the sort of game where you can pick it up, play for 5 or 10 minutes, and then put it down and come back the day after; an approach that would greatly benefit from having the communication be stateless (as in HTTP).

On the other hand, target devices include the iPad and (perhaps) other mobile devices down the road; any protocol used would probably benefit greatly from being compact, if not so much for the speed (see above), but more in order to not cost the user everything he has if he plays on the road using cellular data networks.

On the gripping hand; using HTTP as the basic communication protocol greatly facilitates the creation of a web-based client.

All of this leaves me, as far as I can see, anyway, with 3 options:

1. XML over HTTP: A bit of bloat, but easy to implement in all cases.
2. Custom protocol: Allows for a very streamlined protocol, but trickier to implement.
3. All of the above: Small protocol for application clients; big protocol for web clients, increases implementation complexity and maintenance time required geometrically.

Does the short development time required for HTTP/XML offset its size issues compared to developing a custom protocol?

Answer 1

Do some back-of-the-envelope estimates: how often does the game state change? How often is this change communicated to the clients? How much data is communicated each time? For a turn-based strategy, I guess, you'll have only a handful of updates, but each relatively big in terms of data.

If I'm right, then you're not going to save much traffic with a custom binary protocol: you'll shave off a little from each packet, but since there's not many of them, savings won't add up.

In any case, you should try to completely separate your game logic and communication layers. That way, you'll be able to swap custom binary protocol with HTTP and vice-versa without much trouble.

Answer 2

If you use a modern database such as couchdb you will get a way to store your game state and get the syncronization basically for free.

It also works using a javascript interface, so it should blend well with your HTML5 app.

EDIT: I forgot to mention- the client-server communication happens in JSON, which is less verbose than XML but equally expressive.