這個過程用 udp 協議做比用 tcp 協議來的好。因為 tcp 協議可能因為丟包重發引起教大誤差，而 udp 則是自己控制，這個誤差要小的多。只是，現在網絡游戲用 tcp 協議實現要比 udp 有優勢的多，我們也不必為對時另起一套協議走 udp 。

一般的解決方法用多次校對就可以了。因為，如果雙方時鐘快慢一致的情況下，對時包在網絡上行程時間越短，就一定表明誤差越小。這個誤差是不會超過包來回時間的一半的。我們一旦在對時過程中得到一個很小的行程時間，并在我們游戲邏輯的時間誤差允許范圍內，就不需要再校對了。

或者校對多次，發現網絡比較穩定（雖然網速很慢），也可以認為校對準確。這種情況下，潛在的時間誤差可能比較大。好在，一般，我們在時間敏感的包上都會攜帶時間戳。當雙方時間校對誤差很小的時候，client 發過來的時間戳是不應該早于 server 真實時刻的。（當時間校對準確后，server 收到的包上的時間戳加上數據包單行時間，應該等于 server 當前時刻）

一旦 server 發現 client 的包“提前”收到了，只有一種解釋：當初校對時間時糟糕的網絡狀態帶來了很多的時間誤差，而現在的網絡狀態要明顯優于那個時候。這時，server 應該勒令 client 重新對時。同理，client 發現 server 的數據包“提前”到達，也可以主動向 server 重新對時。

一個良好的對時協議的設定，在協議上避免 client 時間作弊（比如加速器，或者減速器）是可行的。這里不討論也不分析更高級的利用游戲邏輯去時間作弊的方式，我們給數據包打上時間戳的主要目的也非防止時間作弊。

校對時間的一般用途是用來實現更流暢的戰斗系統和位置同步。因為不依賴網絡傳輸的統一時間參照標準可以使游戲看起來更為實時。

首先談談位置同步。

好的位置同步一定要考慮網絡延遲的影響，所以，簡單把 entity 的坐標廣播到 clients 不是一個好的方案。我們應該同步的是一個運動矢量以及時間信息。既，無論是 client 還是 server ，發出和收到的信息都應該是每個 entity 在某個時刻的位置和運動方向。這樣，接收方可以根據收到的時刻，估算出 entity 的真實位置。對于 server 一方的處理，只要要求 client 按一個頻率(一般來說戰斗時 10Hz 即可，而非戰斗狀態或 player 不改變運動狀態時可以更低) 給它發送位置信息。server 可以在網絡狀態不好的情況下依據最近收到的包估算出現在 player 位置。而 client 發出的每次 player 位置信息，都應該被 server 信任，用來去修正上次的估算值。而 server 要做的只是抽查，或交給另一個模塊去校驗數據包的合法性（防止作弊）。

在 server 端，每個 entity 的位置按 10Hz 的頻率做離散運動即可。

client 因為涉及顯示問題，玩家希望看到的是 entity 的連續運動，所以處理起來麻煩一點。server 發過來的位置同步信息也可能因為網絡延遲晚收到。client 同樣根據最近收到的包做估算，但是再收到的包和之前已經收到的信息估算結果不同的時候，應該做的是運動方向和速度的修正，盡可能的讓下次的估算更準確。

關于戰斗指令同步，我希望是給所有戰斗指令都加上冷卻時間和引導時間，這正是 wow 的設計。這樣，信任 client 的時間戳，就可以得到 client 準確的指令下達時間。引導時間（或者是公共冷卻時間）可以充當網絡延遲時間的緩沖。當然我們現在的設計會更復雜一些，這里不再列出。對于距離敏感的技能，例如遠程攻擊和范圍魔法，我們的設計是有一個模糊的 miss 判定公式，解決距離邊界的判定問題。

這里， server 對攻擊目標的位置做估算的時候，可以不按上次發出包的運動方向去做位置估計，而選擇用最有利于被攻擊者的運動方向來做。這樣，可以減少網絡狀況差的玩家的劣勢。

對于 PVE 的戰斗，甚至可以做更多的取舍，達到游戲流暢的效果。比如一個網絡狀態差的玩家去打 npc，他攻擊 npc 的時刻，npc 是處于攻擊范圍之內的。但是由于網絡延遲，數據包被 server 收到的時候，npc 已經離開。這個時候 server 可以以 client 的邏輯來將 npc 拉會原來的坐標。

雖然，這樣做，可能會引起其他玩家（旁觀者） client 上表現的不同。但是，網絡游戲很多情況下是不需要嚴格同步的。在不影響主要游戲邏輯的情況下，player 的手感更為重要。