有關位置同步的方案實際上已經比較成熟，網上也有比較多的資料可供參考。在《帶寬限制下的視覺實體屬性傳播》一文中，作者也簡單提到了位置同步方案的構造過程，但涉及到細節的地方沒有深入，這里專門針對這一主題做些回顧。
最直接的同步方案就是客戶端在每次發生位置改變時都向服務器報告 ，服務器再轉發給周圍的其他玩家，其他客戶端將對應的游戲實體移動到新的位置上。
但是這樣存在一個問題，每個玩家的位置都是自己先開始移動，一段時間之后才在其他玩家的客戶端上表現出來。如果只是希望每個客戶端上看到的游戲對象都同時開始移動，那可以讓玩家的每一步操作都由服務器確認之后再執行，這樣誤差將縮減到不同客戶端之間的網絡延時差。但是顯然的，這樣的做法不可能真正被采用，因為這將使得玩家的游戲體驗非常的糟糕。有誰能忍受連每走一步路都要卡一下的游戲呢？
既然一定存在先后時間差，那需要一種方法來讓不同客戶端上看到的玩家位置不至于有太大的誤差，尤其是不能有影響到游戲公平性的誤差存在。根據誤差出現的直接原因：時間差，我們應該能夠想到一個解決方案，那就是讓其他客戶端設法彌補掉這段時間差內少走的距離。這樣的話也就要求我們的消息包中多帶一個開始移動的時間數據，用于其他客戶端在收到這個消息包時計算對應的玩家實體已經移動過的時間和距離。
我們以一個實際的例子來說明如何減少這種誤差的影響。假設玩家A以速度V從P1點去到P2點，A的網絡延時為T1，在A旁邊有個玩家B，他的網絡延時為T2。B收到服務器轉發過來的移動包時，A在其自己的客戶端上已經移動了T1+T2的時間，在這段時間內他自己已經走過了V*(T1+T2)的距離。如果這時在B的客戶端上開始將實體A從P1移動到P2，那顯然兩個客戶端上看到的A的位置始終存在V*(T1+T2)的誤差。
為了使A在B客戶端上顯示的位置與其實際位置的誤差盡可能的縮小，一個簡單的做法是直接將A的位置向前拖V*(T1+T2)然后開始移動，這樣兩者之間的誤差便消除了。但這樣會使得客戶端的顯示太魯莽，要讓其看起來平滑一些，我們可以考慮使用一些算法，比如計算出A從當前位置走到P2點還需要的時間，然后加快其速度使其在規定的時間內到達P2點，這樣A和B看到的最終時間是相同的，但中間過程還是存在較多誤差。另一種較好的做法是先讓A以一個可接受的較快速度移動到其當前應該所在的位置稍前一點的地方，然后以正常速度移動到P2點，這樣后面的移動情況與其實際移動情況基本吻合了。
看起來這個方案很完美，但是這里卻忽略了一個問題：我們假設的是每次移動時都知道玩家要去的確切位置。這在靠鼠標點擊來移動的2D游戲中是正好合適的，但是在WOW一類的靠鍵盤來移動的3D游戲中卻沒有辦法采用。WOW中的移動消息都只能向服務器報告當前的坐標及朝向信息。
這類移動的位置同步其實也可以采用類似方案，服務器將移動玩家的當前位置信息廣播給周圍的其他玩家，當然其中也包含了時間戳。當其他玩家收到這個移動包后，表示的是在過去的某個時間里該玩家移動到了這個位置。如果只是簡單地將其對應的實體移動到這個位置，那同樣的，也存在位置誤差。
與上一種情況類似，如果我們知道該玩家的移動速度，再通過數據包中的時間戳，假設該玩家還在以相同的速度朝相同的方向移動，那我們也可以預測出該玩家從開始移動到現在這段時間內他走了多遠了距離。我們也可以將其位置做適當的修正，并使其繼續移動下去。
我們需要先停下來考慮一下這些算法的部分細節。其中出現了一些數據是否應該包含在我們的每個消息包中，也就是我們需要考慮的另外一個問題：移動同步的消息中應該包含哪些數據，以及這些數據到底應該向哪些玩家廣播。
對于2D游戲的情況來說，我們的算法需要的數據有：玩家的速度V，玩家開始移動的時間T0，收到數據包的時間T1，玩家當前位置P1和玩家要去的位置P2。T1和P1從當前客戶端上都可以取到，而速度V一般來說不會經常改變，至少不是每次移動時都不一樣，所以我們可以為速度的改變設計單獨的消息碼，這樣V值也是可以在客戶端上取到的。最后，每個移動消息中包含的數據只需要有移動到的位置P2和開始移動的時間T0。
其他客戶端在使用特定算法將玩家移動到P2后會將其停在此處，直到收到下一個移動包時再開始移動。而對于在移動過程中又收到了新的移動包的處理過程基本類似，不做過多描述。
對于3D游戲的情況，算法是基本相同的，但是沒有目標點，替換為移動方向，比如是向正前方移動，還是向左或向右移動等。在這種情況下，只要沒有收到玩家停止移動的消息，其他客戶端上都會以最后一次收到的移動包的狀態來繼續模擬移動。
所以，在網絡偶爾卡一下的時候也會出現一些奇怪的現象。比如WOW中，看到隊友直沖沖地走下了懸崖，你剛喊了句“怎么掉下去了？”只見隊友又從身后走出來，還冒出一句：“沒啊，我就在你旁邊!”
關于數據要向哪些人廣播的問題，其實很簡單，哪些人會看到這個玩家就需要向哪些人廣播。不管是直接在主屏幕上看到還是在大地圖上看到的代表其位置的一個點。但是，針對不同的人使用的廣播策略還是存在差異。
在《帶寬限制下的視覺實體屬性傳播》一文中提出了一個方案很值得參考。該方案提出的基礎是因為3D空間透視的原因，離你很遠的一個玩家移動了10米，最終在你的顯示器上看到的位移可能只有一個象素；而離你不到一米的一個玩家雖然只移動了一米，但最終顯示出來的位移可能會有幾十個象素。所以，遠處玩家的移動并不需要非常嚴格的關注，但近處玩家的移動同步需要非常高的優先級。
這個方案的實現還依賴于另一項技術要求，玩家的屬性更新以一定的頻率來進行，更新時比較一下當前屬性值與上次更新時的屬性值，如果存在差異則通知客戶端更新，另外如果中間跳過了某次更新也不會對客戶端表現及游戲公平性造成什么影響。比如這里要處理的玩家坐標，第一次移動到A點，第二次從A點又移動到B點，如果移動到A點的更新包沒有發送，直接發送了移動到B點的更新包，這將不會對游戲邏輯產生大的影響。
這套方案基本上是為3D游戲的實體屬性廣播優化而設計的，在2D游戲中很難使用。一是斜45度視角的2D游戲中屏幕頂端、中間和底部任何一個位置上的玩家移動，其距離和象素比是完全相同的，因為畫面不存在透視，所以也就沒有遠處對象更新頻率低這一可能。另外2D游戲中的移動與3D游戲也存在差異，具體情況前面有詳細描述，2D游戲中基本上每一次移動都需要廣播，不能跳過哪一個，否則玩家看到的現象就是在亂跑，這也必將影響到技能的使用等游戲邏輯。
有關位置同步所涉及到的一些技術細節及優化方案上面描述了一部分，但是在實際的應用中是否會使用還是要看具體游戲的需求。比如大話類型的游戲，其本身對位置的精確同步就沒有要求，兩個客戶端上出現一前一后的移動也不會影響任何的游戲邏輯，所以前面提到的同步方案可能都用不上。
而對于一些同步要求很高的游戲，如WOW中盜賊這類職業的需求，上面的方案可能還不夠細致，還需要設計更加有效的同步方案。
另外，在位置同步過程中還有一個不容忽視的問題是外掛。我們不能像WOW那樣完全依賴客戶端，如果沒有暴雪那樣強硬的封號措施，游戲也就成為了外掛們的溫床。所以，如何在服務器端模擬每個客戶端的移動，如何檢測出客戶端是否存在作弊行為，也是需要重點關注的一個問題。