* https://fabiensanglard.net/quakeSource/index.php
I recommend checking it out.
EDIT: i was thinking of the analysis done on Quake 2, which is more about the engine:
* https://fabiensanglard.net/quake2/index.php
while the one about is regarding the multiplayer system, which is still an amazing bit of dev.
Github:
By the way, quake.exe for DOS was 404,480 bytes.
UDP's main advantage is the ability to process out-of-order - by sending duplicate state (actually more wasteful in terms of raw bandwidth!) or allowing for a lossy stream of data, your latency won't spike (as much) waiting for previous packets to be retransmitted. This isn't so much about efficiency per se, so much as it is about minimizing response time (even if it is potentially more bandwidth, potentially more CPU, more code, etc.) which matters a lot for some twitchy competitive games.
It's also not going to have any real impact if you're not dropping packets, nor if you're building your own reliable in-order channels atop that (which even the twitchiest game will likely have for some things if they're not using TCP as well - things like in game chat, leaderboards, matchmaking info, telemetry, etc. - a large number of which might use a full HTTP stack these days, if only under the hood of some official SDK, because why not use the same leaderboard server for your game clients and your website?)
And there's the occasional router (edit: or firewall, or other network appliance) that's so terrible, it manages to ship without a properly tested UDP stack, so a full blown TCP fallback isn't the worst idea ever.
TL;DR: Heckin' trade-offs.
I don't know if it's described sufficiently detailed anywhere besides the source though.