My game will be a turn based game which will need a server gateway in order to send requests. What would be better for the server: using REST HTTP GET for making the requests? Or using WebSocket which enables you to have an active connection?
|
|
If you need an active connection and literally real-time gameplay, then go with WebSockets, or a similar technique like Comet. Note that WebSockets requires a recent browser, while Comet is probably good enough for most purposes with better support for older browsers. For example, Facebook and Google use Comet for their technologies (Facebook Chat, Google Docs, Gmail, etc.). If you don't need this, then you can choose plain HTTP. It's probably easier to develop, but you lose the real-time nature of a constant connection. In this case, "turn based game" is not enough information. A turn based game like Draw Something is only going to have a few turns per day in an average game, so you could probably do just fine with plain HTTP, polling occasionally. A turn based game like chess, you'd probably want to have a little less latency, so I'd probably choose Comet. For some sort of action turn-based game, you might want the real-time nature of WebSockets. |
|||||||||
|
|
Websockets are definitely the way to go. There are indeed solutions out there that allow you work with websockets smoothly and very fast. A couple were already addressed here and I work for Realtime.co. One of our priorities was precisely providing developers with a way for them to start working with this new technology (with fallbacks, of course) in a very easy way. You can actually start developing in less than 10 minutes. You should worry about your game logic, not your communication layer. I wouldn't go with comet either right now. Websockets provides you with so many advantages with much less latency and it doesn't force you to hammer your server with constant connections, queries, etc.. There's no reason for developers not to start looking at the websocket-based frameworks out there very seriously. As to why we should use websockets when Facebook and Google are not. Well... I'm sure they are working hard to change this as it offers them the ability to provide a much better service with a much, much lower maintenance cost. |
|||
|
|
I would not use Comet for any new development projects. There are websocket providers out there that provide websocket emulation or fallback for older browsers. Kaazing is one and full disclosure I work there, but there are others that will automatically do the fallback for you. And those (like Kaazing) that do it properly, will still provide speed benefits much closer websockets. |
|||||||||||||||||||||
|
|
You should go for a Real-Time Web solution that completely abstracts from the underlying transport (WebSockets, Comet, etc.), giving you the guarantee that it will work on every possible browser and on the top of any possible network connection (mobile, unreliable, with unpredictable bandwidth, etc.). As the CTO of Lightstreamer, I suggest you to take a look at our solution, which has been around for 12 years, incorporating new standards and techniques. Originated in the financial services field, it has now been adopting by the gaming industry for many new projects. http://www.lightstreamer.com |
|||||||
|