在游戲中 關于網絡中多人同步的挑戰

16年年底的時候我從當時的公司離職，來到了目前任職的一家更專注于游戲開發的公司。接手的是一個platform游戲項目，基本情況是之前的團隊完成了第一個版本，即單人模式的基礎玩法，但是之后對該項目的定位又變成了一個本地局域網的聯機手游(2-4個玩家)。因此，重寫項目底層外加確定網絡同步方案就成了第一件需要去認真考慮的事情了。那么本文就來聊聊網絡同步這件事吧。

游戲同步中的主次

開發網絡多人游戲是一件十分有趣的事情，但是和單機游戲相比無疑增加了更多的挑戰。

例如，我們之前開發的單機版本并不需要多么擔心作弊的問題。這是因為購買我們游戲的玩家(假如我們的單機游戲不免費發布的話)即便作弊，影響的也僅僅是他自己的游戲體驗，不會影響到別人。

但是開發多人游戲就不是這樣了，為了保證讓每個人都有好的游戲體驗，防止作弊總是需要去考慮的。

除此之外，在開發多人游戲時我們還需要考慮如何“欺騙”玩家的眼睛，讓他們認為他們在同一個世界中。

當2個或4個玩家一起在手機上玩游戲時，看上去他們確實像是在共享同一個虛擬世界，在同一個世界中游玩。但事實卻是，玩家自己的手機只是對“同一個”虛擬世界的近似模擬。換言之，他們的游戲世界每一個都是獨一無二的，只不過從外觀上看起來像。

因此，為了達到這種看上去近似的效果，我們需要確認哪些狀態是需要同步的，只要同步了這些狀態，這個游戲世界就看上去一樣了。而哪些狀態是無需同步的，即這些對象的狀態是否同步對整個游戲是否看上去一樣并沒有特別大的影響。

在我們的游戲中，玩家的各種屬性、在世界中的坐標、游戲世界中的敵人各種屬性、道具獲取以及各種觸發器的觸發等等都有可能會對游戲的表現產生影響，因此需要考慮同步;但是像例如海底的水泡粒子效果、道具獲取后的碎裂效果，甚至是背景音樂則不會對游戲的表現產生特別的影響，因此并沒有必要去同步這些內容。

同步輸入or同步狀態

既然明確了不存在兩個完全一樣的游戲世界，每個游戲世界無非都是近似的模擬。那么接下來我們就要來選擇一個適合的網絡同步方案以滿足這種需求了。

兩種client-server模型的相同點都在于有一臺機器負責整個游戲世界的模擬，而這臺負責整個游戲世界模擬的機器是誰則是這兩者最大的區別。在我們的項目中，我們借助其中一個玩家的手機作為服務器，我們叫它Master主機，而一般的玩家設備則被稱為Client。當然，更常見的一種情景是游戲開發商或發行商管理的計算機作為服務器，這也往往需要更多的計算機和運維人員。

通常，基于這種同步模型的游戲中客戶端不能做出真正的決定。一個情景就是當客戶端的玩家按下一個按鍵，客戶端并不會真正的執行影響游戲狀態的操作，相反操作會被發往服務器，并在服務器執行它，之后服務器將執行完這個操作之后的結果(通常是游戲世界的狀態變化)返回給客戶端。

由于大家都知道的網絡延遲，因此服務器和客戶端并非時刻保持一致的，為了使游戲玩家的狀態變化自然(主要是指玩家的位置、角度等狀態)，我們使用的是一種基于插值的同步算法(當然，這種方式也常常被稱為影子跟隨算法)：

服務器間隔固定的時間向客戶端同步狀態數據

客戶端收到數據之后進行同步，一般的屬性數據例如血量等等直接根據服務器的值來同步。而諸如位置等信息在客戶端則保存為ServerPosition或者稱為影子，而客戶端的位置則不斷向ServerPosition靠攏。

位置同步的過程為了更加平滑，要使用插值，步進距為玩家的移動速度。因此，雖然ServerPosition是跳變的，但是在客戶端的表現上卻是連續平滑的。如下圖所示，左側的畫面為Server的狀態，右側的畫面為客戶端的狀態，玩家和場景內的怪物位置通過Server告訴客戶端，客戶端于是開始追趕Server發來的狀態。

當然，將所有的邏輯放到服務器并經過服務器的模擬之后再將結果返回給客戶端的過程會帶來一些滯后感，當玩家對操作的敏感度要求較高時，這顯然不是一個很好的解決方案。因此，客戶端的輸入預測和服務端的延遲補償開始得到應用。通過在客戶端側的輸入預測，可以讓玩家的輸入得到立刻的反饋。而延時補償則保證了結果的正確性。這個過程可以基本概括為以下幾個階段：

當玩家按下按鈕時，客戶端立刻執行相應的操作例如開始播放某個動作或是開始移動。與此同時，客戶端還會向服務器發送一條包含了時間戳的消息。

服務器經過一段延遲后收到了客戶端發來的按鈕被按下的消息，于是服務器會回滾到按鈕被按下的時刻，在這個時刻執行按鈕對應操作，之后再重新模擬到當前時刻。

之后服務器將當前的狀態同步給客戶端。

客戶端收到服務器同步過來的數據，此時由于網絡延遲的緣故，客戶端收到服務器的消息時也已經過去一段時間。所以客戶端同樣需要回滾到服務器發出消息的時刻，并根據服務器發送的狀態來修正自己的狀態。

雖然這樣做能夠更好的保證玩家的手感，但是我們發現無論是客戶端還是服務器，一旦收到消息包之后都需要回滾。而這種回滾機制相對來說較為復雜，并且也不容易在已有的游戲中加入這種機制。

綜上，我們可以看到在這兩種同步模型中，服務器獲取客戶端的操作指令并在服務器內模擬整個游戲世界，之后服務器是將服務器所維護的游戲世界內的狀態同步給各個客戶端，因此這里主要是做狀態同步。

Peer to Peer點對點同步模型是一種很經典的網絡游戲網絡同步模型。帶有幀同步模型的Peer to Peer在很多RTS游戲中得到了大量應用，不過在討論幀同步模型之前，我們先來聊聊一般的Peer to Peer。

相對于C/S模型擁有一個計算機負責整個游戲世界的模擬，Peer to Peer模式并沒有單一的計算機來負責模擬游戲世界。相反它將對游戲世界的模擬分配給了所有玩家，因而每個玩家的客戶端都在模擬著自己的游戲世界。這樣做的一大好處在于玩家的輸入總是立刻響應的，我按下一個按鈕，按鈕造成的結果便發生了，同時我需要做的是將我的操作發送給和我相連的客戶端，讓他們也去根據我發送的操作模擬游戲世界。但是這樣做的一大弊端在于不能保證客戶端看到的游戲畫面是一樣的。

例如上圖上方的怪物射出的子彈可以通過畫線來阻擋，但是由于client1和client2都是在模擬自己的游戲世界，因此延遲或是不同移動設備本身的性能問題就有可能會造成client1的畫線操作同步到client2上時產生不同的結果。所以我們發現只是簡單的讓每個客戶端模擬自己游戲世界(就像單機那樣)，同時簡單的將操作同步給別的客戶端，至少在同步這個問題上是不靠譜的。

因此，游戲行業大多會采用幀同步模型來保證同步的可靠性。很多早期的RTS游戲都采用了幀同步來作為網絡同步的方案。至于為什么很多人在介紹幀同步的時候，都喜歡把早期的RTS游戲搬出來作為一個例子呢?我想各位看一眼RTS游戲的游戲截圖就能猜到個大概了。

RTS游戲中常常伴隨著數十上百甚至上千個邏輯實體單位，如果采用狀態同步的話數據量相對要大很多。但是如果只同步玩家的操作呢?如果每個客戶端在相同的情況下開始游戲，并且運行完全相同的步驟，那么客戶端就可以不通過接收狀態同步信息就能保證游戲的同步了。

這也是這種模型的一大優勢，我們除了發送玩家的操作之外幾乎不需要再發送任何數據。這種同步輸入的方式可以說非常適合RTS游戲，因為它們有那么多的單位，同步所有單位的狀態是不容易的。

因此，采用這種模型就可以把游戲的過程分為一個一個的回合。游戲的每一步都需要通過網絡來收集所有玩家的操作輸入，然后再往下執行。當然，一提到“回合”這個詞，大家想到往往是所謂的回合制游戲，但事實上只要回合的頻率足夠快，仍然是可以做出即時游戲的感覺。

當然，由于沒有同步游戲的狀態，而是同步玩家在游戲內的輸入操作，因此實現完全同步還是有一些事情需要注意的。因為一旦一個小小的不同步發生，就會產生蝴蝶效應，從而引起很明顯的不同步。一個典型的例子便是我以前在開發一個戰斗回放系統時，發現由于一個士兵在尋路的時候稍微走到有點不一樣的地方，就導致了一場戰斗的結果大不相同。

雖然我們目前的項目并沒有采用幀同步的方案，但是還是想和大家分享一點教訓。例如不要使用浮點型數據，這是由于舍入會造成誤差，所以建議各位使用整形數據。同樣，另一個又被重視又被忽略的是隨機數的問題。大家都知道幀同步要保證隨機數也完全一致。因此，大家都會去同步隨機數生成器的種子和它們的使用方式。但是一個潛在的可能性是某一方的非游戲邏輯對象使用了隨機數生成器，從而造成不同步。例如某一方的移動設備性能更好，也因此屏幕上有一些額外粒子特效，這些粒子特效是有可能會使用隨機數發生器的，如果這些游戲邏輯之外的對象使用了隨機數發生器就會造成不同步的發生。

哦，對了，最后需要說明的一點是幀同步還可以和C/S模型組合使用，我們可以通過服務器來轉發客戶端的操作數據，而不必讓各個客戶端直接通訊。公司內有項目組采用的就是這種方案。