I am about to make a turn-based game in the Monkey language (Cross-platform translator). The game will use the HTML 5 platform. This game will play online where players can match against each others (It can be a 2vs2 match). I recently reviewed a tons of solutions and i stopped on 2 of them. The good old XmlHttpRequest and the new one WebSocket which seem to be in a recommandation state from W3C which is rather good. There also another technology which i was interested which is PubNub, a push service. This service actually push messages to all clients connected and is really fast.. but this come at a cost later and is restricted in the number of messages you sent. By that i mean it cost you 15$ per month for 1000 connections and 1million message then +1$ for another 1 million and go on. There actually 3 actors, the client written in monkey (HTML5) the server written in C# because i know well the language and PubNub for broadcasting messages. The client will only send requests to the server and the server is relaying the messages to PubNub which in return send back to clients. I had two plan in head considering thoses facts :
- The game is written in HTML 5 but i may port it to other languages (Android as an example). I can't do that if i use WebSockets because i would have to get additionnals librairies to handle this and i don't want to invest more time in it. So i will focus on HTML 5 for now but porting it is alway an option.
- Its a turn-based game so yeah XmlHttpRequest seem to be suitable for this task but at which point ? If i have over 1000 connections sending requests will it be able to support it ? Each turn is an unique request but chat messages is also a request and private messages too, getting player data too (before you join any game) etc. An advantage over WebSockets is that Http Get are easy to make and is supported easily on many platforms so i could obviously go the Android route if i choose this.
- I don't want to invest more time in others technologies than thoses stated here.
- PubNub cost money in the end but it is very efficient for pushing messages so not using it might be risky and would force me to do the messages relaying code myself.
So here my 4 plans.
- Going with WebSockets and use Alchemy as a WebSocketServer for C# which i tested and work wonderfully and still have the PubNub actor in the backend for relaying my messages.
- Go with XmlHttpRequests and use a simple WebAPI for the request Gateway.
- Go with both. Make the client independent on which technology to choose. Use XmlHttpRequest as a fallback and make the server support both connection. PubNub will still be the relaying actor here which should make the whole stuff communicating.
- Go with WebSockets but without PubNub.
So which route do you recommand me to go and why ?
Thanks!
Take a look at http://realtime.co - Its a Realtime platform similar to PubNub and with more capabilities.