Hacker News Reader

Comment by swiftcoder | Hacker News Reader

> It mentions that the video game industry uses UDP but then fails to further address that use case

Video games tend to use UDP for the same reason everyone else mentioned does: timeliness. You want the most recent position of the various game objects now, and you don't give a shit about where they were 100ms ago.

The proposed solution of segmenting data into QUIC streams and mucking with priorities should work just fine for a game.

> Is that even supported across all the various gaming platforms?

QUIC itself is implemented in terms of datagrams, so if you have datagrams, you can have QUIC.

View on HN

But the proposed solution provides no value over datagrams, while it has plenty of downsides.

Let me rephrase the problem here for a simple FPS game:

The entire world state (or, the subset that the client is supposed to know about) is provided in each packet sent from the server. The last few actions with timestamps are in each packet sent from the client. You always want to have the latest of each, with lowest possible latency. Both sides send one packet per tick.

You do not want retransmission based on the knowledge that a packet was lost (the RTT is way too long for the information that a packet was lost to ever be useful, you just retransmit everything every tick), you do not want congestion control (total bandwidth is negligible, and if there is too much packet loss to maintain what is required, there is no possible solution to maintain sufficient performance and you shouldn't even try), and none of the other features talked about in the post add anything of value, either.

It reads like someone really likes QUIC, it fit well into their problems, and they are a bit too enthusiastic about evangelizing it.

In practice most games also need reliable side channels for control messages/chat/etc, and so they end up building optional reliable streams over UDP... and at the end of this path lies something that looks a lot like a (less thoroughly designed/tested) version of QUIC

My spidey sense is that almost all games used a custom UDP solution. I could be wrong! I made a Twitter poll to try and get info.

You’re right that a custom reliable UDP solution is going to wind up QUIC-like. On the other hand it’s what games have been doing for over 20 years. It’s not particularly difficult to write a custom layer that does exactly what a given project needs.

I don’t enough about QUIC to know if it adds unnecessary complexity or not.

Yeah, I don't know how many games actually use a fully custom layer, versus forking something like enet/RakNet

Tribes, and various quake mods, used to use a TCP side channel for chat and control messages. Tribes famously used irc, and you could connect to a tribes server with any irc client to chat with your friends in game

Why not make a second connection using another protocol (possibly TCP)?

You also don't want to share the routing performance, congestion treatment, OS queue, and probably a lot of other stuff.

NAT traversal, historically. Reliably punching one hole through the local NAT gateway is bad enough, adding a second protocol into the mix was asking for trouble.

> Video games tend to use UDP for the same reason everyone else mentioned does: timeliness. You want the most recent position of the various game objects now, and you don't give a shit about where they were 100ms ago.

This is only true for games that can replicate their entire state in each packet.

There are many situations where this is infeasible and so you may be replicating diffs of the state, partial state, or even replicating the player inputs instead of any state at all.

In those cases the "latest" packet is not necessarily enough, the "timliness" property does not quite cover the requirements, and like with most things, it's a "it depends".

With those requirements raw datagrams also don't fit the bill, so you'll need to build some sort of reliable stream abstraction over UDP (with optional unreliable delivery for the state which you can replicate quickly)... and now we're closing in on QUIC territory

I thought QUIC promised you get your data eventually? In that case it wouldn't be great for games, because you usually don't want packets that got dropped, as the next packet will replace it anyway?

> I thought QUIC promised you get your data eventually?

QUIC optionally promises you that, you are free to opt out. For example, take a look at the QUIC_SEND_FLAG_CANCEL_ON_LOSS flag on Microsoft's QUIC implementation.

Reply on news.ycombinator.com