This page will describe the way movement is networked in the World of Warcraft game (patch 3.3.5. Other versions of the game are currently out of scope from the page). It aims to be as exhaustive as possible. You are welcomed to contribute by adding any missing information or correcting any error. However, please let's talk on changes beforehand, in the comment section.

First things to know about WoW :
* The game works following a server - client model
* The server is authoritative on most things (for the reason being that it's very hard to prevent cheatting in non-authoritative games)

In order to make movements in the game a smooth experience for players, WoW uses and combines several industry-established technics:

Client side prediction (cf [1], [2], [4] for definitions)

How do we know this?

Independently of our current latency with the server (50ms or even 1000ms), almost as soon as we press the key to move forward, our character starts to move. In other words, the physics simulation is locally run on the client. Motions of our character don't wait for any acknowledgements from the server before they are visible on our client. This gives movement in the game an immediate feedback response feeling.

* One thing currently unknown however is if the server also runs its own simulation of player-controlled units (including collisions with walls and other static elements of the map). And if it does, is there a mechanism of "reconciliation" put in place ?

Current observations based on packet exchanges analysis, black box testing & client de compiling would indicate that no, there is no such thing. Clients seem to run the entire physic simulation for the character that they own. And in their simulation, clients also take into account all external factors sent by the server such as dynamic collisions or temporarily forces (example: a knock-back spell. or a dynamically removed floor such as in the Lich King encounter). This makes the client authoritative about the player's movement. The advantage of this technic is that it lowers the computation burden on the server and it is much simpler to implement (no need to run the physic simulation of each player on the server, then send the movement state to the client and do a client side reconciliation [1]). The major downside is that it's very exploitable by cheaters.

Client side extrapolation (aka dead reckoning) for player controlled units (cf [3] for more details)

How do we know this?

By looking at the movement packets sent by the client. The movement of players is sent in discret steps. The client only sends a packet on player's direction or speed change (or on heatbeat). The client of "observers" can then extrapolate the movement of the "mover" only using position, direction & speed.

Client side interpolation for server controlled units (including CCed players such as players affected by sheep or fear).

How do we know this?

By looking at the SMSG_ON_MONSTER_MOVE packets sent by the server. They include the spline that describes the trajectory that the unit must follow. When we send this kind of packet to the client and if it is properly constructed, we will see the unit follow the trajectory described by the packet.

Anti jitter buffer (also known as client side buffer or buffer-on-receipt) (cf [5] for more details)

How do we know this?

Each movement packets sent by the client to the server include a time-stamp. This time-stamp (after conversion to server time) along with the rest of the packet is then retransmitted to the other clients. By adding some delay to this time-stamp, its easy to see that "movement events" can be played at a later time than when they are received. At time of writing (2019-01-20), the duration of that buffer is currently assumed to be 500ms. However, no definite proof has been found on that.

time synchronization between the server and the clients (cf [6] and the SNTP protocol for more details)

How do we know this?

Using a buffer implies transmitting time-stamp of events to know when they should be played. However, clocks on different computers are known to drift apart over time. Therefore, it is necessary to implement a method to keep the clocks in sync. One important to mention however is that in WoW, client clocks are actually not synced. Instead, the server just keep track of the clock drift between its own lock and each of the clients. This can be proved by the fact that its the server (and not the clients) that initiate a SNTP-like packet exchange to compute the clock drift.

[1] http://www.gabrielgambetta.com/client-side-prediction-server-reconciliation.html

[2] https://gamedevelopment.tutsplus.com/articles/gamedev-glossary-what-is-client-side-prediction--gamedev-3849

[3] https://www.gamasutra.com/view/feature/131638/dead_reckoning_latency_hiding_for_.php

[4] https://gafferongames.com/post/what_every_programmer_needs_to_know_about_game_networking/

[5] https://gafferongames.com/post/state_synchronization/ at "Jitter Buffer" section

[6] https://web.archive.org/web/20180121081303/https://www.mine-control.com/zack/timesync/timesync.html

Recommended resources:

Development & Deployment of Multiplayer Online Games Vol. I by "No Bugs Hare" covers most of the technics mentioned here. It is available on Amazon. Great book. I highly recommended it.

Navegador incompatible