Is it just me or is networking really hard?

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.

Perhaps if you're going for simplicity or something then that might be an ok idea, but he mentions those three because they are more modern or important additions to the Quake model. He is of course very aware of their Quake heritage, at the end of this article he credits John Carmack (in an indirect way).

I recommend reading the rest of Gaffer's articles before doing anything, it will give you a basis that's needed to understand why Quake does what it does.

Thanks very much for this, these are great articles.

It seems one would need some way of synchronizing clocks (or measuring the lag between server and client). Do you know if there is a standard way of accomplishing this?

Networking has local time, like the relativity theory. "Those two packets are at the same time at point a, but not point b." "A sends b and C sends d, but since time is local you cannot" etc.

So IMO it makes sense that networking is really hard. I like it though. Networking problems are clear when you think hard about them, unlike so many of today's programming problems, where the key is to know some half-documented aspect of a large framework/library/whatnot.

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.