Viability of Real-Time Multiplayer in HTML5

In my experience it doesnt really matter which type of data flow you use to get a multiplayer going.

Its alll about how you implement it.

solution to old data lag ... send game time/tick along, and do not proces outside of set time frame / tick count :)

Actually even with TCP you can work with it. Just add a sent time with the packet adjust for viable time difference. then drop all the packets that are too old.

This won't fix some latency, but it will re-adjust to not handle messages that are too old and can cause problems.

Anyways. Realt time MP can be done with TCP. it's just an elite myth.

UDP is better; i won't argue better. But can't, shouldn't are not relevant.

Nope, TCP is completely unusable for fast paced games. You cannot read new packets until old ones arrive.

For instance, let's assume players A and B.

Player A sends packets 1,2,3 and 4 to player B.

Player B receives packets 1,3 and 4, but not 2.

Player B can read packet 1, but cannot read packet 2 because it was lost, and it cannot read packets 3 and 4 because it has to wait for packet 2, even though it already received packets 3 and 4. Player B cannot simply "drop" packet 2 until it has received it - it is forced to wait for it's retransmission.

The game hangs in there waiting for a stale packet that is of no use even though it has the data it needs to continue simulating - it cannot read packets 3 and 4 in any way whatsoever, since it is a protocol restriction. Meanwhile, player A is desperately attempting to resend the now-useless packet 2 that was lost.

By the time packet 2 arrives, thus freeing packets 3 and 4, those are already stale (meaning that the data in them is already too old), and player A is already sending packet 10 - if any new packet hangs, the game has to wait again.

Keep in mind this is only a problem for fast paced games - turn based games don't have this problem since there are times where no packets are being sent, allowing TCP to "catch up" without creating delays.

What is the current solution for fast paced TCP games? It's somewhat complex:

The players open multiple TCP connections to each other and begin sending packets alternating the connection that is used. If a packet "hangs", only one connection is affected. This problem is detected, and that connection is dropped and recreated, while the others are retained. Maybe this is something Ashley could look at if the HTML5 UDP solution ends up being underwhelming.

That's called head-of-line blocking and we have seen it make even simple games unplayable in our own tests. WebRTC DataChannels support UDP which allows out-of-order delivery which is the best solution to that problem.

Ashley - UDP in HTML5 has been in the drawing board (in one form or another) for years - while I believe it will eventually get past that stage and onto production, do you think it's viable to use TCP sockets round-robin, recreating sockets that block?

Fimbul - no it's not, it works already with WebRTC DataChannels!

They are unplayable if there is no latency handling. While nothing can be done until the next packet comes in; once the packet arrives the message can be ignored to prevent screwing up and using the next most up to date state.

However my C2 test multiplayer game ran fine unless the player had poor ISP connection. Almost the entire RTS genre runs on TCP, old and new MMO still use TCP even for there PvP. I've never argued that UDP performs better. I'm arguing that posts saying TCP can't do real-time are misinformation.

Now here is what the two above posts can never prove

Real Time TCP Games

Guild Wars(has PvP)

Guild Wars 2(has large scale PvP)

Age of Empire(has PvP)

World of Warcraft(has PvP)

Star Craft(has PvP)

... there are many more, but these are some of the bigger names.

That this small list of realtime pvp games fail at doing real-time. It's impossible that the all the nay saying posts can't do. And all the nay saying posts haver never actively proved there claims.

As a nail

now how about stop making claims and prove that my posts are wrong? I'm not saying UDP isn't better, I'm saying and have proven many times that TCP will pass under most games. Yet nothing but statements says the contrary

Again the games will fail for games like Street Fighter and precision based shooters likes Call of Duty.

I'm also not saying that Ashley should make a TCP server/client structure. If the Ash wants to weight I'm fine by that. But there are options now and people should not be dissuaded by misinformation to make that choice.

Ashley - Wow, I just saw this - chrome 31 stable, eh?

Well I guess I know what you're cooking up then :D

Fimbul

I'm betting Ashley is cooking up a simple P2P set of game protocols. I'm hoping there will be latency handling and predetermine positioning though.

We've done our own tests with TCP which show games are just totally unplayable over poor quality links. TCP does fine where there's a high quality connection, but if your ISP is crap or there is high congestion on the network between you and the host, UDP is essential to keep the game playable. I guess round-robin TCP connections would get by as well, but what's really needed is out-of-order delivery which UDP excels at.

I will agree with that. And much to my surprise poor ISP connections can be found in my own city of Vancouver. My friend who lives in our downtown HUB had very poor performance in my TCP game. I suspect if I handled TCP messages better I could get around that. TCP requires more overheard to handle latency problems where as UDP just needs redundancy for lost information. UDP is probably easier in the long run than handling TCP latency.

However as a counter he does play Guild Wars and WoW and other TCP games with no problems. He is also an active player of League of Legends, but I'm pretty sure that one is UDP.

I don't have the slightest clue what is going on here but I read Ashley blog just now regarding webRTC...

I'm not quite sure what to expect... so... I hope some of you can give a very easy to understand explanation/answer...

So multiplayer caught my interest just a few minutes ago so my noob questions are:

1. If i want to make a multiplayer, if C2 finally support webRTC, does it mean I only need to make the client?
2. Will i need a server if my game is kind of arcade-action-fighting game like street fighter?
3. Does it mean local-hosted-wifi-multiplayer will be possible (no internet connection)
4. Will the multiplayer previewing supported? let say I want my laptop VS my mobile phone VS my iPad

There is a game engine called isogenic that seens to be able to support a fast multiplayer trough node.js:

isogenicengine.com

Maybe that�s an option? I don�t know what their license is, but Construct 2 could license their solution if it�s any good.

I would gladly pay extra for a multiplayer module.

Also, check their isometric engine, it supports isometric TMX and that�s sweeet.