Take the 2-minute tour ×
Game Development Stack Exchange is a question and answer site for professional and independent game developers. It's 100% free, no registration required.

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?

share|improve this question
1  
This depends entirely on a host of other requirements. As it stands now, this question is far too broad to be answered accurately. –  Justin Skiles Oct 8 '12 at 0:44
    
It's broad, but I wouldn't say "far too broad". I think I made a decent answer out of it. –  Ricket Oct 8 '12 at 2:06
    
Sure it depend on the host and requirements but this question is not related about the hardware but more specifically the performance side of the technology. –  Rushino Oct 8 '12 at 3:18
    
Websockets are nice on the bandwith if that is something you are going to take in consideration. just my 0.02€ –  Valmond Oct 8 '12 at 9:11
    
I decided to go with websockets just to be sure even if they are overkillbut there another reason too its because i don't want the stateless nature of HTTP. Cause later it won't be the time to go back. –  Rushino Oct 9 '12 at 0:56
add comment

4 Answers 4

up vote 5 down vote accepted

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.

share|improve this answer
1  
You must be good in chess if you need sockets for a smooth gameplay. –  Markus von Broady Oct 8 '12 at 6:59
1  
Or really bad :) [at the time I wrote this, I was talking about if you're bad at it so you just take turns without pausing for thought; it's a lame joke in retrospect] –  Ricket Oct 8 '12 at 12:15
add comment

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.

share|improve this answer
1  
"I would not use Comet" - why? And isn't 'Kaazing' actually a comet with sockets interface? –  Markus von Broady Oct 8 '12 at 21:08
1  
Indeed, please explain. If it's good enough for Google and Facebook, why wouldn't it be good enough for pretty much anyone? –  Ricket Oct 9 '12 at 12:26
1  
Its not a question of good enough. Websockets is the solution that all Comet solutions will all eventually migrate to, why use a technology thats on its way out? For websockets there is a difference between emulation and fallback. Emulation is switching to another technique that emulates websocket functionality. Fall back is using comet or another technique to make the appearance of using websockets. Kaazing uses a proprietary emulation strategy. When compared to comet, the emulation means less bandwidth and less response messages. This also generally means a speed improvement over comet. –  DPW_SPOON Oct 10 '12 at 21:52
1  
The thing is, sometimes you can just use HTTP request, instead of using some abstraction layer framework and be dependent on it. (security updates, migration when frameworks support ends etc.) And while HTTP request is an old solution and simply works, as well as Websockets, the framework may turn out to have additional problems. –  Markus von Broady Oct 11 '12 at 9:12
1  
I completely agree that its important to choose a service that can meet your needs now and has a strong likelihood of being very successful in the future!! I can't speek for for other companies, or officially for Kaazing, but I can say that if you look at kaazing list of current customers and collateral its quite impressive ;-) –  DPW_SPOON Oct 11 '12 at 18:34
add comment

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

share|improve this answer
1  
This looked really interesting at first, but if I understand it, developer is forced to use a Lightstreamer server? –  Markus von Broady Oct 10 '12 at 15:30
    
Yes, the core of this technology is the Lightstreamer Server, which sit along your Web Server (does not replace it) and takes care of all the real-time communication. –  Alessandro Alinone Oct 11 '12 at 9:05
add comment

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.

share|improve this answer
    
Maybe Google and Facebook don't migrate to websockets, because they worry more about logic, than communication layer :) –  Markus von Broady Oct 10 '12 at 15:34
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.