幀同步與狀態同步的區別

實時遊戲發展迅猛，同步技術也逐漸成爲解決方案的核心之一。 本文簡單討論了幀同步和狀態同步。
幀同步

什麼是幀同步：幀同步常被RTS(即時戰略)遊戲常採用。在遊戲中同步的是玩家的操做指令，操做指令包含當前的幀索引。通常的流程是客戶端上傳操做到服務器， 服務器收到後並不計算遊戲行爲， 而是轉發到全部客戶端。這裏最重要的概念就是 相同的輸入 + 相同的時機 = 相同的輸出。

實現幀同步的流程通常是：

同步隨機數種子。(通常遊戲中都設計隨機數的使用， 經過同步隨機數種子，能夠保持隨機數一致性)

客戶端上傳操做指令。(指令包括遊戲操做和當前幀索引)

服務器廣播全部客戶端的操做。(若是沒有操做， 也要廣播空指令來驅動遊戲幀前進)。

由於幀同步的特性， 咱們能夠很方便的作出戰鬥回放：服務器記錄全部操做， 客戶端請求到操做文件再執行一次便可。

幀同步的特性致使客戶端的邏輯實現和表現實現必須徹底分離。Unity中的一些方法接口(如 Invoke， Update、動畫系統等)是不可靠的，全部要本身實現一套物理引擎、數學庫，作到邏輯和表現分離。 這樣即便Unity的渲染是不一樣步的，可是邏輯跑出來是同步的。

我曾經參與過一個飛機類彈幕遊戲的項目，它的同步方案就是幀同步， 能夠完美的播放回放， 並實現服務器上加速驗算。
狀態同步

什麼是狀態同步：同步的是遊戲中的各類狀態。通常的流程是客戶端上傳操做到服務器，服務器收到後計算遊戲行爲的結果，而後以廣播的方式下發遊戲中各類狀態，客戶端收到狀態後再根據狀態顯示內容。狀態同步最普遍的應用應該是在回合制遊戲中。

狀態同步實際上是一種不嚴謹的同步。它的思想中，不一樣玩家屏幕上的表現的一致性並非重要指標， 只要每次操做的結果相同便可。因此狀態同步對網絡延遲的要求並不高。像玩RPG遊戲，200-300ms的延遲也能夠接受。 可是在RTS遊戲中，50ms的延遲也會很受傷。
舉個移動的例子，在狀態同步中， 客戶端甲上操做要求從A點移動到B點，但在客戶端乙上， 甲對象從A移動到C，而後從C點移動到了B。這是由於， 客戶端乙收到A的移動狀態時， 已經通過了一個延遲。這個過程當中，須要客戶端乙本地作一些平滑的處理，最終達到移動到B點的結果。

因此國產RPG遊戲中，動畫的特效通常作的比較絢麗(大)， 攻擊的時候給人感受是擊中了。放技能以前通常也有一個動畫前搖，同時將攻擊請求提交給服務器。等服務器結果返回時，動畫也播放完畢了，以後就是統一的傷害效果和結算。

狀態同步和幀同步的比較和選擇：

對好比下

 

選擇：對於單位比較多的即時策略遊戲，幀同步是很好的選擇。反過來，若是玩家比較多，狀態同步更合適，安全性更高。