Also, the reason many don't use TCP is that while it guarantees ordering and packet arrival people completely forget that it's doing that by adding an indeterminate amount of latency. It's not some "packets arrive perfectly / user different pipes, because [magic]" solution.
SCTP provides a nice protocol that gets you the best of both worlds in many ways between TCP and UDP. It features:
- hybrid reliable and unreliable, ordered and unordered delivery semantics
- automatic MTU fragmenting, to avoid router fragmentation
- ordered multi-channel multiplexing
Unfortunately SCTP never took off, but it is the data channel protocol for WebRTC, which uniquely positions WebRTC as a nice platform for game networking in the browser. (However, the stack must be implemented in user space since it is SCTP over DTLS over UDP.)
We are working on a WebRTC based game networking server for Social Mixed Reality at Mozilla which uses the Janus WebRTC gateway as the connection manager, our initial work can be found here:
Our initial SFU plugin for Janus already out of the box makes it easy to set it up as a dumb game networking server that just relays messages between peers, but our plan is to turn it into a connection manager in front of an OTP service that provides full authoritative game networking services.
Whatever happened to the BananaBread Engine demo that was supposed to show off WebRTC based game networking? Now the only public demo is single player. A twitch FPS shooter pushes networking more than a social chat room.
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.
The complaint was confusing to me because it didn't call out where the error was. The word "use" appears early on, so it looked like the complaint was incorrectly calling out a disagreement in plurality.
(Didn't downvote, but I did spent a good minute trying to parse the problem.)
https://www.gamasutra.com/view/feature/131577/halflife_and_t...
Also, the reason many don't use TCP is that while it guarantees ordering and packet arrival people completely forget that it's doing that by adding an indeterminate amount of latency. It's not some "packets arrive perfectly / user different pipes, because [magic]" solution.