Viability of Real-Time Multiplayer in HTML5

Pode: WebRTC relies on a server to client communication, only it happens to be "transparent" in the end.

The server (also referred to as wabRTC cloud) is a mere medium to transport streams from a client to another.

It still is not a direct peer-to-peer connection.

Kyatric : I need to find a discussion I saw about it. Chrome dev are planning to integrate something like that into the engine. (I'm pretty sure I didn't hallucinate it <img src="smileys/smiley2.gif" border="0" align="middle" />)

Whilst UDP is all well and good. ..Is there perhaps some confusion between that and well designed architecture.

I believe good multi-player gaming can be achieved with TCP.

First off all, we need a optimised methods of transit and a means - socket.io. Many guys here have already demo'd the use of this.

We should, in theory (and with some mods), be able to use c2runtime.js on both server and client side with some 'middleware' that deals with Client Side Prediction and Entity Interpolation.

gabrielgambetta.com

buildnewgames.com/real-time-multiplayer

What's interesting about the above article is the structure of the game:

client.js - The logic for the game client setup in the browser.

app.js - The server side app to run on node. This handles all the node/express/socket.io set up and code.

game.server.js - The logic for the game server (?lobby?).

game.core.js - The logic for the game play itself, both server and client.

Until I've created for myself and failed or seen a game output here with these methodologies, I can't believe it can't be done (double negative ;))

As an addition the Photon server mentioned above by Velojet, I stumbled upon SmartFox server recently, did you guys check it out already? They say it supports UDP as well

Smartfox

EDIT: ooh there's more more actually

Netty.io

Union

Cubeia

(btw I have no idea how to code all this, good luck guys we're counting on you^^)

lemo Smartfox doesn't include any HTML5 example, it means no HTML5 support.

Orbiter uses WebSocket, old news.

Cubeia, only for Java, not javascript!

A lot of people thinks Java is javascript, it's another huge mistake

Joannesalfa

Smartfox support with HTML5 (okay it's with websockets too)

I know the difference with java/javacript...

Cubeia's client is javascript, so even if the server is java, at least the client part should work with C2 right?

lemo oh my bad, about Smartfox, i doubt it comes UDP for HTML5; i don't think everyone uses server as Java.

My two cents:

If TCP is good enough for World of Warcraft, should be good enough for HTML5 games.

Socket.io is a good solution, but it has its own limitations. Current socket.io plugin for Construct isn't greatest but if you tweak it for your own needs, and respect the limitations of socket.io, it'll be good enough for most projects.

If you really want UDP, currently your only hope is Node-webkit export and UDP / Datagram Sockets module from Node.js. But that's .exe, not HTML5.

Without central server for game logic, there is no talk about some serious multiplayer game. I don't think we'll see some good solution for C2 multiplayer games with the "No programming required" premise any time soon.

Cheers!

Funny this thread resurfaced today.

Funny because there's been some news about webRTC : FF and Chrome are calling each others, interoperability is on the way.

It's still experimental but progress are made.

I'd love to see multi-player (online) play a part in HTML5 gaming - it's also intriguing to me and very interesting indeed for how it will work around its current nature of flow in its problems, we can only wait now to see.

Guys, be aware I'm talking about REAL TIME multiplayer.

It's perfectly possible to make multiplayer games right now, as long as they aren't REAL TIME (as in, dependent on fast reaction times or twitch skills). MMOs are also perfectly doable.

Adding multiplayer to the ghost shooter demo, as an example, is not viable. It gets very laggy very fast.

Let me give you an example (which is not scientific at all): a sustained 2% packet loss over a 50ms connection gigabit ethernet (latency and packetloss simulated) desyncs the game by more than 1 second per 5 minutes.

In the same conditions, under UDP, there is no loss or desync, the game runs perfectly.

Game was tested using raw tcp/udp and multimedia fusion 2. Server powered by node.js in both modes as well. I would imagine construct would fare even worse, due to websocket's overhead.

Just ran across this thread via a Google search and hoped this could be useful.

I'm currently developing an Arduino based robotics platform that needed to be controlled via Web Browser/USB Joysticks. I too found websockets unsatisfactory for any sort of real time control mechanism. Even socket.io provided poor performance, as it is all based upon the TCP protocol which is inherently "reliable". Usually it would function decently, but every second or two a few packets went missing and the entire link slowed to a crawl (similar to the 500ms delay as you mentioned).

In my case I only needed to make this work in Chrome, so I was able to get away with using the chrome.socket API:

developer.chrome.com/apps/app_network.html

Although you'd have to develop your game as a Chrome app, it would allow the creation of a game in the browser that uses UDP to communicate. I can confirm this works excellently for controlling remote control robots, so it should definitely work for gaming. Also for anyone else interested, the HTML5 Gamepad API is quite excellent as well:

html5rocks.com/en/tutorials/doodles/gamepad

The best part is that both the Gamepad API and UDP sockets are now supported out of the box for Chrome stable!

Hope this helps!

ericbarch

Good stuff, thanks for the contribution!

The problem with UDP is much of the crappy routers and middleware across the internet end up blocking it, or just not routing it because they're broken or badly designed. You need hacks like NAT Punchthrough just before any packets start arriving, and that requires intermediate servers. WebRTC has NAT punchthrough built in though, so is definitely a better candidate for that.

If the issue with TCP is one side falling behind over time, would this work:

Assume a multiplayer game with Player A and Player B

Set up the game so that every frame, each player will attempt to read a packet. However, each player will only send a packet every three frames. This way, whenever there is any latency, either side will catch up. It would not be the smoothest, but it would allow for an up to date communication while the client would fill in the gaps.