TCP is very widely used by multiplayer gaming today. It turns out you can just tweak it a little bit and it works fine.
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.
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.
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)
But in real world scenarios there are lots of reasons for packet loss, congestion being the most important. Have your little brother turn on a bit torrent client on a DSL line when you're playing counter strike and you will experience packet loss for sure.
Your understanding of TCP is wrong. Packet loss is a natural part of the process. When a link is saturated, a router should drop packets and notify the sender to slow down.
When ISPs engineer their networks to not drop packets they add larger buffers, packets wait at the last hop and instead of high speed you get high latency. Games lag at the expence of bandwidth.
Read up about buffer bloat.
Games should use UDP, as its not important if 0.5% of position updates don't get through, but it is important the get through quickly.
I have yet to see anything designed with UDP instead of TCP that didn't end up reimplementing TCP itself, poorly.
I'm not sure what else you can do without breaking portability or tweaking OS parameters.
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.
> 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 (or the Saltzer/Reed/Clark paper; it's very good: http://web.mit.edu/Saltzer/www/publications/endtoend/endtoen...)
Looks like real time to me.
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.
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?
.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.
Your spell interruption example illustrates it perfectly - spells can be interrupted if the interrupt is within the 1-2s cast time of the spell. It's adjudicated on server side, where the server knows the spellcast start and sends feedback on the spell results (including if any interrupts happened). If there is minimal delay then it works without being noticed; however when I had significant packet loss, then the spellcasting would 'end' for me only after the response (including check if it was interrupted) was received, and it could be multiple seconds later.
The point is, that WoW can mostly function if the orders and feedback are received with delays, since if some opponent in reality(server) is somewhere else than I see, then it usually doesn't change anything - but for a rapid movement FPS game, that would change hits to misses which is the core of that game.