Hacker News Reader

Comment by 10000truths | Hacker News Reader

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.

View on HN

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/ Once you click the multiplayer link you will get a URL with your server name, which others can visit to join your server instantly.

That is absolutely fantastic. Instant mayhem! Thank you for this.

Isn't WebTransport supposed to get P2P via QUIC?

I think there is an intention to add P2P to WebTransport someday. But I wouldn't hold my breath.

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?

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

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/

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.

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.)

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/we...

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.

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.

I thought MMORPGs preferred TCP.

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.

> or sometimes a weird TCP-like monstrosity rebuilt on top of UDP

Like QUIC?

If some packet loss is not problematic, UDP is used. Often for players positions.

That's also how some speed hacks are made possible.

Have you shipped a multiplayer game yourself?

Reply on news.ycombinator.com