幀同步在競技類網絡遊戲中的應用

幀同步在競技類網絡遊戲中的應用

幀同步在網上能夠搜的資料比較少，關於遊戲的更是沒有，不過，實現的原理也比較簡單，最近幾天就寫了份關於幀同步的文檔，看成給同事掃掃盲，順便也在這裏發發，能夠給其餘人蔘考參考

    --競技類網絡遊戲設計方案

 

1、        前言

 幀同步，根據wiki百科的定義是，一種對同步源進行像素級同步顯示的處理技術，對於網絡上的多個接入者，一個信號將會經過主機同步發送給其餘人，並同步顯示在各個終端上。同步信號能夠是每幀的像素數據，也能夠是影響數據變化的關鍵事件信息。

幀同步在網絡遊戲中的應用，設計上有異於傳統的mmorpg遊戲，由於能夠承載更大量的後臺計算，實現類單機的效果，因此可應用在相似射擊類、飛機類中實現彈幕計算或者格鬥類的高精度打擊體驗

本文將主要介紹下幀同步與傳統mmorpg設計框架的異同點以及相關的幾個設計方案，最後，深刻展開對其中一種實現方案的分析，而相關的反外掛和斷線重連機制等技術難點暫不在本文討論。

2、        幀同步在遊戲中的應用

網絡遊戲中，遊戲服務的架構大體能夠分爲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主機與服務器主機協同服務

 

3、        服務器主機結構設計

服務器主機結構的特色如上所述，這裏再深刻展開對該結構的分析與設計。

         服務器設計

         

                                                             圖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得到邏輯幀通知過來的最新幀，這樣，保證了邏輯幀中關鍵幀進行傷害計算時，渲染幀不會脫幀嚴重。

 

 

4、        反外掛與斷線重連

         稍等後續文章