I'm surprised it's taken this long for me to see a WebRTC game on hacker news. I think that's a very promising technology for realtime games in the browser. When more websites can hide source code with web assembly, I wonder if that's what it'll take for more to come out.
That's because WebRTC really isn't a great fit. It doesn't guarantee a UDP pipe so it can fallback to TCP with disastrous results and the dependency chain on the server side makes it really painful to integrate.
You can cause effectively force UDP by doing two things:
1. Don't signal TCP ICE candidates.
2. Don't provide TCP TURN servers.
If you do those two things, it's impossible to get a TCP connection. In fact, just doing #2 will nearly guarantee it (since a TCP connection outside of TURN is so rare).
But ICE will almost always prefer UDP over TCP, so if it's using TCP it's because otherwise you simply wouldn't be connected at all. And if you'd prefer not to be connected, you could simply close the connection when you observe it's over TCP.
Okay so you can force a UDP connection, still doesn't solve the second point which is that it's a royal pain to use the Google library.
Last time I tried to get the chromium builds going on win32 was 3 hours of complete failure and obscure error messages because of various "non-googler" flags. The WebRTC page basically says you can't do Android development if you don't have a Linux machine [1].
There's been a bunch of game studios that started down the path of WebRTC and basically gave up since it's so hard to integrate. Compare that with 2-3 C files and a couple headers + libsodium for something like Netcode.io.
Also game servers don't really care about congestion control. They rarely break ~15kbps of continuous data per client versus something that scales up with bandwidth like a file transfer. Any case where congestion control is an issue should be something that needs to negotiated over a TCP stream anyway(otherwise you're just reinventing TCP over UDP).
Congestion control is required to be enforced at the browser level as an anti-DoS measure. You could just have the browser API limited to 15kbps, but that seems like a silly limitation when the way around it has already been implemented...
Take a look at Netcode.io, all clients are auth'd with a token and any client that doesn't have the token gets ignored. The token also mandates what IP/hostnames are a valid destination. That way someone trying to DoS just gets their account blacklisted.
Congestion control isn't going to help when a bad actor spoofs your protocol and dump GBs of data on you.
Yeah the WebRTC repo is basically awful to try to build. tbf though that's not entirely out of line with other open source projects from Google. You get to have fun tearing it out of Chromium and experimenting until it works...
Do you know the reason causing such a fallback? Would there, in general, be any other possibility to use UDP under the circumstances causing the fallback?
If I am not mistaken, it is at least possible to detect whether UDP is available using the protocol property of the RTCIceCandidate. [1]
Nope, spec just doesn't mandate that UDP is a required channel.
I mean fundamentally the goals of WebRTC and game engines just aren't that well aligned. All games are going to want an authoritative server to hold the master state and reconcile clients. Where as WebRTC is very much interesting in P2P. All the STUN, TURN and ICE stuff is pretty much wasted on a game server.
The spec is also way over complicated, heck it covers DTMF for crying out loud.
Thank you for the information. Unfortunately, unreliable data channels currently seem to be the best option if you want people to be able to host their own game server easily from within the browser without having to install additional software.
Having experimented a bit with WebRTC myself, I agree that it is overly complex but it also offers many features. And if usage is too complicated for game developers, they can still libraries that simplify the usage for their purpose.
As I just commented higher up in the thread, it is possible to force UDP if that's what you want.
And while WebRTC is complex, you can ignore almost all of that if you're just doing client to server data channels. You just need to speak ICE lite, DTLS, and SCTP, all of which have libraries. See some of my comments from months ago for more details.
I've already commented at length about this, but I'll repeat: UDP without congestion control in browsers is not really an option. UDP with congestion control is basically what QUIC is. So we might as just get p2p QUIC connections working instead (which we are doing in the ORTC community group).
I think it is just P2P in a sense that no additional third party is required, except for the connection establishment. It is still a client-server model. The difference is just that any browser can become a server hosting the game.
Even if P2P in this case meant that all clients were connected to each other, you could still have each client maintain its own state and only transmit the user input. I do not see why this should not work well as long as the majority uses honest clients.
Exactly, the real game runs on the host, the clients only send user input and Sync positions of the in-game objects, you can't use software like cheatengine clientside because it will always sync on what the host sees, but if you use it on the host all the changes will be shared with the clients connected.
Hello I'm the dev of this game ask me anything you want, we are working on an updated version of the game stay tuned on our official page https://www.facebook.com/SockeyGame/.
Unfortunately, as many game creators, they seem to believe that everybody in the world has qwerty keyboards, which is not the case. Using the A, W, S and D letters does not make sense on azerty keyboards (up and down reversed). Why can't we use keyboard arrows to move?
Too bad, the game would have been really fun to play if controls were usable for me.
