MagicNumber

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.

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

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

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.

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.