> It would greatly improve the networking of these games.
This is not accurate, i know it's like a rule of thumb that UDP is faster than TCP, but that's naive, there are cases where UDP will end up being slower, and to be honest, it depends on lots of variables, and at many times, the congestion control, packet ordering and all the bells and whistles that comes with TCP is well worth the little performance penalty, assuming that in that specific case it actually is slower than UDP
And of course if I'm wrong, someone will let me know :D
UDP provides massively better quality of service for realtime data wherein there aren't usually dependencies between particular pieces of data.
For example, if you are transmitting the position of some guy in a world, N times per second ... and you drop one particular packet ... that's fine, you just get the next one and you have more up-to-date information anyway.
TCP will block the entire connection when that packet is dropped, waiting until it is received again, and not giving any of the subsequent information to the application. This is bad in THREE different ways: (1) By the time the new position is received, it is old and we don't care about it any more anyway; (2) Subsequent position data was delayed waiting on that retransmit and now most of that data is junk too, EVEN THOUGH WE ACTUALLY RECEIVED IT IN TIME AND COULD HAVE ACTED ON IT, but nobody told the application; (3) Other data on the stream that had nothing to with the position was similarly delayed and is now mostly junk too (for example, positions of other guys in totally other places in the world).
It is hard to overstate how bad TCP is for this kind of application.
You are absolutely correct, but not all games are FPSes, I just think that the generalisation in the premise that UDP is better than TCP for networked games is naive, you have to put into consideration the type of game and what data is actually being sent.
What I said is true for almost every kind of game. POV of the camera has nothing to do with it.
The main exception is low-number-of-player token-ring style games like RTSs with tons of units. Those usually simulate in lockstep, with the full state of the world extrapolated from inputs that consist of a very small amount of data. This means network traffic is relatively low, but in order for this to work you have to have complete knowledge of everything and exactly when it happened, which means no packet loss can be accepted and everything must be processed in order. So then you have the same kinds of problems as with TCP (even if the underlying transmission is via some other protocol) ... thus these games operate with some large amount of latency to hide these problems.
But, this network design is only the case for a minority of games. Just about any modern multiplayer game that is drop-in/drop-out, where the developers really care about quality of experience, is better off going UDP. (This is not to say that developers always do the best thing, since it's much easier to just say screw it and talk over TCP and call it a day. The temptation to do this is heightened because of all kinds of problems with NAT punchthrough and whatnot; because so much traffic is Web-oriented these days lots of routers mainly care about that, which causes all kinds of interesting annoyances. Thus games that do talk over UDP generally fall back to TCP if they are unable to initiate a UDP connection).
Well, there is one other case of games that run in lockstep, which is when they are console games made by developers who want to avoid incurring the costs of running servers (which are often much higher on consoles because the platform holder charges you out the nose). When you are running in lockstep like that it is more like the RTS scenario above, and thus it doesn't matter much if you use TCP because you are already taking the quality hit. But this is a cost-cutting kind of decision, not an it's-best-for-gameplay kind of decision.
P.S. It's not a good idea to call someone naive about a subject where you yourself may not know enough to correctly judge naivete.
> What I said is true for almost every kind of game. POV of the camera has nothing to do with it.
You misundrestood what I'm talking about, I'm not talking about the camera position, I'm talking about different games like turn based games, chess, board games, etc..
Lockstep is out of the scope here, surely not needed in a chess game. I'm talking deterministic games here.
> What I said is true for almost every kind of game. POV of the camera has nothing to do with it.
Again, out of scope, I'm saying UDP is not the answer to all games and the assumption that if a game is networked then you should go with UDP is naive as I'm trying to say, forget open world, forget FPS, think about a simple turn based game.
> P.S. It's not a good idea to call someone naive about a subject where you yourself may not know enough to correctly judge naivete.
Where did I call anyone naive ? thre's a difference saying you're naive and saying "the assumption is naive" I do believe i know enough that's why I'm commenting in the first place, even though I stated I might be wrong about some points, I did not personally call anyone names, go back and read my comments.
What people usually want is all the bells and whistles of TCP without the occasional huge latency spike introduced by the guaranteed ordered packet delivery to the application layer.
Unfortunately, all the alternatives (SCTP etc etc) seem to have foundered, probably due to aggressive filtering by border routers/firewalls making it impossible for alternative protocols to gain traction.
Exactly my point about the whole "many variables involved", many networks still filter UDP as you say, which is really bad if you want to make sure everyone can use your game
SCTP droped 100% time as there no proper PNAT available for it. To make traction other protocols there need "happy eyeballs for transport" so it can be transparent for end-users
You are wrong, I would attack your argument if you gave one beyond that TCP has some convenient features but you didn't. So all I have to say is that you should try playing slitherio agario on an internet connection that isn't in a metropolitan area.
I'm surely wrong at many things yes, but you are also wrong at some points, if i play a game in a bad network setting, UDP will still be a bad option, packets will be probably very mangled on a bad network and will offer no superiority over TCP, you will see more blockage on TCP, but you will probably also see your player jump all over the place with UDP coming in totally out of order, and if you implement your own way of reordering packets, then you are almost reimplementing TCP over UDP again. if a network is bad, it's bad no matter what networking protocol you'll be using.
The only thing that makes UDP faster is that it comes without TCP's convenience features, and for many games, this is more than enough and the performance penalty is not usually worth it (unless you're a AAA with lots of resources and dedicated team just for the networking part)
besides that if you simply opt-in to UDP because it's better, then you'll spend much more time working on the network than actually working on the game.
my problem was with the generalisation in the premise, that `UDP is better than TCP for networked games`, this is not the case for a deterministic game of chess or any card/board game.
UDP's only point in this article is realtime data intensive games like FPS'es.
also I'm not putting security into consideration in this argument.
then you are almost reimplementing TCP over UDP again
you implement TCP features only when you need them. player positions for example are not critical, you can miss some but your game would still work if you are interpolating things correctly. if your player position message gets lost, you don't need it anyway you only need the newest position. same goes for order of the packets, if you are not needing such a thing, your lost packets would delay everything in the game.
For these reasons, TCP suffers a lot more if the network is bad. You really don't need to be a AAA company to implement TCP features on UDP.
UDP's only point in this article is realtime data intensive games like FPS'es.
Well article says, as you quoted:
> It would greatly improve the networking of these games.
And 'these games' are he means real time games like agario. It is not a FPS but it is a real time game. There is no reason to use UDP if it is a turn based game, like a card game. But a real time is pretty much always would be better with UDP
Totally agree with you there, but player position criticality is not for me or you to decide, it's game dependant, my worries is not about dropped packets, but packets that are in the wrong order, only in a game where combat has to be precise I would say it's critical.
Yeah you don't need to be a AAA for sure, i was exaggerating a bit to make my point, what i'm trying to say is that newcomers to gamedev will end up struggling, TCP isn't easy, neither is UDP, without proper understanding of both protocols there will surely be mistakes made.
I do agree with the article 100%, I'm not saying in that use case that TCP is better, I'm just disagreeing with the premise as it's a bit vague and implies that you know what agar.io and slither.io are, I know both games and i know they're realtime, but there are people out there who don't know what they are, so I'm saying that just thinking that UDP is faster than TCP so it's best for networked games is naive, a better way to say it is just mentioning that this is for realtime games, better yet realtime games that can't allow network delays and are not critical, WOW for example uses TCP for some parts of the game that are not critical, where player position doesn't really affect the game, they end up with huge latency now and then, but the game is programmed in a way that some latency won't matter. in other cases they use UDP, that's also one of my reasons to say that UDP is not the only answer.
So yes, you are 100% right, and the article is 100% right, I just don't like the premise (the way it was written at least)
Everyone seems to miss the whole point of my comment up here, so here is what I was trying to say:
1- UDP is not always the answer, don't overcomplicate things, I'm trying to say that there are games like chess,board games, basically deterministic games that are not realtime. it is very wrong to use UDP for that game style, it's just a huge overkill.
2- UDP can in fact be slower for some use cases than TCP, there are lots of variables and unknowns.
3- Just opting into UDP because "it's faster" is very wrong, before jumping to UDP, there is a whole lot of networking theory that needs to be learned, and I'm not concerned about AAA here, I'm concerned about new beginners and indies that will read this post and think that this is the only right way to do things.
4- UDP is filtered on some networks still, you'll lose some players
5- If your network is so bad that TCP is not fast enough or that older packets are blocking newer ones, it'll be the same with UDP, packets will come in mangled and out of order, ant the game's "Quality" will still be bad with your avatar flying all over the place. until the developer implements a way to reorder packets, which is still more work.
6- I'm not a network professional, neither are lots of people. and if you don't have a strong knowledge to make sure your game's networking is in top shape you might end up making mistakes that will cost to fix.
7- The premise that UDP is going to greatly improve the game networking is naive (It's ok to call things naive by the way, don't be too sensitive) I'm a big fan of gafferongames, there are tons of great resources there, I'm only saying the premise is naive, not the person who wrote it. of course the author knows what they're talking about and I do understand they mainly target RTC and games like agar.io, I would want them to state more clearly that this is only valid for non deterministic, RTC, FPS, whatever you call it. for other cases, it's not the best.
8- Security wise, I'm not sure how easy it is to secrue a UDP conection, but it's surely not straightforward and easy as TCP with SSL for example.
Finally, there is never one true answer to your project's networking technology, lots of developers mix and match between TCP, UDP to get best of both worlds
I would just say use whatever works best for you as long as you have enough knowledge and good reasoning to back your decision on what to use!
> It would greatly improve the networking of these games.
This is not accurate, i know it's like a rule of thumb that UDP is faster than TCP, but that's naive, there are cases where UDP will end up being slower, and to be honest, it depends on lots of variables, and at many times, the congestion control, packet ordering and all the bells and whistles that comes with TCP is well worth the little performance penalty, assuming that in that specific case it actually is slower than UDP
And of course if I'm wrong, someone will let me know :D