7

I noticed I'm getting tired of trying to make games with high level programming languages like C#, using OpenTK. C or C++ stills looks a little out of range for my humble self. I just got the sudden urge to get back to some web development and try to make a browser game - in pure HTML5+JS of course!

And while I think I can figure out the canvas myself sooner or later, with the help of ze internetz, I just don't quite know how I should handle networking.

WebSockets seem interesting, but are they the right way to go, seeing as they're still pretty undeveloped? AJAX sounds a little slow and bulky. I don't plan to make a game that requires very low latency, but I do want to keep it low enough to play smoothly.

What would you suggest?

copyboy
  • 115
  • 2
  • 7

6 Answers6

3

I think what you are looking for is the comet technology which is used to implement server push technology. You can find more information from following links:

http://en.wikipedia.org/wiki/Comet_(programming)

http://infrequently.org/2006/03/comet-low-latency-data-for-the-browser/

Khez
  • 10,172
  • 2
  • 31
  • 51
xiao 啸
  • 6,350
  • 9
  • 40
  • 51
3

If latency is not a big issue then you should probably just use one of the many good AJAX/long-poll libraries.

WebSockets will get you the lowest latency browser communication. WebSockets is actually fairly universally available because their is a WebSockets Flash emulator web-socket-js that can be automatically loaded if native WebSocket support is not found. Using web-socket-js emulation will have higher latency than native WebSockets but still lower than AJAX/long-poll.

In terms of WebSockets availability, native WebSockets (version 03) is supported by Chrome and Safari. Version 03 is also supported by Firefox 4.0 and Opera 11 but is disabled by default. WebSockets is also support in iOS natively since 4.2. I'm in the HyBi (WebSockets) working group and the next iteration of the protocol that addresses the security concerns from Mozilla and Opera is getting very close. Mozilla and Opera are actively working on implementations so I expect that at the latest the next major releases from them will have WebSockets turned on by default. But even so, the the Flash fallback and iOS support, WebSockets is available pretty much everywhere today.

If you are willing to do Javascript server-side too, then I would recommend Socket.IO. It is a node.js backend plus a client side JS library. It defaults to WebSockets if the browser supports it, includes the web-socket-js Flash fallback, and can use long-poll if the WebSockets connection doesn't work for some reason (or you choose to disable WebSockets as a transport).

kanaka
  • 70,845
  • 23
  • 144
  • 140
2

Perhaps you might read up more on different options. Google will provide you with research material.

Depending on the amount of data exchanged between server/clients, socket.io seems good enough for up to 10 updates/second for up to 100 people. Mind though that even Javascript will introduce alot of overhead, people that create networking code in C++ still complain about connectivity and speed issues even when using highly specific approach (data packing, tcp/ip packet caching etc).

Community
  • 1
  • 1
Daniel Protopopov
  • 6,778
  • 3
  • 23
  • 39
2

If you want to stay with only HTML5, WebSocket is a very interesting technology especially if you need your data to move as fast as possible. It's the only technology that will allow you to stream data in both direction with the server. If your game doesn't need to have update as soon as their are available Ajax is enough.

Also you need to ask yourself what browser you want to support for your game. WebSocket is not supported by all browser.

If you are open to other options, it is possible to do P2P connection in the browser with RTMFP in Flash. This allows you to do all the "client to client" communication directly instead of passing by a server to retransmit the data. It is in Flash, but it's possible to bridge that functionnality so that you have all your application logic in Javascript. This technology allows to pass more data around without overloading your server, but the big downside is the support. Flash is not well supported on Unix platform and it's a 3rd party plugin.

HoLyVieR
  • 10,985
  • 5
  • 42
  • 67
  • Heh, to be honest, I don't quite know why your answer got upvoted instead of one of the others. I explicitly said I wanted to go for a pure solution and otherwise it didn't contain a lot of information that I didn't already know. No offense, it's not a bad answer, I just think the other answers were more helpful. – copyboy Apr 15 '11 at 12:50
  • @copyboy Well if you think the other one where more helpful to you, you can accept one of them. That's what accepting an answer is for. – HoLyVieR Apr 15 '11 at 14:21
  • @copyboy if you think the other answers are more helpful, then as Jobs says "You are doing it wrong". The sooner you get to grips with NodeJS and Socket.io the better. – PaulM Apr 18 '11 at 00:08
1

I would suggest Ajax. The key to networking in online games with HTML5 and JavaScript is to minimize the traffic to the server (as with any other web application) so all you have to do is find a way to do that. What type of game do you have in mind, exactly? Does it strictly need a constant internet connection?

Even so, Ajax is neither slow nor bulky. It's just as fast as any other internet connection in any desktop game.

Ry-
  • 218,210
  • 55
  • 464
  • 476
  • I've done something with Ajax before - without any library. I think the largest problem is that I have to queue up events which are all going to be sent to the client once he requests them, attaching his actions to that request. It doesn't **feel** right. – copyboy Apr 15 '11 at 12:56
  • Ajax IS slower than other connection since when you do an Ajax request all the HTTP overhead comes with it even if the amount of data you send is minimal. This is true for when you send data from the client to the server. The only thing with Ajax that is as fast as anything else is Ajax streaming (from the server to the client). – HoLyVieR Apr 15 '11 at 14:27
  • It may be slower but it is not slow. – Ry- Apr 15 '11 at 19:19
  • I would have down voted this if I had sufficient rep. Doing this with AJAX is the worst. The best option is to use NodeJS. – PaulM Apr 18 '11 at 00:05
  • PaulM, the question contentrated on the client(browser)-side of the game -- if I understand Node.js correctly, it is a server-side application -- so AJAX-bashing might be okay, but Node.js is not the correct answer, or how did you mean it? – Dr. Jan-Philip Gehrcke Jun 12 '11 at 22:53
1

for the networking code you might want to try working with an existing framework like union platform. here's a multiuser drawing app written in pure js/html5 without websockets:

http://www.unionplatform.com/?page_id=2762

it's also worth looking at www.socket.io. socket.io provides a raw websocket wrapper with xhr failover, but no higher-level apis (e.g., no rooms, no users, no accounts, no data sharing/management for things like scores, etc).

colin

colin moock
  • 1,038
  • 11
  • 15