Latency Compensating Methods in Client/Server In-Game Protocol Design (2001)

> Getting a "feel" for your latency is difficult. Quake3 attempted to mitigate this by playing a brief tone whenever you received confirmation of your hits. That way, you could figure out how far to lead by firing your weapons in rapid succession and adjusting your leading amount until you started to hear a steady stream of tones.

Ah, so that's what that sound was! I always wondered why Q3 had that weird sound when I hit someone, and never knew what it was supposed to sound like. It ends up being one of those things you get used to, and the game wouldn't be the same without it.

Fond(?) memories of the Tribes 2 engine discussed in that paper, which became the GarageGames engine, which was so poorly architected that every function of interest ran inside the network serialization function. Why did all the code run inside the network serializer? Because the engine was such a mess that no one could figure out why their values were getting stomped on and eventually someone realized "hey! The last bit of code that runs each frame is the network serializer! If I put my player bone animation code in the network serializer nothing can stomp on my animations" and a new arms race was born as every developer rushed to put their code into the network serializer.

I wonder, how low could we get latency if network providers put as much effort into reducing lag as they do increasing bandwidth?

the overwatch developers made a video explaining their implementation of these concepts at a bit of a higher level: https://www.youtube.com/watch?v=vTH2ZPgYujQ