My understanding was that WebRTC wasn't specifically designed for video and voice applications exclusively, but rather as a generic real time, peer to peer communication framework that included capabilities for voice and video. Not trying to take away from your comment or anything, but maybe I misunderstand WebRTC.
I recently implemented a WebRTC multiplayer game in Godot, and yeah, it has very little to do with chat, and isn't really "off the shelf", it took a hell of a lot of configuration, plus running and maintaining a STUN/TURN server and backend lobby/matchmaking system. It's no more a chat protocol than HTTP really when you're doing that kind of programming with it, just has some nifty tricks for getting around routers and making a direct connection where it can.
That said, it was better than NAT punch-through and/or UPNP which are not very reliable these days.
Correct me if I'm wrong. STUN/TURN is the one that is doing the UDP punching. And in the event that fails, all the data are being passed through the STUN/TURN server, which makes it just like client/server setup where the server became the bottle neck again.
Stun is a protocol to query the network about the topology. Turn is a protocol to route through a third party when p2p fails. Both of these are part of the ICE methodologies.
STUN is basically a way to know your external IP address to share to others and have both peers try to connect to one another through them. It's lightweight.
If that fails, then there's TURN which acts like a proxy between the peers.
Yeah. It's specifically designed for both AV, and for generic datagrams. You have to choose one or the other during initialization of a stream (but can have multiple streams between clients).
tl;dr using WebRTC just for realtime client<->server data sucks, but WebTransport[1] is coming soon to serve that exact usecase with an easy API
WebRTC has data channels, which are currently the only way to achieve unreliable and unordered real-time communication (UDP-style) between the browser and other browsers or a server. This is pretty essential for any networked application where latency is critical, like voice and video and fast-paced multiplayer games.
As other commenters have noted, it's a royal pain in the ass to set up WebRTC if all you want is UDP-style communication between a server and browser, since you need to wrangle half a dozen other protocols in the process.
However! A new API, WebTransport[1], is actively being developed that will offer a WebSockets-like (read: super simple to set up) API for UDP-style communication. I am extremely excited about it and its potential for real-time browser-based multiplayer games (which I'm working on).
What do you find hard about setting up a WebRTC server? I hear from users they are able to spin up a Pion DataChannel server in 5 mins (including installing Go)
WebTransport isn’t going to be here soon though, I would be cautious in investing. Stuff like Congestion Control is still a big unknown [0] and we don’t have Datagrams everywhere.
I just starred it, it does seem like it'd alleviate a some of the pain. Another similar (more end to end) project I had come across is: geckos.io. This previous HN thread[1] discusses some of the (at least perceived) difficulty with using WebRTC as a "WebSockets but UDP" solution.
I'm not sure I follow the concern about congestion control. UDP doesn't have it either, presumably since if you're building an application that requires such latency sensitivity, you don't mind rolling your own congestion control algorithm that makes most sense given your application's specific needs, right? Pretty much all FPS games do this, as far as I understand.
I just don't know what a 'ROM game command' is. Seems more likely it would be controller inputs to one person's emulator? Or perhaps everyone has an emulator and the inputs are simply shared.
It’s probably really simple: if you normally load a ROM game and start a multiplayer game you control all the other players input. This simply goes next step and makes other inputs be controlled by other players.
Rollback networking is essentially event sourcing. Game states are immutable, and new game states are derived from adding inputs (events).
You keep the last dozen game states around in memory, and if you receive an input from the past, you rewind to the last game state prior, add it to your input stream, and fast forward to the present.
It has the same base advantages and drawbacks as RTS networking - the core logic is written as though the game is single player, and complexity can be scaled arbitrarily without bloating bandwidth requirements.
But in addition, you get the benefit of zero input latency (play a multiplayer RTS game and send a unit around - they won't move for 200ms or so), and the drawback of an absolute clusterfuck time rewind debugging madness if any inadvertent mutation of your immutable data happens.
The reason you do rollback with something like this is it gives you zero latency, and you can retrofit it on to an emulator without changing any game code just by using memcpy() on the game state.
Source: I've developed about a dozen titles using rollback networking.
I find this hard to conceptualize/unite with the players view of the game - so if an input arrives out of order the engine can essentially just reapply the new adjusted stream of events to correct itself? From a data modelling perspective that seems fine.
However, in those situations what does the player see in game? IIRC rollback was popularised in fighting games like Street Fighter - so does the player see one "universe" only for that branch to suddenly rewind and replay to an alternate universe where a tiny action happened/does not happen?
That's exactly what happens. If you are writing the game yourself, you can do interpolation to fix things up gradually.
You can also delay significant events such as death until the rollback threshold has been passed, so you don't run in to knife edge situations where, e.g., it looks like you died and your character starts to ragdoll but then you snap back when it turns out you killed the enemy instead.
The key to it not being too disruptive is keeping the maximum rollback threshold fairly low. If you add inputs and your ping is greater than the threshold, they get delayed to a later frame, and your inputs start to feel sluggish (the server would enforce the delay, but you'd also add it client side).
Thank you these types of comments are why I frequent HN! Really insightful, first time I came across rollback I had one of those loving CS/SWE moments. So I'm grateful that you're so obliging to my curiosity!
Out of interest are there any toy projects out there you can point to that can explore the concepts here with no first hand experience with game dev?
Hmm, I haven't come across any, although you can probably dive in and build a prototype system without too much trouble.
My recommendation would probably be to build it without netcode to start (two local clients connected over a virtual pipe), and using a system where you can easily serialize the game state - C with memcpy(), JavaScript reading/writing to json, Clojure or similar. I use C# with compile time generated codes to store data in slots - it's not fun.
While not rollback, the original AOE networking writeup is probably the best I've come across as an introduction to deterministic multiplayer. There's the GGPO framework that you can get off the shelf, but it's pretty heavy weight.
There are some real head scratching moments with debugging rollback, but in general for games that aren't too performance intensive it shines. I actually developed an entire strategy game prototype over a period of three weeks in single player before bothering to test it worked in multiplayer. It did first try. Four days later, it was live in public beta (starjack.io if you're interested, which peaked at around 400 concurrent players).
Use off-shelf-chatrooms-software to create rooms but instead of chatting you send ROM game commands to each other and allow for multiplayer gaming!