4 ms·

I suggest you use the WebTransport datagram API for your netcode, now that it's supported by the latest version of all major browsers (except Safari). WebSocket

I suggest you use the WebTransport datagram API for your netcode, now that it's supported by the latest version of all major browsers (except Safari). WebSockets suffer from the typical head-of-line blocking issues inherent to TCP, which makes it a suboptimal fit for latency sensitive applications like multiplayer games, where you only care about the most recent state.

modeless 2y ago
I wouldn't suggest WebTransport unless/until Safari gets support. Instead you can use WebRTC DataChannel today for UDP in all browsers. Also, WebTransport doesn't support direct P2P connections but WebRTC does. I have ported Quake III to use DataChannel and it works great (once all the WebRTC boilerplate is in place). You can test it here: https://thelongestyard.link/ https://thelongestyard.link/ Once you click the multiplayer link you will get a URL with your server name, which others can visit to join your server instantly.
- iAmAPencilYo 2y ago
  That is absolutely fantastic. Instant mayhem! Thank you for this.
- kaliqt 2y ago
  Isn't WebTransport supposed to get P2P via QUIC?
  - modeless 2y ago
    I think there is an intention to add P2P to WebTransport someday. But I wouldn't hold my breath.
- tillcarlos 2y ago
  Most underrated comment, and what a blast from the past. Back then Quake 3 would require 3d accelerators and now we can play it in the browser... and some person on HN just casually "ported it". Awesome! What's the technology there? Do you run it on WASM?
  - modeless 2y ago
    Thanks! Yes, it's ioquake3 compiled to wasm with Emscripten, and definitely still uses 3D accelerators via WebGL. Quake III is GPL of course and the code is here: https://github.com/jdarpinian/ioq3 https://github.com/jdarpinian/ioq3 In addition to WebRTC multiplayer and a bunch of random improvements I added web gamepad API support as well as touch controls. Yeah, touch controls, because half of everyone is browsing on their phone and I don't think you can really call it a proper web port if it doesn't work on phones. Touch controls for Quake III were a challenge but I think I have something that's fun to use. I'm interested to hear if it works for people. I'm also experimenting with a port of Cave Story (the classic 2D indie platformer) with touch controls for mobile: https://thelongestyard.link/cave-story/ https://thelongestyard.link/cave-story/
- altanis 2y ago
  WebRTC is complicated; there are many more edge cases compared to websockets. Off the top of my head, I know I'd need to run a TURN server for people behind symmetrical NAT or CGNAT networks, which would be a pain. WebSockets are much more accessible for everyone. In the future I'll investigate UDP protocols, but its likely I'll always use TCP for web games.
  - modeless 2y ago
    Yes, WebRTC is complicated. But you only need a TURN server for the P2P case. If you are using it in a client-server mode like WebSockets then there is no need for a TURN server, and connection establishment should be significantly simpler. And if you don't need the audio/video stuff then you can ignore that complexity as well. (Although voice chat or even video could be a very cool and differentiating feature for a multiplayer game.)
    - NathanFlurry 2y ago
      We work with a lot of multiplayer game devs and always recommend fast-paced games take a second look at client <-> server WebRTC. This the demo we share: https://github.com/rivet-gg/examples/tree/main/javascript/webrtc https://github.com/rivet-gg/examples/tree/main/javascript/we...
- tracker1 2y ago
  Damn, very nice indeed... Of course I got pwned before I could even get my hands on the right keys. Q3A and Quake TF mod are definitely happy memories.
Kiro 2y ago
I thought MMORPGs preferred TCP.
- aatd86 2y ago
  If some packet loss is not problematic, UDP is used. Often for players positions. That's also how some speed hacks are made possible.
- Chabsff 2y ago
  You typically want a mix of UDP and TCP (or sometimes a weird TCP-like monstrosity rebuilt on top of UDP). Taking great care to design your data streams to be self-correcting (e.g. transfer a world location where characters are going towards instead of which direction they are heading) can go a long way towards saving a ton of synching headaches, and enables very efficient networking. One-off events go over the TCP-like channel, but constant streaming data that naturally self-correct over time, like the example above, can benefit from being on the UDP channel.
  - ErikBjare 2y ago
    > or sometimes a weird TCP-like monstrosity rebuilt on top of UDP Like QUIC?
spintin 2y ago
[dead]
diath 2y ago
Have you shipped a multiplayer game yourself?
altanis 2y ago
I like the idea of UDP, but protocols like WebTransport aren't 100% supported and are still relatively new compared to websockets. But you're right, using UDP would be a less latent approach and clientside prediction can account for any lost packets.

modeless 2y ago

I wouldn't suggest WebTransport unless/until Safari gets support. Instead you can use WebRTC DataChannel today for UDP in all browsers. Also, WebTransport doesn't support direct P2P connections but WebRTC does. I have ported Quake III to use DataChannel and it works great (once all the WebRTC boilerplate is in place). You can test it here: https://thelongestyard.link/ https://thelongestyard.link/ Once you click the multiplayer link you will get a URL with your server name, which others can visit to join your server instantly.

iAmAPencilYo 2y ago
That is absolutely fantastic. Instant mayhem! Thank you for this.
kaliqt 2y ago
Isn't WebTransport supposed to get P2P via QUIC?
- modeless 2y ago
  I think there is an intention to add P2P to WebTransport someday. But I wouldn't hold my breath.
tillcarlos 2y ago
Most underrated comment, and what a blast from the past. Back then Quake 3 would require 3d accelerators and now we can play it in the browser... and some person on HN just casually "ported it". Awesome! What's the technology there? Do you run it on WASM?
- modeless 2y ago
  Thanks! Yes, it's ioquake3 compiled to wasm with Emscripten, and definitely still uses 3D accelerators via WebGL. Quake III is GPL of course and the code is here: https://github.com/jdarpinian/ioq3 https://github.com/jdarpinian/ioq3 In addition to WebRTC multiplayer and a bunch of random improvements I added web gamepad API support as well as touch controls. Yeah, touch controls, because half of everyone is browsing on their phone and I don't think you can really call it a proper web port if it doesn't work on phones. Touch controls for Quake III were a challenge but I think I have something that's fun to use. I'm interested to hear if it works for people. I'm also experimenting with a port of Cave Story (the classic 2D indie platformer) with touch controls for mobile: https://thelongestyard.link/cave-story/ https://thelongestyard.link/cave-story/
altanis 2y ago
WebRTC is complicated; there are many more edge cases compared to websockets. Off the top of my head, I know I'd need to run a TURN server for people behind symmetrical NAT or CGNAT networks, which would be a pain. WebSockets are much more accessible for everyone. In the future I'll investigate UDP protocols, but its likely I'll always use TCP for web games.
- modeless 2y ago
  Yes, WebRTC is complicated. But you only need a TURN server for the P2P case. If you are using it in a client-server mode like WebSockets then there is no need for a TURN server, and connection establishment should be significantly simpler. And if you don't need the audio/video stuff then you can ignore that complexity as well. (Although voice chat or even video could be a very cool and differentiating feature for a multiplayer game.)
  - NathanFlurry 2y ago
    We work with a lot of multiplayer game devs and always recommend fast-paced games take a second look at client <-> server WebRTC. This the demo we share: https://github.com/rivet-gg/examples/tree/main/javascript/webrtc https://github.com/rivet-gg/examples/tree/main/javascript/we...
tracker1 2y ago
Damn, very nice indeed... Of course I got pwned before I could even get my hands on the right keys. Q3A and Quake TF mod are definitely happy memories.

Kiro 2y ago

I thought MMORPGs preferred TCP.

aatd86 2y ago
If some packet loss is not problematic, UDP is used. Often for players positions. That's also how some speed hacks are made possible.
Chabsff 2y ago
You typically want a mix of UDP and TCP (or sometimes a weird TCP-like monstrosity rebuilt on top of UDP). Taking great care to design your data streams to be self-correcting (e.g. transfer a world location where characters are going towards instead of which direction they are heading) can go a long way towards saving a ton of synching headaches, and enables very efficient networking. One-off events go over the TCP-like channel, but constant streaming data that naturally self-correct over time, like the example above, can benefit from being on the UDP channel.
- ErikBjare 2y ago
  > or sometimes a weird TCP-like monstrosity rebuilt on top of UDP Like QUIC?

spintin 2y ago

[dead]

diath 2y ago

Have you shipped a multiplayer game yourself?

altanis 2y ago

I like the idea of UDP, but protocols like WebTransport aren't 100% supported and are still relatively new compared to websockets. But you're right, using UDP would be a less latent approach and clientside prediction can account for any lost packets.