6 ms·

TCP is very widely used by multiplayer gaming today. It turns out you can just tweak it a little bit and it works fine.

by RyanZAG 13y ago

stoptalkingshit 13y ago
It works just fine.. for non-realtime games (and has been widely used for such games since forever). I've done the tests - you cannot just "tweak" it, and even if you could you'd be relying on the networking stack to do something it's not intended to do.
- forrestthewoods 13y ago
  You might be surprised. World of Warcraft and Guild Wars 2 are both TCP. It's pretty common for MMOs. It can also work well for some types of RTS games where the added latency isn't a major issue.
  - deleted 13y ago
    [deleted]
  - lucian1900 13y ago
    They're not real-time, though, in the sense that a delayed message is as good as no message. The tolerance is high enough that a few delays usually don't affect gameplay.
- RyanZAG 13y ago
  All flash games use TCP (as you can't use UDP in flash). There are many realtime flash games. Many MMORPGs use TCP for compatibility reasons: they are very much real-time, especially something like PVP in world of warcraft, etc. Guild Wars also uses TCP and is very much a 'twitch' based realtime game as well.
  - shultays 13y ago
    PVP in mmos are hardly real time.
    - RyanZAG 13y ago
      Spell interruption in warcraft? Also first youtube video for 'guild wars 2 pvp' : https://www.youtube.com/watch?feature=player_detailpage&v=KRcTKt47ixk#t=265 https://www.youtube.com/watch?feature=player_detailpage&v=KR... Looks like real time to me.
      - shultays 13y ago
        Didn't play much wow but aren't spell cast times like 2-3 secs in wow? Even with a 0.5-1 sec delay, it would be playable. Never played guild wars Maybe my definition of real time is incorrect. But you don't point and click in MMOs generally, it is all aoe spells or targetted abilities. There are big margins of time or spell aoe to overcome delays of network packets.
        Luyt 13y ago
        Spells vary in casting time. Many spells are instant.
        m_mueller 13y ago
        - and the instant ones aren't interruptible I guess? People, I don't even get what you're discussing here. That TCP should be fine for any game's network code because it works for WoW?
        Glide 13y ago
        1.5 second cast times with abilities to push that down to around 1.0s. A lot of the interrupts are off the global cooldown in order for players to use spell interrupts effectively. .5 - 1 seconds of delay may not seem like much, but it actually adds up to be quite significant because of the global cooldown would also be enforce client side and so a player with higher delay would have done fewer actions in the same amount of time.
  - stoptalkingshit 13y ago
    World of Warcraft is not a "twitch" game. Ever multi-screened it? Why make all this stuff up? This may surprise you, but Flash games don't set the standard for quality network code.
nhaehnle 13y ago
I can confirm this, having been mostly responsible for the network code in Widelands. We exclusively used TCP with parallel simulation (i.e., only player actions are transmitted), and it worked just fine as early as 2007 even without any special tweaks. There are two factors that matter, I believe: First, Widelands is a real-time game but with a slow pace, so relatively high latency is easy to tolerate. Second, the internet is simply more reliable today than it was 15 years ago, especially if the bandwidth that you use is small relative to the Mb/s connections that are common today.
- willvarfar 13y ago
  The players were on 28K modems; it was a very different world before broadband even.
- exDM69 13y ago
  > First, Widelands is a real-time game but with a slow pace, so relatively high latency is easy to tolerate. Second, the internet is simply more reliable today than it was 15 years ago, especially if the bandwidth that you use is small relative to the Mb/s connections that are common today. Exactly. TCP is fine if you can tolerate 3-5 round trip times' worth of latency. RTT to the other side of the world is ~135 milliseconds at the speed of light. That's roughly one second of latency for a less than optimal network connection. Probably just fine for an RTS game or a not quite real time MMO. It is not, however, good enough for fast paced FPS games, racing sims or (space) flight sims. They will keep on working better with UDP as long as there will be latency and packet loss in the Internet.
- mcguire 13y ago
  Did you use a server, rather than peer-to-peer communications between players?
  - nhaehnle 13y ago
    One of the players acted as a server, though this was actually more to avoid the headaches associated with NAT rather than for bandwidth reasons.
prewett 13y ago
What tweaks should one use?
- laichzeit0 13y ago
  The only way I know to reduce latency at the socket API level is by turning off the Nagel algorithm (TCP_NODELAY). I'm not sure what else you can do without breaking portability or tweaking OS parameters.
  - astrobe_ 13y ago
    ... and that's the crux of the problem. TCP is good enough for the large majority of not-too-demanding use cases. But in some corner cases it becomes more of a problem than a solution, because it is more or less a black box; one has very little control over the number of repetitions (sometimes it's even advantageous not to repeat), the repetition timings, the window sizes, etc. In these corner-case situations you prefer UDP because you have better control on what happens. Also if you work with some obscure TCP/IP stack implementations you wouldn't bet your life on (that happens in the embedded world), and that you don't feel like debugging, or if datagrams are more convenient than streams for your app(sometimes new programmers are surprised to receive one packet when they sent two - or the other way round), UDP doesn't look that bad at all. I read once a rant that argued half-jokingly that TCP is useless, because in the end the services it offers are redone at application level. Repetition? most applications do retry a failed operation? Acknowledgement? Ditto. Encryption? Same.
    - mcguire 13y ago
      There are, of course, a [heap; I originally wrote "stack"] of reasonably standard protocols other than TCP and UDP with behavior that may be more appropriate for games; many are based on top of UDP. RDP comes to mind, although it's not much of a protocol itself. > I read once a rant that argued half-jokingly that TCP is useless, because in the end the services it offers are redone at application level. Half-jokingly? Essentially all services provided at "layers" below the application are, at best, performance optimizations. See the End-to-end argument.[1] [1] http://en.wikipedia.org/wiki/End-to-end_principle http://en.wikipedia.org/wiki/End-to-end_principle (or the Saltzer/Reed/Clark paper; it's very good: http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf http://web.mit.edu/Saltzer/www/publications/endtoend/endtoen...)
pilif 13y ago
Also, nowadays, there are (usually) no more slow and brittle dialup modems in place any more. A connection without packet loss is way more common these days than one with. This makes TCP much more feasible (and sometimes necessary as getting UDP packets through various NAT routers can be difficult). Back then, they were probably right to use UDP, but I found it funny how all the reasons they gave why TCP sucked were things their workarounds were equally bad at.
- JPKab 13y ago
  All of this engineering and technical analysis is wonderful and interesting, but it doesn't change the fact that Lucas Arts sold this game for a big chunk of change to my teenage self (I did farm work to earn my money) and it was a HUGE, DISAPPOINTING RIPOFF. The single player AND multi-player aspects of the game were shit. It was rushed to production by the publisher and it showed. I realize that it was a huge technological leap for early 1997, I really do. But the product was shit and we paid good money for it. Edit: I meant to add something. 11 months after XvT was released, Volition Software released Descent: Freespace. It was everything that XvT should have been. Nobody noticed it but whatever. (I admit I'm probably being unfair since the internet was changing so fast back then)
- nknighthb 13y ago
  I haven't used a dial-up modem since ~1999, and have had 7 different connections in 6 different cities on the west coast in that time. ~0.5-3% packetloss has never stopped rearing its head, especially during prime time. If you've got a magic source of packetloss-free last-mile connections, I'd love to hear about it.
  - pilif 13y ago
    I live in switzerland and I have been using DSL and tv cable modems since 2001 and I never had packet loss (unless there was something broken on the providers end and subsequently fixed by them - this was something that lasted for maybe a day or two)
    - 13y ago

TCP is very widely used by multiplayer gaming today. It turns out you can just tweak it a little bit and it works fine.

by RyanZAG 13y ago

TCP is very widely used by multiplayer gaming today. It turns out you can just tweak it a little bit and it works fine.

It works just fine.. for non-realtime games (and has been widely used for such games since forever). I've done the tests - you cannot just "tweak" it, and even if you could you'd be relying on the networking stack to do something it's not intended to do.

forrestthewoods 13y ago
You might be surprised. World of Warcraft and Guild Wars 2 are both TCP. It's pretty common for MMOs. It can also work well for some types of RTS games where the added latency isn't a major issue.
- deleted 13y ago
  [deleted]
- lucian1900 13y ago
  They're not real-time, though, in the sense that a delayed message is as good as no message. The tolerance is high enough that a few delays usually don't affect gameplay.
RyanZAG 13y ago
All flash games use TCP (as you can't use UDP in flash). There are many realtime flash games. Many MMORPGs use TCP for compatibility reasons: they are very much real-time, especially something like PVP in world of warcraft, etc. Guild Wars also uses TCP and is very much a 'twitch' based realtime game as well.
- shultays 13y ago
  PVP in mmos are hardly real time.
  - RyanZAG 13y ago
    Spell interruption in warcraft? Also first youtube video for 'guild wars 2 pvp' : https://www.youtube.com/watch?feature=player_detailpage&v=KRcTKt47ixk#t=265 https://www.youtube.com/watch?feature=player_detailpage&v=KR... Looks like real time to me.
    - shultays 13y ago
      Didn't play much wow but aren't spell cast times like 2-3 secs in wow? Even with a 0.5-1 sec delay, it would be playable. Never played guild wars Maybe my definition of real time is incorrect. But you don't point and click in MMOs generally, it is all aoe spells or targetted abilities. There are big margins of time or spell aoe to overcome delays of network packets.
      - Luyt 13y ago
        Spells vary in casting time. Many spells are instant.
        m_mueller 13y ago
        - and the instant ones aren't interruptible I guess? People, I don't even get what you're discussing here. That TCP should be fine for any game's network code because it works for WoW?
      - Glide 13y ago
        1.5 second cast times with abilities to push that down to around 1.0s. A lot of the interrupts are off the global cooldown in order for players to use spell interrupts effectively. .5 - 1 seconds of delay may not seem like much, but it actually adds up to be quite significant because of the global cooldown would also be enforce client side and so a player with higher delay would have done fewer actions in the same amount of time.
- stoptalkingshit 13y ago
  World of Warcraft is not a "twitch" game. Ever multi-screened it? Why make all this stuff up? This may surprise you, but Flash games don't set the standard for quality network code.

nhaehnle 13y ago

I can confirm this, having been mostly responsible for the network code in Widelands. We exclusively used TCP with parallel simulation (i.e., only player actions are transmitted), and it worked just fine as early as 2007 even without any special tweaks. There are two factors that matter, I believe: First, Widelands is a real-time game but with a slow pace, so relatively high latency is easy to tolerate. Second, the internet is simply more reliable today than it was 15 years ago, especially if the bandwidth that you use is small relative to the Mb/s connections that are common today.

willvarfar 13y ago
The players were on 28K modems; it was a very different world before broadband even.
exDM69 13y ago
> First, Widelands is a real-time game but with a slow pace, so relatively high latency is easy to tolerate. Second, the internet is simply more reliable today than it was 15 years ago, especially if the bandwidth that you use is small relative to the Mb/s connections that are common today. Exactly. TCP is fine if you can tolerate 3-5 round trip times' worth of latency. RTT to the other side of the world is ~135 milliseconds at the speed of light. That's roughly one second of latency for a less than optimal network connection. Probably just fine for an RTS game or a not quite real time MMO. It is not, however, good enough for fast paced FPS games, racing sims or (space) flight sims. They will keep on working better with UDP as long as there will be latency and packet loss in the Internet.
mcguire 13y ago
Did you use a server, rather than peer-to-peer communications between players?
- nhaehnle 13y ago
  One of the players acted as a server, though this was actually more to avoid the headaches associated with NAT rather than for bandwidth reasons.

prewett 13y ago

What tweaks should one use?

laichzeit0 13y ago
The only way I know to reduce latency at the socket API level is by turning off the Nagel algorithm (TCP_NODELAY). I'm not sure what else you can do without breaking portability or tweaking OS parameters.
- astrobe_ 13y ago
  ... and that's the crux of the problem. TCP is good enough for the large majority of not-too-demanding use cases. But in some corner cases it becomes more of a problem than a solution, because it is more or less a black box; one has very little control over the number of repetitions (sometimes it's even advantageous not to repeat), the repetition timings, the window sizes, etc. In these corner-case situations you prefer UDP because you have better control on what happens. Also if you work with some obscure TCP/IP stack implementations you wouldn't bet your life on (that happens in the embedded world), and that you don't feel like debugging, or if datagrams are more convenient than streams for your app(sometimes new programmers are surprised to receive one packet when they sent two - or the other way round), UDP doesn't look that bad at all. I read once a rant that argued half-jokingly that TCP is useless, because in the end the services it offers are redone at application level. Repetition? most applications do retry a failed operation? Acknowledgement? Ditto. Encryption? Same.
  - mcguire 13y ago
    There are, of course, a [heap; I originally wrote "stack"] of reasonably standard protocols other than TCP and UDP with behavior that may be more appropriate for games; many are based on top of UDP. RDP comes to mind, although it's not much of a protocol itself. > I read once a rant that argued half-jokingly that TCP is useless, because in the end the services it offers are redone at application level. Half-jokingly? Essentially all services provided at "layers" below the application are, at best, performance optimizations. See the End-to-end argument.[1] [1] http://en.wikipedia.org/wiki/End-to-end_principle http://en.wikipedia.org/wiki/End-to-end_principle (or the Saltzer/Reed/Clark paper; it's very good: http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf http://web.mit.edu/Saltzer/www/publications/endtoend/endtoen...)

pilif 13y ago

Also, nowadays, there are (usually) no more slow and brittle dialup modems in place any more. A connection without packet loss is way more common these days than one with. This makes TCP much more feasible (and sometimes necessary as getting UDP packets through various NAT routers can be difficult). Back then, they were probably right to use UDP, but I found it funny how all the reasons they gave why TCP sucked were things their workarounds were equally bad at.

JPKab 13y ago
All of this engineering and technical analysis is wonderful and interesting, but it doesn't change the fact that Lucas Arts sold this game for a big chunk of change to my teenage self (I did farm work to earn my money) and it was a HUGE, DISAPPOINTING RIPOFF. The single player AND multi-player aspects of the game were shit. It was rushed to production by the publisher and it showed. I realize that it was a huge technological leap for early 1997, I really do. But the product was shit and we paid good money for it. Edit: I meant to add something. 11 months after XvT was released, Volition Software released Descent: Freespace. It was everything that XvT should have been. Nobody noticed it but whatever. (I admit I'm probably being unfair since the internet was changing so fast back then)
nknighthb 13y ago
I haven't used a dial-up modem since ~1999, and have had 7 different connections in 6 different cities on the west coast in that time. ~0.5-3% packetloss has never stopped rearing its head, especially during prime time. If you've got a magic source of packetloss-free last-mile connections, I'd love to hear about it.
- pilif 13y ago
  I live in switzerland and I have been using DSL and tv cable modems since 2001 and I never had packet loss (unless there was something broken on the providers end and subsequently fixed by them - this was something that lasted for maybe a day or two)
  - 13y ago