3 ms·

> I'd like to read some articles by game developers giving examples of their protocol and where UDP was useful and where multiple tuned TCP connections wouldn't

by exDM69 13y ago

> I'd like to read some articles by game developers giving examples of their protocol and where UDP was useful and where multiple tuned TCP connections wouldn't have been enough. Here's some articles from professional game developers that contain war stories about networked game programming. Unfortunately they are quite old and you might have already read these. I would love to see some newer ones. This is the article referenced in the OP. The author of this wrote network code for some MechWarrior games. You can find more of his articles/talks with some war stories: http://gafferongames.com/networking-for-game-programmers/ http://gafferongames.com/networking-for-game-programmers/ This is pretty old but talks about real world networking issues that are still relevant today. In particular, they mention having TCP retransmission causing about one minute of latency. That figure has improved but not gone away since those times. "The Internet Sucks: Or, What I Learned Coding X-Wing vs. TIE Fighter": http://www.gamasutra.com/view/feature/131781/the_internet_sucks_or_what_i_.php?page=1 http://www.gamasutra.com/view/feature/131781/the_internet_su... The two articles above both recommend using UDP (or at least regret using TCP). For a contrast, here's one about using TCP in a "real time" strategy game. "1500 Archers on a 28.8: Network Programming in Age of Empires and Beyond": http://www.gamasutra.com/view/feature/3094/1500_archers_on_a_288_network_.php http://www.gamasutra.com/view/feature/3094/1500_archers_on_a... The best conclusion we can draw is that the decision between TCP and UDP is a very application specific and advocating one over the other for all use cases is harmful.

Thaxll 13y ago
That was 13 years ago... networks / algo / network programming changed a lot since that time.
- exDM69 13y ago
  > That was 13 years ago... networks / algo / network programming changed a lot since that time. Yes, a lot has changed but a lot has stayed the same. In particular, the speed of light is still the same that it used to be and the optimal round trip time across the world hasn't improved. Not a lot has changed with the fundamental nature of TCP or UDP either. All of the articles I linked have valuable lessons that are still valid today. Also some stuff that isn't really relevant today. But yeah - I'd love to see more recent articles on the subject.
  - CocaKoala 13y ago
    Mauve wrote some interesting articles [1] back in 2012 on the roll-back principle being used in GGPO, which is a (semi) popular netcode used for fighting games. In the likely event that you don't play fighting games, I'll break down briefly the needs of the genre. Fighting games are almost always animated at 60 frames per second. Different moves will come out in a certain number of frames, be active for a certain number of frames, and have recovery animation for a certain number of frames. When you have all of that information for a character, it's called (unsurprisingly) "frame data". Let's say you and your opponent are standing right next to each other. You press light punch, and he presses heavy punch, and it turns out that he was just a little faster and pressed his punch button a tenth of a second before you did; that's six frames. HOWEVER, his heavy punch is a really slow button; it has ten frames of startup animation before the punch even comes out! Your light punch is much faster; it comes out in only 3 frames. So he hits punch, six frames pass, and then you press punch as well. Three more frames pass, and your punch is active, but he's still in the startup animation. So even though he hit a button well before you did, you're actually hitting him first. There's a lot more to the strategy (if your punch hits him, he's going to go into some kind of hit animation; how long does that last? If you can get another attack to come out and hit him before that animation ends, then there's no way for him to block the second attack; this is the basis behind the concept of a combo in fighting games. Interestingly, it was initially a bug in Street Fighter 2.) but for the purposes of networking, all you need to understand is that frames are crucially important to a fighting game, there need to be sixty of them a second, and delaying even one or two frames can make the different between counterhitting your opponent with a light, or getting counterhit yourself with a heavy. It's worth clicking around on a couple of Mauve's posts, because they tend to be pretty interesting. [1]: http://mauve.mizuumi.net/2012/07/05/understanding-fighting-game-networking/ http://mauve.mizuumi.net/2012/07/05/understanding-fighting-g...

by exDM69 13y ago

Thaxll 13y ago

That was 13 years ago... networks / algo / network programming changed a lot since that time.

exDM69 13y ago
> That was 13 years ago... networks / algo / network programming changed a lot since that time. Yes, a lot has changed but a lot has stayed the same. In particular, the speed of light is still the same that it used to be and the optimal round trip time across the world hasn't improved. Not a lot has changed with the fundamental nature of TCP or UDP either. All of the articles I linked have valuable lessons that are still valid today. Also some stuff that isn't really relevant today. But yeah - I'd love to see more recent articles on the subject.
- CocaKoala 13y ago
  Mauve wrote some interesting articles [1] back in 2012 on the roll-back principle being used in GGPO, which is a (semi) popular netcode used for fighting games. In the likely event that you don't play fighting games, I'll break down briefly the needs of the genre. Fighting games are almost always animated at 60 frames per second. Different moves will come out in a certain number of frames, be active for a certain number of frames, and have recovery animation for a certain number of frames. When you have all of that information for a character, it's called (unsurprisingly) "frame data". Let's say you and your opponent are standing right next to each other. You press light punch, and he presses heavy punch, and it turns out that he was just a little faster and pressed his punch button a tenth of a second before you did; that's six frames. HOWEVER, his heavy punch is a really slow button; it has ten frames of startup animation before the punch even comes out! Your light punch is much faster; it comes out in only 3 frames. So he hits punch, six frames pass, and then you press punch as well. Three more frames pass, and your punch is active, but he's still in the startup animation. So even though he hit a button well before you did, you're actually hitting him first. There's a lot more to the strategy (if your punch hits him, he's going to go into some kind of hit animation; how long does that last? If you can get another attack to come out and hit him before that animation ends, then there's no way for him to block the second attack; this is the basis behind the concept of a combo in fighting games. Interestingly, it was initially a bug in Street Fighter 2.) but for the purposes of networking, all you need to understand is that frames are crucially important to a fighting game, there need to be sixty of them a second, and delaying even one or two frames can make the different between counterhitting your opponent with a light, or getting counterhit yourself with a heavy. It's worth clicking around on a couple of Mauve's posts, because they tend to be pretty interesting. [1]: http://mauve.mizuumi.net/2012/07/05/understanding-fighting-game-networking/ http://mauve.mizuumi.net/2012/07/05/understanding-fighting-g...