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]

[1] https://www.w3.org/TR/webrtc/#dom-rtcicecandidate

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.

> just need to speak ICE lite, DTLS, and SCTP...

I think your proving my point here. That's a lot more to ask than a simple libsodium based crypto + auth token that something like Netcode.io uses.

There is a button to select the input keys when logging in.

Oh you're right! I searched for something after the login screen but I missed this before. Thank you.

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.

It definitely lacks some feature indicating where the room is hosted. This would make it easier to find rooms with a lower latency.

Disclaimer: I am not related to the game creator.

Mozilla has a demo for the use of WebGL which is pretty impressive: http://kripken.github.io/misc-js-benchmarks/banana/index.htm...

Web assembly even extends the possibilities game creators already have for creating browser-based games.

The game that's compiled from, sauerbraten, was fun. I used to play it.