幀同步在網上可以搜的資料比較少，關於遊戲的更是沒有，不過，實現的原理也比較簡單，最近幾天就寫了份關於幀同步的文檔，當作給同事掃掃盲，順便也在這裏發發，可以給其他人參考參考
-- by Fox
--競技類網絡遊戲設計方案
一、 前言
幀同步，根據wiki百科的定義是，一種對同步源進行像素級同步顯示的處理技術，對於網絡上的多個接入者，一個信號將會通過主機同步發送給其他人，並同步顯示在各個終端上。同步信號可以是每幀的像素數據，也可以是影響數據變化的關鍵事件信息。
幀同步在網絡遊戲中的應用，設計上有異於傳統的mmorpg遊戲，因爲可以承載更大量的後臺計算，實現類單機的效果，所以可應用在類似射擊類、飛機類中實現彈幕計算或者格鬥類的高精度打擊體驗
本文將主要介紹下幀同步與傳統mmorpg設計框架的異同點以及相關的幾個設計方案，最後，深入展開對其中一種實現方案的分析，而相關的反外掛和斷線重連機制等技術難點暫不在本文討論。
二、 幀同步在遊戲中的應用
網絡遊戲中，遊戲服務的架構大致可以分爲2種模式，分別是cs模式和p2p模式
cs模式框架如圖1(c爲客戶， GSS爲遊戲狀態服務器)
圖1
如圖1，遊戲狀態服務器(GSS)單獨部署，負責對網絡上各個接入者提供服務，當GSS狀態發生變化時，將狀態同步發送給各個接收者。
p2p模式框架如圖2(c爲客戶，GSS爲遊戲狀態服務器):
圖2
圖2中，遊戲狀態服務器存在於各個客戶主機上，遊戲狀態的改變直接來自於各個客戶端的輸入。
以上2個服務框架中，cs模式，由於GSS服務器只有一個，遊戲狀態能保證絕對一致，但GSS可能同時服務上萬個玩家，由於機器性能以及網絡帶寬等硬件資源限制，服務器對大部分情況都無法進行非常嚴格的檢查和處理；p2p模式相對於cs模式，同時連接的玩家有限，所以可以進行比較精細的運算，可實現類似射擊類、飛機類的彈幕計算或者格鬥類的高精度打擊體驗，但是，由於端到端的通訊方式，隨着同時接入用戶的增加，通訊量呈指數級增長，所以，其對同時接入的數量上會限制得比較嚴格，適合少量同屏的競技類等遊戲。
p2p模式中，由於存在多份的GSS，如何保證各個GSS一致也需要特殊考慮， 幀同步算法在遊戲中的應用，主要就是爲了解決p2p模式下的GSS一致性問題。實現原理是將遊戲處理細化爲幀，對於每幀，在同樣的運行環境中，保證同樣的輸入的情況下，將得到同樣的輸出結果。
圖3
圖3中，初始狀態都爲1，序列幀第二幀時，輸入加1操作，則狀態變爲2，第三幀時無輸入，狀態不變，第四幀時，輸入加1操作，狀態變爲3.對於同個運行環境的各個客戶端來說，相同的輸入狀況下，將得到相關的輸出結果，如圖4效果。
圖4
通常，爲了用戶的輸入能及時的響應以及遊戲狀態的過度能夠平滑，會將GSS設置爲20到30幀以上。並且，由於客戶端機器性能或者設置的差異，GSS的狀態無法與遊戲渲染幀實現一一對應，所以，GSS與表現層必須做到完全的分離，否則將因爲某些細小的誤差被放大最終導致遊戲出現完全不同的結果。
圖5
如圖5，非確定的渲染層的輸出，完全由GSS來驅動，GSS保證幀數的穩定，即使出現網絡延遲，也必須在確保收到該幀的所有輸入後才執行該幀的處理。
實現方案上，大致可以分出3種，分別是無主機結構、有主機結構、服務器主機結構
u 無主機結構
在圖2的拓撲結構中，所有GSS功能對等，該方案需要進行特殊的對幀處理，確保所有客戶端都已經同步並且收到所有的輸入。但是，由於網絡上的各個客戶端完全對等，一旦某個用戶網絡狀況出現延遲或者中斷等異常，將影響其他用戶的操作體驗，所以該方案簡單公平但體驗容易受限
u 有主機結構
圖6
如圖6，在各個客戶端中隨機選擇一個的GSS作爲主機，同時負責對幀控制及輸入輸出管理，其他GSS僅跟GSS主機通訊，GSS之間互相不通訊。該方案的好處是，遊戲的體驗只受主機與本機的網絡與本機器狀況的影響，其他GSS出現的任何故障都不會影響其他人，當GSS主機完全失去聯繫時，其他GSS也可以重新仲裁得出新的GSS主機來，但該結構主機在客戶端，容易給外掛有可乘之機，對輸入對幀等能進行特殊處理，最終導致遊戲喪失公平性。此方案能保證玩家體驗，但安全性較低
u 服務器主機結構
服務器主機結構，是將圖6的結構中的GSS主機的的對幀控制及輸入輸出管理功能放在服務器上，降低GSS客戶端的客觀影響，保證了大部分玩家的體驗，且其中有玩家作弊，也能馬上檢測到，保證遊戲的公平性，但結構上已脫離p2p設計，通訊流量隨用戶增加，負額指數級增長。該方案安全性高，保證玩家體驗，但對服務負載有一定的要求。
u 其他
融合有/無主機與服務器主機的結構。服務器主機結構的特點在於控制權在服務端，在有狀態的網絡遊戲中，可以有效防止遊戲數據修改、遊戲加速等外掛，在服務端硬件資源方面，可以增加有/無主機結構減輕負擔，大部分功能用有/無主機結構處理，關鍵操作由服務器主機結構處理等，讓GSS主機與服務器主機協同服務
三、 服務器主機結構設計
服務器主機結構的特點如上所述，這裏再深入展開對該結構的分析與設計。
服務器設計
圖7
服務器主要是起到控制作用，進行客戶端的對幀控制和輸入輸出管理。如圖7，服務器每幀都發驅動幀驅動客戶端執行幀處理，當客戶端有輸入被服務器接收到，則服務器當前幀內將輸入同步輸出給各個客戶端.
網絡上由於客戶端的狀況多種多樣，客戶端幀數可能跟不上服務器，如圖8所示，如果客戶端出現掉幀情況，則在收到驅動幀後需要加速執行，以追上其他客戶端的速度，避免掉幀的用戶一直在對過去的事件進行響應。
遊戲應該優先保證正常用戶的體驗，所以當有玩家出現卡幀情況的時候，不應選擇暫停其他玩家，而是讓他慢慢的追趕上來，設計上，服務器即可以採用客戶端的正常速度，按幀驅動客戶端，但當網絡都出現突發狀況的時候，如圖9，通訊異常時，2個客戶端都對幀數2缺失，如果服務器照常運行，到恢復網絡狀況時，會出現情況是，每個客戶端都卡了幾幀之後，加速拉了幾幀。所以，針對這種情況，增加客戶端的對幀操作，即客戶端執行第1幀時，跟服務器說可以播放第二幀了，然後服務器開始驅動第二幀動作，考慮網絡延遲情況，可以提前對幀第n幀的,效果如圖9，左邊客戶端第二個對幀操作使服務器開始推動第二幀進行，而右邊客戶端的第二個對幀動作其實不起任何作用
圖8
圖9
僞代碼
代碼不貼了
客戶端設計
圖10
客戶端設計由兩部分組成，分別是GSS模塊和渲染模塊。
GSS模塊包含物品系統、角色系統、AI系統、場景系統還有其他相關係統等，同時，輸入輸出和幀數控制也一起集成在GSS模塊中。GSS中各系統功能分別是：
物品系統: 遊戲物品以及物品的效果
角色系統: 角色包括玩家角色、npc及apc等
ai系統: 驅動apc行動的控制模塊
場景系統: 場景物件、地圖、尋路等
其他系統: 其他類似技能、狀態等系統
輸入輸出模塊: 監聽玩家輸入，將玩家輸入上報服務器，同時監聽服務器輸入，綁定當前幀輸出
幀數控制模塊: 監聽服務器驅動幀，驅動執行每幀處理
GSS模塊中各個系統的執行，由幀數驅動，不引入其他時間線。有如物品持續時間、狀態持續時間等都以幀數作爲唯一的時間軸。幀與幀之間的播放頻率，則由服務器統一控制，但由於網絡抖動等影響，幀的頻率並不是太穩定，爲避免播放抖動，幀數控制器需要進行一定的平滑處理。
圖11
客戶端的渲染層，由GSS模塊驅動，爲減少模塊間的耦合，GSS模塊使用事件通知機制驅動渲染層表現。具體細分事件類型如圖12(具體項目具體事件拆解)
由於渲染層與GSS只做到事務級的同步，而GSS與渲染層的播放速率有可能不同，則爲保證較好的表現效果，GSS的邏輯幀需要與渲染層的渲染幀做固定比率的綁定，譬如圖13的1:2，當GSS邏輯幀數不變的情況下，渲染幀掉幀時，能經過換算得到當前邏輯幀對應的渲染幀數，出現GSS幀數暫停時，則邏輯幀也跟着一起暫停
圖13
邏輯幀與渲染幀綁定算法(僞代碼)
代碼不貼了
其中 OnUpdate由引擎在每幀調用，GetNewestFrame獲得邏輯幀通知過來的最新幀，這樣，保證了邏輯幀中關鍵幀進行傷害計算時，渲染幀不會脫幀嚴重。
四、 反外掛與斷線重連