Viability of Real-Time Multiplayer in HTML5

I am currently concerned with the current status of HTML5 real-time gaming.

For instance, I've made a few prototypes using TCP websockets, and I ran into two major deal-breakers:

The first is lack of UDP support - since I can't get rid of sequencing and delivery assurance, this some times means some of my players get badly out of sync, since they're stuck (some times for as much as 500 ms) waiting for packets that contain outdated information. Apparently there is no discussion regarding this in the living standard, and it's stuck in the stone age. There used to be an experimental extension in the dev version of chrome that could enable UDP sockets here, which was available a month ago, but it has since disappeared - which should reflect the instability of the whole scene.

UDP is absolutely essential to real-time gaming, and it seems to be completely ignored at the moment in the specs.

The second is the suspension of the game process when the window loses focus. This appears to be impossible to bypass, and creates a series of problems for multiplayer: mainly that players get badly out of sync once they become unable to process received messages in time. I don't know if this is a problem with the websockets extension, or if the game loop itself is affected.

Does anyone have more information or possible solutions concerning these issues?

I'm afraid I also ran into these issues and was forced to abandon the project, or at least suspend development on it. After hours of searching, I found no solution to this issue.

Fingers crossed someone can shed some light on this topic.

Look for WebRTC, an API primarily aimed at video/audio chat but that will allow to also send any type of data in a p2p way.

It's not there yet, but it is in development.

For your second issue, I'd suspect that the process of the game itself is frozen when the tab has lost focus, and so the websocket can't produce the Ping/Pong. I guess it's part of the standard itself.

A workaround could be to warn the player to not change tabs when they are playing, and if it happens, "intercept" it with the Browser trigger "On suspended" sending a "Self-kick" message to your server and a "rejoin" message "On resumed".

Handle a sort of pause for the player's entity in the current game, without needing to keep the connexion alive.

You can set a timeout period on your server for the entities which were "paused" for too long, or when the current game is over.

When the player joins again ("On resumed") activate the connexion again and place the entity into play again.

I used juantar's excellent plugin (based off Zack0Wack0's) to create my prototype, and also followed juantar's tutorial to make my node.js server.

It was very disappointing because I was getting huge lag spikes and desyncs in localhost, with only two players in separate windows, and it's not an issue with my server code or my logic, since I redid the prototype in MMF2 (while keeping the server written in node.js). The lag issues there were still present, although a lot less due to it being raw TCP sockets instead of websockets. I was able to compensate for lag with some dead reckoning in MMF, and the game appeared to be completely playable even with ~300 ms latency once I put in UDP.

Construct is a lot more enjoyable to work with, especially since you can hook up debuggers and inspect traffic flow without having to resort to wireshark, and the fact that you can jump straight into the code (thanks to the SDK) if you need something more complex.

The issues don't appear to be construct's fault, though I have a slight feeling that socket.io "message received" events either aren't triggers (I haven't checked) or triggers are affected by chrome's policy of slowing down inactive tabs.

In any case, multiplayer of any kind seems like a no-go in HTML5, since even having a window pop-up in front of chrome causes it to suspend your thread and make the player lose sync.

Artillery claims to have made a playable air-hockey game, which would be ideal, however they seem to have ran into the same issues regarding the lack of UDP support. Researching the web I've found some people who claim to have solved the problem by round-robing two, three or more instances of web-socket objects to prevent the entire game from choking on a lost packet, but so far I've seen no working examples.

If anyone has any comments on the issue such as success stories, links to further resources, research papers, prototypes or even wild ideas, I'd be happy to hear them.

I edited my previous post.

Kyatric, there's no mention of "UDP" or even "datagram" in that spec, there's only a mysterious "reliability mode" flag on the connection, and no explanation given regarding what it does.

In addition, we can see that the working draft in 2008 was discussing UDP, including registering ports for it, but it seems strangely missing from the current draft. Where are the discussions happening? Why was support dropped? Why did chrome suddenly drop it's own experimental extension (the only thing that had UDP support)?

I don't see game devs making noise regarding this stuff. The HTML5 standard gets thinner and thinner, and comments like this make me lose a bit of faith on the future of multiplayer with HTML5 - will we have to wait 10 years like the flash guys?

I mean, it's either that or resorting to evil black magic (suck as coercing your javascript to interact with a udp java applet).

As for your method of "kicking the user out" when he/she switches tabs, I could do that, but what if my game had to transmit a fair bit of state before he could join?

This would mean that people couldn't even alt-tab to check an instant message, or answer a skype call, since a minimized window counts as "suspended" - I can't expect anyone to take my game seriously if I say "this game is played in 30 minute sessions - do not minimize or switch tabs at any time during gameplay or you will be disconnected" - it just doesn't work like that, especially considering that some events may force your window to minimize.

And I'm not even touching the issue of the additional overhead of having to create the rejoin code, which is non-trivial.

We have considered official multiplayer features for C2, but I don't think it is worth implementing until there's good UDP (or an "unreliable mode" for transmission, which is likely spec-speak for UDP). As noted without this the latency spikes can make the game unplayable. I'm pretty sure even if Google are being quiet about it that they're working on something in this area though. WebRTC might also provide a solution.

As for tabbing away, it's not a new problem, fullscreen games could always randomly be quit or alt-tabbed in to the background, it's just a lot easier to do in a browser window. Use the 'request fullscreen' action and encourage the user to switch in to fullscreen, and that should increase their engagement and make an accidental quit less likely. Also, even inactive tabs still keep websocket connections active IIRC, it's just the browser will reduce the framerate to 1 FPS. So as long as your game can handle running at 1 FPS and not time out or lose track of the game state, it should be fine.

Worth noting that the Photon game server offers reliable UDP. But the bad news: their HTML5/JavaScript SDK (currently) depends on WebSockets.

Fimbul: check this video from the last Google IO

<center>[tube]E8C8ouiXHHk[/tube]</center>

At 26:42 it states the protocol used for the DataChannel as being "SCTP/DTLS/UDP".

The video is really worth having a look at, although it appears you are to go through App Engine to get this technology working.

Anyway, it's clearly being developed with concerns regarding multiplayer gaming needs.

It only is available in Chrome 21 (with some flags changes) atm, but is also already being implemented in FF 17 which is promising.

Edit: DataChannel is still in the process of being "standardized", but it is expected to be up and running by the end of the year.

And this is all good news pointing to a future for multiplayer HTML5 gaming ;D?

I'm still quite shocked at how BrowserQuest has done it, but yet there are so many limitations preventing it.. I'm not a very tech saavy guy when it comes to networking, so I'm going to remain lost until someone explains it all in layman terms!

I'm digging this topic off it's grave since the HTML5 spec has been finalized and 2012 ended.

Kyatric, as the video said, DataChannel would be ready by the end of the year, do you have any news on it? I'm trying to dig around the web but so far I'm out of luck.

Fimbul: Well all I know is that for now the dev of audio/video protocol/communication is available in chrome (with flag switch I think for now, or maybe in beta) and that January's release of FF should have it too.

But for the DataChannel I believe we will have to wait longer (I'd expect around 6 months, but it's just a personal guess).

After all, once the video chat part of webRTC is stable, DataChannel would be almost complete too, the major difference being the user has the choice of the datas to send/receive whereas it's fixed streams for the video chat.

Browser Quest is open source, aren't there any useful information for you guys?

Astrosus, it uses TCP from what I've seen. The gameplay is too basic, too, but thanks for the contribution!

We need UDP to enable twitchy fast-paced real time gaming with HTML5.

It's not simply WebRTC that's needed. There's also the need of a solution added on top of that to discover available devices on the same network (�la Bonjour/mDNS), or do something to punch holes inside firewalls, to work without a central server.