Viability of Real-Time Multiplayer in HTML5

Discussion and feedback on Construct 2

Post » Thu Feb 14, 2013 2:24 pm

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.
Scirra Founder
B
359
S
214
G
72
Posts: 22,949
Reputation: 178,574

Post » Wed Jan 01, 2014 7:41 pm

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.
B
2
Posts: 5
Reputation: 160

Post » Wed Jan 01, 2014 8:13 pm

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 :)
Who dares wins
B
50
S
10
G
10
Posts: 1,728
Reputation: 12,867

Post » Thu Jan 02, 2014 12:04 am

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.
B
87
S
18
G
9
Posts: 2,455
Reputation: 14,834

Post » Tue Jan 14, 2014 12:50 pm

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.Fimbul2014-01-14 12:56:54
B
35
S
8
G
8
Posts: 532
Reputation: 6,868

Post » Tue Jan 14, 2014 2:27 pm

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.
Scirra Founder
B
359
S
214
G
72
Posts: 22,949
Reputation: 178,574

Post » Tue Jan 14, 2014 3:42 pm

@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?
B
35
S
8
G
8
Posts: 532
Reputation: 6,868

Post » Tue Jan 14, 2014 3:49 pm

@Fimbul - no it's not, it works already with WebRTC DataChannels!
Scirra Founder
B
359
S
214
G
72
Posts: 22,949
Reputation: 178,574

Post » Tue Jan 14, 2014 3:52 pm

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
Guild Wars 2 TCP PvP Game play 5v5 with UDP announcers

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.jayderyu2014-01-14 15:55:23
B
87
S
18
G
9
Posts: 2,455
Reputation: 14,834

Post » Tue Jan 14, 2014 3:55 pm

@Ashley - Wow, I just saw this - chrome 31 stable, eh?
Well I guess I know what you're cooking up then :D
B
35
S
8
G
8
Posts: 532
Reputation: 6,868

PreviousNext

Return to Construct 2 General

Who is online

Users browsing this forum: No registered users and 16 guests