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:
- XML over HTTP: A bit of bloat, but easy to implement in all cases.
- Custom protocol: Allows for a very streamlined protocol, but trickier to implement.
- 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?