TCP has different goals than UDP gaming. You can (and 99% of games do) implement a real-time version of abstract TCP. But the similarities fall away when you stop looking at the "abstract" version of TCP.
This is an extremely optimized, important aspect of game programming. I would be very careful to suggest everyone is spending thousands of hours re-inventing the wheel for no reason--especially in the ultra-time-constrained game industry.
>Unfortunately, [...] TCP still has serious problems for multiplayer games and it all stems from how TCP handles lost and out of order packets to present you with the “illusion” of a reliable, ordered stream of data. [goes on to explain issues]
When you implement your own error and ordering stack, you are in control of how and when to drop a packet or consider the packet too out-of-date. These "best settings" are very much related to the entire architecture of your physical simulation, game mechanics/rules, and distribution of players. Some games use TCP for control signals and UDP for faster, but less critically important data.
Lastly, as for re-inventing the wheel, there are actually plenty of vetted libraries that implement error checking, quality of service, etc for UDP while still retaining the configurability and real-time/games focus that TCP doesn't allow.
The majority of the industry runs on UDP. That's not an accident--especially when the majority of college students / outsiders don't know anything about UDP and focus on TCP in their studies. Different application, different tool for the job. When you're sending banking information you need to know it got there or didn't. When you're updating someone's head direction in a FPS game, you can tolerate huge amounts of inconsistency between players when the connection starts degrading.
This is an extremely optimized, important aspect of game programming. I would be very careful to suggest everyone is spending thousands of hours re-inventing the wheel for no reason--especially in the ultra-time-constrained game industry.
https://gafferongames.com/post/udp_vs_tcp/
>Unfortunately, [...] TCP still has serious problems for multiplayer games and it all stems from how TCP handles lost and out of order packets to present you with the “illusion” of a reliable, ordered stream of data. [goes on to explain issues]
When you implement your own error and ordering stack, you are in control of how and when to drop a packet or consider the packet too out-of-date. These "best settings" are very much related to the entire architecture of your physical simulation, game mechanics/rules, and distribution of players. Some games use TCP for control signals and UDP for faster, but less critically important data.
Lastly, as for re-inventing the wheel, there are actually plenty of vetted libraries that implement error checking, quality of service, etc for UDP while still retaining the configurability and real-time/games focus that TCP doesn't allow.
The majority of the industry runs on UDP. That's not an accident--especially when the majority of college students / outsiders don't know anything about UDP and focus on TCP in their studies. Different application, different tool for the job. When you're sending banking information you need to know it got there or didn't. When you're updating someone's head direction in a FPS game, you can tolerate huge amounts of inconsistency between players when the connection starts degrading.