同步在網(wǎng)絡(luò)游戲中是非常重要的，它保證了每個(gè)玩家在屏幕上看到的東西大體是一樣的。其實(shí)呢，解決同步問(wèn)題的最簡(jiǎn)單的方法就是把每個(gè)玩家的動(dòng)作都向其他玩家廣播一遍，這里其實(shí)就存在兩個(gè)問(wèn)題：1，向哪些玩家廣播，廣播哪些消息。2，如果網(wǎng)絡(luò)延遲怎么辦。事實(shí)上呢，第一個(gè)問(wèn)題是個(gè)非常簡(jiǎn)單的問(wèn)題，不過(guò)之所以我提出這個(gè)問(wèn)題來(lái)，是提醒大家在設(shè)計(jì)自己的消息結(jié)構(gòu)的時(shí)候，需要把這個(gè)因素考慮進(jìn)去。而對(duì)于第二個(gè)問(wèn)題，則是一個(gè)挺麻煩的問(wèn)題，大家可以來(lái)看這么個(gè)例子：
比如有一個(gè)玩家A向服務(wù)器發(fā)了條指令，說(shuō)我現(xiàn)在在P1點(diǎn)，要去P2點(diǎn)。指令發(fā)出的時(shí)間是T0，服務(wù)器收到指令的時(shí)間是T1，然后向周圍的玩家廣播這條消息，消息的內(nèi)容是“玩家A從P1到P2”有一個(gè)在A附近的玩家B，收到服務(wù)器的這則廣播的消息的時(shí)間是T2，然后開(kāi)始在客戶端上畫(huà)圖，A從P1到P2點(diǎn)。這個(gè)時(shí)候就存在一個(gè)不同步的問(wèn)題，玩家A和玩家B的屏幕上顯示的畫(huà)面相差了T2-T1的時(shí)間。這個(gè)時(shí)候怎么辦呢？
有個(gè)解決方案，我給它取名叫 預(yù)測(cè)拉扯，雖然有些怪異了點(diǎn)，不過(guò)基本上大家也能從字面上來(lái)理解它的意思。要解決這個(gè)問(wèn)題，首先要定義一個(gè)值叫：預(yù)測(cè)誤差。然后需要在服務(wù)器端每個(gè)玩家連接的類里面加一項(xiàng)屬性，叫TimeModified，然后在玩家登陸的時(shí)候，對(duì)客戶端的時(shí)間和服務(wù)器的時(shí)間進(jìn)行比較，得出來(lái)的差值保存在TimeModified里面。還是上面的那個(gè)例子，服務(wù)器廣播消息的時(shí)候，就根據(jù)要廣播對(duì)象的TimeModified，計(jì)算出一個(gè)客戶端的CurrentTime，然后在消息頭里面包含這個(gè)CurrentTime，然后再進(jìn)行廣播。并且同時(shí)在玩家A的客戶端本地建立一個(gè)隊(duì)列，保存該條消息，只到獲得服務(wù)器驗(yàn)證就從未被驗(yàn)證的消息隊(duì)列里面將該消息刪除，如果驗(yàn)證失敗，則會(huì)被拉扯回P1點(diǎn)。然后當(dāng)玩家B收到了服務(wù)器發(fā)過(guò)來(lái)的消息“玩家A從P1到P2”這個(gè)時(shí)候就檢查消息里面服務(wù)器發(fā)出的時(shí)間和本地時(shí)間做比較，如果大于定義的預(yù)測(cè)誤差，就算出在T2這個(gè)時(shí)間，玩家A的屏幕上走到的地點(diǎn)P3，然后把玩家B屏幕上的玩家A直接拉扯到P3，再繼續(xù)走下去，這樣就能保證同步。更進(jìn)一步，為了保證客戶端運(yùn)行起來(lái)更加smooth，我并不推薦直接把玩家拉扯過(guò)去，而是算出P3偏后的一點(diǎn)P4，然后用(P4-P1)/T(P4-P3)來(lái)算出一個(gè)很快的速度S，然后讓玩家A用速度S快速移動(dòng)到P4，這樣的處理方法是比較合理的，這種解決方案的原形在國(guó)際上被稱為（Full plesiochronous），當(dāng)然，該原形被我篡改了很多來(lái)適應(yīng)網(wǎng)絡(luò)游戲的同步，所以而變成所謂的：預(yù)測(cè)拉扯。
另外一個(gè)解決方案，我給它取名叫 驗(yàn)證同步，聽(tīng)名字也知道，大體的意思就是每條指令在經(jīng)過(guò)服務(wù)器驗(yàn)證通過(guò)了以后再執(zhí)行動(dòng)作。具體的思路如下：首先也需要在每個(gè)玩家連接類型里面定義一個(gè)TimeModified，然后在客戶端響應(yīng)玩家鼠標(biāo)行走的同時(shí)，客戶端并不會(huì)先行走動(dòng)，而是發(fā)一條走路的指令給服務(wù)器，然后等待服務(wù)器的驗(yàn)證。服務(wù)器接受到這條消息以后，進(jìn)行邏輯層的驗(yàn)證，然后計(jì)算出需要廣播的范圍，包括玩家A在內(nèi)，根據(jù)各個(gè)客戶端不同的TimeModified生成不同的消息頭，開(kāi)始廣播，這個(gè)時(shí)候這個(gè)玩家的走路信息就是完全同步的了。這個(gè)方法的優(yōu)點(diǎn)是能保證各個(gè)客戶端之間絕對(duì)的同步，缺點(diǎn)是當(dāng)網(wǎng)絡(luò)延遲比較大的時(shí)候，玩家的客戶端的行為會(huì)變得比較不流暢，給玩家?guī)?lái)很不爽的感覺(jué)。該種解決方案的原形在國(guó)際上被稱為（Hierarchical master-slave synchronization），80年代以后被廣泛應(yīng)用于網(wǎng)絡(luò)的各個(gè)領(lǐng)域。
最后一種解決方案是一種理想化的解決方案，在國(guó)際上被稱為Mutual synchronization，是一種對(duì)未來(lái)網(wǎng)絡(luò)的前景的良好預(yù)測(cè)出來(lái)的解決方案。這里之所以要提這個(gè)方案，并不是說(shuō)我們已經(jīng)完全的實(shí)現(xiàn)了這種方案，而只是在網(wǎng)絡(luò)游戲領(lǐng)域的某些方面應(yīng)用到這種方案的某些思想。我對(duì)該種方案取名為：半服務(wù)器同步。大體的設(shè)計(jì)思路如下：
首先客戶端需要在登陸世界的時(shí)候建立很多張廣播列表，這些列表在客戶端后臺(tái)和服務(wù)器要進(jìn)行不及時(shí)同步，之所以要建立多張列表，是因?yàn)橐獜V播的類型是不止一種的，比如說(shuō)有l(wèi)ocal message,有remote message,還有g(shù)lobal message 等等，這些列表都需要在客戶端登陸的時(shí)候根據(jù)服務(wù)器發(fā)過(guò)來(lái)的消息建立好。在建立列表的同時(shí)，還需要獲得每個(gè)列表中廣播對(duì)象的TimeModified，并且要維護(hù)一張完整的用戶狀態(tài)列表在后臺(tái)，也是不及時(shí)的和服務(wù)器進(jìn)行同步，根據(jù)本地的用戶狀態(tài)表，可以做到一部分決策由客戶端自己來(lái)決定，當(dāng)客戶端發(fā)送這部分決策的時(shí)候，則直接將最終決策發(fā)送到各個(gè)廣播列表里面的客戶端，并對(duì)其時(shí)間進(jìn)行校對(duì)，保證每個(gè)客戶端在收到的消息的時(shí)間是和根據(jù)本地時(shí)間進(jìn)行校對(duì)過(guò)的。那么再采用預(yù)測(cè)拉扯中提到過(guò)的計(jì)算提前量，提高速度行走過(guò)去的方法，將會(huì)使同步變得非常的smooth。該方案的優(yōu)點(diǎn)是不通過(guò)服務(wù)器，客戶端自己之間進(jìn)行同步，大大的降低了由于網(wǎng)絡(luò)延遲而帶來(lái)的誤差，并且由于大部分決策都可以由客戶端來(lái)做，也大大的降低了服務(wù)器的資源。由此帶來(lái)的弊端就是由于消息和決策權(quán)都放在客戶端本地，所以給外掛提供了很大的可乘之機(jī)。
綜合以上三種關(guān)于網(wǎng)絡(luò)同步派系的優(yōu)缺點(diǎn)，綜合出一套關(guān)于網(wǎng)絡(luò)游戲傳輸同步的較完整的解決方案，我稱它為綜合同步法（colligate synchronization）。大體設(shè)計(jì)思路如下：
首先將服務(wù)器需要同步的所有消息從劃分一個(gè)優(yōu)先等級(jí)，然后按照3/4的比例劃分出重要消息和非重要消息，對(duì)于非重要消息，把決策權(quán)放在客戶端，在客戶端邏輯上建立相關(guān)的決策機(jī)構(gòu)和各種消息緩存區(qū)，以及相關(guān)的消息緩存區(qū)管理機(jī)構(gòu).
對(duì)于非重要消息，客戶端的大體處理流程，其中有一個(gè)客戶端被動(dòng)行為值得大家注意，其中包括對(duì)服務(wù)器發(fā)過(guò)來(lái)的某些驗(yàn)證代碼做返回，來(lái)確保消息緩存中的消息和服務(wù)器端是一致的，從而有效的防止外掛來(lái)篡改本地消息緩存。其中的消息來(lái)源是包括本地的客戶端響應(yīng)玩家的消息以及遠(yuǎn)程服務(wù)器傳遞過(guò)來(lái)的消息。
對(duì)于重要消息，比如說(shuō)戰(zhàn)斗或者是某些牽扯到玩家一些比較敏感數(shù)據(jù)的操作，則采用另外一套方案，該方案首先需要在服務(wù)器和客戶端之間建立一套Ping System，然后服務(wù)器保存和用戶的及時(shí)的ping值，當(dāng)ping比較小的時(shí)候，響應(yīng)玩家消息的同時(shí)先不進(jìn)行動(dòng)作，而是先把該消息反饋給服務(wù)器，并且阻塞，服務(wù)器收到該消息，進(jìn)行邏輯驗(yàn)證之后向所有該詳細(xì)廣播的有效對(duì)象進(jìn)行廣播（包括消息發(fā)起者），然后客戶端收到該消息的驗(yàn)證，才開(kāi)始執(zhí)行動(dòng)作。而當(dāng)ping比較大的時(shí)候，客戶端響應(yīng)玩家消息的同時(shí)立刻進(jìn)行動(dòng)作，并且同時(shí)把該消息反饋給服務(wù)器，值得注意的是這個(gè)時(shí)候還需要在本地建立一個(gè)無(wú)驗(yàn)證消息的隊(duì)列，把該消息入隊(duì)，執(zhí)行動(dòng)作的同時(shí)等待服務(wù)器的驗(yàn)證，還需要保存當(dāng)前狀態(tài)。服務(wù)器收到客戶端的請(qǐng)求后，進(jìn)行邏輯驗(yàn)證，并把消息反饋到各個(gè)客戶端，帶上各個(gè)客戶端校對(duì)過(guò)的本地時(shí)間。如果驗(yàn)證通過(guò)不過(guò)，則通知消息發(fā)起者，該消息驗(yàn)證失敗，然后客戶端自動(dòng)把已經(jīng)在進(jìn)行中的動(dòng)作取消，恢復(fù)原來(lái)狀態(tài)。如果驗(yàn)證通過(guò)，則廣播到的各個(gè)客戶端根據(jù)從服務(wù)器獲得校對(duì)時(shí)間進(jìn)行對(duì)其進(jìn)行拉扯，保證在該行為完成之前完成同步。
至此，一個(gè)比較成熟的網(wǎng)絡(luò)游戲的同步機(jī)制已經(jīng)初步建立起來(lái)了，接下來(lái)的邏輯代碼就根據(jù)各自不同的游戲風(fēng)格以及側(cè)重點(diǎn)來(lái)寫了。
同步是網(wǎng)絡(luò)游戲最重要的問(wèn)題，如何同步也牽扯到各個(gè)方面的問(wèn)題，比如說(shuō)游戲的規(guī)模，游戲的類型以及各種各樣的方面，對(duì)于規(guī)模比較大的游戲，在同步方面可以下很多的工夫，把消息分得十分的細(xì)膩，對(duì)于不同的消息采用不同的同步機(jī)制，而對(duì)于規(guī)模比較小的游戲，則可以采用大體上一樣的同步機(jī)制，究竟怎么樣同步，沒(méi)有個(gè)定式，是需要根據(jù)自己的不同情況來(lái)做出不同的同步?jīng)Q策的
網(wǎng)游同步算法之導(dǎo)航推測(cè)（Dead Reckoning）算法：
在了解該算法前，我們先來(lái)談?wù)勗撍惴ǖ囊恍┍尘百Y料。大家都知道，在網(wǎng)絡(luò)傳輸?shù)臅r(shí)候，延遲現(xiàn)象是很普遍的，而在基于Server/Client結(jié)構(gòu)下的網(wǎng)絡(luò)游戲的同步也就成了很頭疼的問(wèn)題，在保證客戶端響應(yīng)用戶本地指令流暢的情況下，沒(méi)法有效的保證的同步的及時(shí)性。同樣，在軍方也有類似的事情發(fā)生，即使是同一LAN里面的機(jī)器，也會(huì)因?yàn)閭鬏數(shù)难舆t，導(dǎo)致一些運(yùn)算的失誤，介于此，美國(guó)國(guó)防部投入了大量的資金用于研究一種比較的好的方案來(lái)解決分布式系統(tǒng)中的延遲問(wèn)題，特別是一個(gè)叫分布式模擬運(yùn)動(dòng)（Distributed Interactive Simulation）的系統(tǒng)，這套系統(tǒng)呢，其中就提出了一套號(hào)稱是Latency Hiding & Bandwidth Reduction的方案，命名為Dead Reckoning。呵呵，來(lái)頭很大吧，恩，那么我們下面就來(lái)看看這套系統(tǒng)的一些觀點(diǎn)，以及我們?nèi)绾伟阉\(yùn)用到我們的網(wǎng)絡(luò)游戲的同步中。