World of Warcraft is a pretty slow-paced game on "the inside", it just looks like a fast real time game but it's almost turn based when you analyze the gameplay. When you cast a spell, you'll instantly see the animation that your character is casting the spell, but the actual effect comes only when the animation is complete. This animation is used to hide the network latency (other players might see the animation played back slightly faster to compensate for the lag). Further, once you cast the spell, it must succeed and you can't really do anything before it has completed. In other words, reliability is essential and latency can be hidden.

Contrast this with a fast paced, (soft) real time multiplayer game. When a player jumps, the jump has to start immediately. If you want to jump and shoot, the shots have to be fired right away, you can't wait for the jump to complete before shots are fired. With TCP, you'd be stuck on the ground until the "jump" packet is re-transmitted (two or more network round trips, tens to hundreds of milliseconds, very noticeable) and no shots would be fired until the character is off the ground.

In a real time game, old packets are next to useless. Re-transmitting is wasting bandwidth and causing lag by blocking on information that is no longer useful. The networking model (like OP describes) is a constant stream of packets containing redundant information, minimum latency is essential and loss of packets is tolerated.

You should be aware that TCP vs. UDP becomes apparent only when network conditions are bad. You could choose either and have satisfactory results 90% of the time, but once packets get lost, TCP does the wrong thing when it comes to fast paced real time games.

If you do take the time to read Gaffer's original article, you should see that it is different from TCP in many ways. Yes it does similar things (reliability, flow control, etc) but in a completely different manner, tuned for a completely different use case.

i forgot where i read this, but WoW is a bit of a special case because several issues were just circumvented through game design.

example 1: there's no collision detection between players, i.e. you can block neither PCs nor NPCs. players blocking each other wouldn't have been possible with TCP at all.

example 2: you don't aim and fire and hit/miss shots due to timing and precision (twitch) - you select a target and execute an action which is sent to the server which will roll a die to see the outcome. it was fairly usual for the early game to break down when a lot of players congregated in a small area (hogger or tarren mill, anyone?), where an instant spell took several seconds to execute and PCs were teleporting around (after running into a wall for several seconds) constantly because their positioning updates took too long. but because of the style of the gameplay this still worked well enough in most situations.

what i want to say is that wow worked around TCPs performance issues by adjusting the game design. i can't fathom the reason for this - it might have to do with their focus on low hardware and connectivity requirements (for countries with unreliable connections). but even then i don't see why TCP would have been the better choice.

Well, World of Warcraft does feel like moving in jello as compared to well optimized UDP-based games like Counter-Strike for instance. However, it does not matter for World of Warcraft very much.

Some games require less latency than others. WoW is a good example of a game that doesn't really have any precision combat. You don't have to aim at enemies there, you just have to lock them for your auto-target.

World of Warcraft can work with big latencies. He is talking about time critical games

Check out this presentation on UDT protocol:

http://udt.sourceforge.net/doc/udt-2009.ppt

It details the problems of TCP, names most alternatives, and describes UDT work. I used to use UDT to eliminate TCP's problems. It's just bad design and the fact that changing it is usually a kernel modification. Hence, all these application-level alternatives with UDT being most general-purpose and one of best.

Be interesting to see if someone can adapt it to games. For now, probably best to use game-specific model as in article and comments. UDT for other stuff where you control how the app works on both ends. TCP where you control one side.

A lot of games use TCP and it's perfectly fine. But if you are racing the network, fighting over every millisecond of latency, you should just use UDP.