Very interesting article, as were the previous articles, thanks. On the other hand, reading it made me feel slightly depressed because my work currently is so boring compared to this and I don't have any energy left for hobby projects at the end of the day or week.
show comments
shdh
There are a number of issues with the Q3 netcode.
When entities are culled due to Potentially Visible Sets (PVS), a player moving fast enough near a vis brush may appear to pop into existence out of thin air. This occurs because of latency. A simple fix would be for the QVM code to extrapolate the player’s position into future frames to determine whether the entity should be culled.
The original Q3 netcode lacked lag compensation for hitscan weapons. As a result, players often had to "lead" their crosshair to register proper hits. This issue was later addressed by the Unlagged mod, which introduced lag compensation.
Input commands had a back buffer to handle lost input frames, but instead of applying them with a delay, the inputs were applied to entities instantly. Consequently, other players' entities sometimes appeared "choppy" when the respective player had a poor connection.
That being said, they got almost everything right:
* Snapshots with entities: Efficiently delivering game state updates to clients.
* Lerping entities: Smoothing movement on the client side using a snapshot buffer.
* Delta encoding: Transmitting only changes in entity states within snapshots.
* Huffman encoding: Compressing snapshots for reduced bandwidth usage.
Almost 12 years ago, I wrote my first web server in C. It was for a router/firewall device running Linux From Scratch(LFS), I can't recall the kernel version(2.6.x?).
Reading this just took me back and made me realize even though we have progressed so far with tech stack and new technologies(LLMs), there is so much joy in just writing plain C code. To me its just feels like working on a classic old 68 mustang and getting your hands dirty. What a joy!
markandrewj
The net code for the original Q3A client worked well for lan, but was sensitive to latency for remote play. One of the exciting changes to Quake Live was the updated net code for better remote play. Internet connections also got better in general with the time.
show comments
burnt-resistor
It's interesting that it's latency predictive with corrections and doesn't use anything fancy like operational transformations (OT). I guess it's actually simpler and shared state isn't a collaboratively-edited document but needs an independent, ultimate source of truth, is faster to develop, and probably more performant as a shared server.
show comments
ChrisMarshallNY
This reminds me of the term "isochronous," that I first started hearing, when FireWire came out. They allude to that, in their justification for using UDP.
I'm pretty sure that isochronous data transfer is a fairly important part of the current USB/Thunderbolt spec.
ltr_
Q: any resource to learn about modern approaches for real time game protocols?
show comments
brcmthrowaway
Is there any bullet propf open source middleware for this any more?
show comments
ernestrc
Such a good read on a Saturday morning as I slowly sip my matcha. The simple pleasures of life.
to-too-two
Seems like the site is getting the HN Hug of Death: <The connection has timed out>
ch33zer
Presumably some snapshot id number also gets sent to the client and is what gets acked?
show comments
Bernardbrant28
[dead]
Kurtcheng
[dead]
[deleted]
smolder
The grammar is pretty bad, but good for a presumably non-native english user. Overall, it's a good article, especially when you consider that it's free. Game network code and predictive motion and rollback or input delay-based approaches are all fascinating to me. It is a hard problem to deal with network latency in a way that feels real-time and doesn't break a game.
Very interesting article, as were the previous articles, thanks. On the other hand, reading it made me feel slightly depressed because my work currently is so boring compared to this and I don't have any energy left for hobby projects at the end of the day or week.
There are a number of issues with the Q3 netcode.
When entities are culled due to Potentially Visible Sets (PVS), a player moving fast enough near a vis brush may appear to pop into existence out of thin air. This occurs because of latency. A simple fix would be for the QVM code to extrapolate the player’s position into future frames to determine whether the entity should be culled.
The original Q3 netcode lacked lag compensation for hitscan weapons. As a result, players often had to "lead" their crosshair to register proper hits. This issue was later addressed by the Unlagged mod, which introduced lag compensation.
Input commands had a back buffer to handle lost input frames, but instead of applying them with a delay, the inputs were applied to entities instantly. Consequently, other players' entities sometimes appeared "choppy" when the respective player had a poor connection.
That being said, they got almost everything right:
* Snapshots with entities: Efficiently delivering game state updates to clients.
* Lerping entities: Smoothing movement on the client side using a snapshot buffer.
* Delta encoding: Transmitting only changes in entity states within snapshots.
* Huffman encoding: Compressing snapshots for reduced bandwidth usage.
Link to the first article in the series: https://fabiensanglard.net/quake3/index.php
Almost 12 years ago, I wrote my first web server in C. It was for a router/firewall device running Linux From Scratch(LFS), I can't recall the kernel version(2.6.x?).
Reading this just took me back and made me realize even though we have progressed so far with tech stack and new technologies(LLMs), there is so much joy in just writing plain C code. To me its just feels like working on a classic old 68 mustang and getting your hands dirty. What a joy!
The net code for the original Q3A client worked well for lan, but was sensitive to latency for remote play. One of the exciting changes to Quake Live was the updated net code for better remote play. Internet connections also got better in general with the time.
It's interesting that it's latency predictive with corrections and doesn't use anything fancy like operational transformations (OT). I guess it's actually simpler and shared state isn't a collaboratively-edited document but needs an independent, ultimate source of truth, is faster to develop, and probably more performant as a shared server.
This reminds me of the term "isochronous," that I first started hearing, when FireWire came out. They allude to that, in their justification for using UDP.
I'm pretty sure that isochronous data transfer is a fairly important part of the current USB/Thunderbolt spec.
Q: any resource to learn about modern approaches for real time game protocols?
Is there any bullet propf open source middleware for this any more?
Such a good read on a Saturday morning as I slowly sip my matcha. The simple pleasures of life.
Seems like the site is getting the HN Hug of Death: <The connection has timed out>
Presumably some snapshot id number also gets sent to the client and is what gets acked?
[dead]
[dead]
The grammar is pretty bad, but good for a presumably non-native english user. Overall, it's a good article, especially when you consider that it's free. Game network code and predictive motion and rollback or input delay-based approaches are all fascinating to me. It is a hard problem to deal with network latency in a way that feels real-time and doesn't break a game.