On the other hand, to misquote Philip Greenspun, any sufficiently complicated UDP-based protocol contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of TCP.
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.
> any sufficiently complicated UDP-based protocol contains an ad-hoc, informally-specified, bug-ridden, slow implementation of half of TCP
Assuming that's true, that doesn't change the fact that TCP is unusable for real-time gaming.
So the solution sounds like a formally specified, bug tested, and fast implementation of half of TCP, as long as it's not the half that breaks soft real-time gaming.
Only for the twitchiest of twitch games really needs lower latency than TCP provides. So many amateur/indie game devs waste huge amounts of time messing with UDP because "everyone knows TCP isn't realtime" when TCP would have been perfectly suitable for their game.
Completely disagreed. If you're amateur/indie, use a premade engine that has networking. If the engine's networking isn't good enough for what you need, there are probably some options on the store that meet your needs.
Experience doesn't agree with this however. Pretty much every game engine in existence has a well-tested UDP-based networking stack, without which low-latency game play simply wouldn't be possible. The other thing this statement ignores is that TCP currently has serious issues which I would call performance bugs, so it isn't even setting the bar particularly high.
