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