多人聯機之研究

原文鏈接

.　　雖說多人聯機技術已經存在很多年，眾多上古游戲就已經支持多人聯機，但隨著業務復雜度提高，多人聯機仍然有許多挖掘空間，從業很多年，參與的專案清一色都是狀態同步，相比幀同步，狀態同步在同步這件事上并沒有多少技術難點，因為實作簡單，適用場景眾多，很多游戲會采用狀態同步，但它并非全能，曾經的MMORPG游戲幾乎全是狀態同步，因受限于狀態同步對于高頻率互動實在無能為力，所以只能在游戲設計上徹底放棄了高頻率互動，但是行業在發展，玩家的期望值在提升，高頻率互動這道坎始終是要邁過去，所以幀同步這項比狀態同步更古老的技術近年出現越來越頻繁，

幀同步

.　　所謂幀同步，通俗解釋就是，嚴格要求所有客戶端每一幀都是同步的（這里的幀指的是邏輯幀而非渲染幀），如何保證這一點呢，原理并不復雜，只要每一幀的輸入是一樣的，處理程序是一樣的，那么結果必然也是一樣的，再具體一點，客戶端的輸入發送到服務端，服務端標記該輸入屬于哪一幀，隨后轉發給所有客戶端，客戶端拿到輸入后用同樣的邏輯執行，從而得到一樣的結果，這就是一幀的處理程序，然后一直重復這一程序，

總結一下，幀同步就是每一幀，輸入一致，執行一致，結果一致，不停重復，

濃縮一下，幀同步就是輸入一致，執行一致，結果一致，

這看起來非常簡單，嘗試一下逐個擊破，

輸入一致

.　　輸入是客戶端產生的，所有客戶端都發送到同一個服務端，服務端維持了一個幀串列，里面記錄了每一幀都有哪些輸入，然后按需轉發給所有客戶端，客戶端收到的幀資料一致，所以輸入也都是一致的，

執行一致

.　　所有客戶端都是同一份代碼，同樣的邏輯，所以執行必然都是一致的，

結果一致

.　　前兩項都一致，那么結果是否能一致呢？就好比，輸入是【1，1】，處理程序是【加法】，那么【1+1=2】必然成立么，根據常識來看，這必然成立，在計算機中這也必然成立，但是！（“但是”不負眾望出現了）如果把【1，1】換成【1.0，1.0】，就變成了【1.0+1.0=2.0】，這在計算機中不一定成立，因為計算機中整數和浮點數的存盤方式不一樣，計算方式也不一樣，浮點數計算是有誤差的，誤差多少取決于你的CPU，甚至同一個CPU，計算浮點數時也可能有誤差，這表面看只是一個【1+1=2】的問題，實際上是個大隱患，誤差會像雪球一樣越滾越大，從而導致幀同步的結果一團亂，

如何保證結果一致

.　　沒有完美的方案可以解決這個問題，要為每一個游戲專門定制，才能達到最優效率，

.　　例如《王者榮耀》，它的互動頻率很高，作為一個競技游戲，需要客戶端嚴格同步，如何正確幀同步呢？因為浮點數計算精度誤差，但整數計算沒有精度誤差，完全可以把所有的計算都換成整數，把所有浮點數小數點往右挪4位，【1.2345】變成【12345】這不就把問題解決了么？從表現上看，《王者榮耀》的計算邏輯并不會太復雜（其實也有點復雜，只是相對而言），它的計算都在同一個平面，不涉及3D計算，需要計算的內容大致是角色移動，技能命中，涉及到的幾何形狀大概是直線，圓形，矩形，簡單多邊形（可能沒有），這些幾何計算完全可以自己實作，把計算用到的數字全換成整數，從而結果不一致的問題就解決了，

.　　上述的解決辦法只限于所有的計算程序都由自己掌控的前提下，假設計算程序更復雜，那就不得不使用現成的幾何計算庫，物理引擎等等外部工具，幸好這種問題早就有人遇到并提供了基于整數計算的物理引擎，或者使用一些開源物理引擎自行換掉浮點數計算的部分，看起來問題已經有完美答案了，但其實不是，設想一下，從此以后數學中只有整數沒有小數，這是不是特別扯淡，因為小數是數學不可缺少的一部分，你能用整數取代一部分，但不能完全取代，對物理引擎來說，全部采用整數計算很不科學，性能還會下降，主流物理引擎全部都是浮點數計算，如果堅持采用整數計算，這意味著要放棄所有主流物理引擎，這條道雖然可行，但槽點多多，我覺得這是一條邪道，不歸路，

.　　現在又陷入了死局，似乎幀同步遇上復雜的數學計算就等于行不通，這就意味著高頻率互動的多人游戲沒法有復雜的數學計算，但市面上確確實實存在這樣的游戲而且非常多，所以其中必然還是有解決方案的，這個方案就是回滾機制，由服務端派發正確的結果，客戶端檢測到與本地不一致時觸發回滾，這樣就可以徹底解決結果不一致問題，如何實作回滾機制，這套機制說起來短短幾句話，做起來想破腦殼，因為沒有一個完美的方案能實作回滾機制，所以針對不同的游戲方案也會有所不同，

.　　現在很少有只用幀同步的了，通常都是幀同步為主，狀態同步為輔，方可發揮其強大的威力，

研究成果

.　　多人聯機沒有完美統一的實作方案，會隨業務變化而變化，不同的同步頻率，不同的同步人數都會直接影響多人聯機的落地方案，現在越來越多游戲使用主幀同步輔狀態同步的方案，因為幀同步的計算都在客戶端，使得客戶端對細節可以完全掌控，這一點很重要，

.　　在研究幀同步的時候，原本計劃實作一個簡單的幀同步Demo，結果越寫越想寫更多，最終做了個動作游戲……（有夸張的成分）

以下是Demo演示

基于UDP幀同步
渲染幀率：60
邏輯幀率：30
同步幀率：10

Demo演示-輸入延遲

Demo演示-追幀

Demo演示-同步

Demo演示-完整演示

題外話

幀同步的質疑

.　　不止一次聽人質疑幀同步流量消耗大，這大概是幀同步的名字讓人產生誤解，幀同步每一幀同步的只是輸入，資料量極小，講究高頻率，低流量，

技能制作

.　　在制作這個Demo的初期，在如何實作技能這個問題上卡殼了很久，arpg游戲比rpg游戲技能表現復雜的多，在rpg游戲中，技能通常是一個影片幾個特效，而arpg中，技能遠不止如此，它可以復雜到難以想象，經過深思熟慮，我覺得把技能節點化是一個不錯的主意，把功能封裝到節點中，節點可接收自定義引數，將節點鏈接起來就是一個技能，我用Mermaid語法描述節點，因為Mermaid本身就是用于描述流程圖的語法，這跟節點化不謀而合（節點連接起來就是流程圖），其次Mermaid語法簡潔能直接嵌入Markdown實時預覽流程圖，

以下是技能Atk1的描述資訊

Mermaid描述

* 方法: Atk1
* 描述: 平A第一刀
```mermaid
graph TD
轉化角色 ==>
播放影片 ==>
等待0[等待] ==>
沖刺 ==>
等待1[等待] ==>
同步 ==>
設定篩選引數 ==>
設定攻擊引數 ==>
命中特效 ==>
播放特效 ==>
矩形攻擊 ==>
等待2[等待]

播放影片_名字[Atk1] --名字--> 播放影片
播放特效_ID[0] --ID--> 播放特效
命中特效_ID[1] --ID--> 命中特效
等待0_時長[0.2f] --時長--> 等待0
等待1_時長[0.3f] --時長--> 等待1
等待2_時長[0.7f] --時長--> 等待2
沖刺_距離[5.0f] --距離--> 沖刺
沖刺_時長[0.3f] --時長--> 沖刺
設定篩選引數_標識[不同陣營 I 攻方不停頓] --標識--> 設定篩選引數
設定篩選引數_范圍[0.5f 0.0f 1.0f 2.2f] --范圍--> 設定篩選引數
設定攻擊引數_硬直[10] --硬直--> 設定攻擊引數
設定攻擊引數_血量[20] --血量--> 設定攻擊引數

Markdown預覽

方法: Atk1
描述: 平A第一刀

graph TD 轉化角色 ==> 播放影片 ==> 等待0[等待] ==> 沖刺 ==> 等待1[等待] ==> 同步 ==> 設定篩選引數 ==> 設定攻擊引數 ==> 命中特效 ==> 播放特效 ==> 矩形攻擊 ==> 等待2[等待] 播放影片_名字[Atk1] --名字--> 播放影片播放特效_ID[0] --ID--> 播放特效命中特效_ID[1] --ID--> 命中特效等待0_時長[0.2f] --時長--> 等待0 等待1_時長[0.3f] --時長--> 等待1 等待2_時長[0.7f] --時長--> 等待2 沖刺_距離[5.0f] --距離--> 沖刺沖刺_時長[0.3f] --時長--> 沖刺設定篩選引數_標識[不同陣營 I 攻方不停頓] --標識--> 設定篩選引數設定篩選引數_范圍[0.5f 0.0f 1.0f 2.2f] --范圍--> 設定篩選引數設定攻擊引數_硬直[10] --硬直--> 設定攻擊引數設定攻擊引數_血量[20] --血量--> 設定攻擊引數

Runtime生成

public static IEnumerator Atk1(Actor actor, Config.Behavior config)
{
    // 0: 轉化角色
    var self = actor as Role;
    var select = self.GetState<Behavior.ParamSelect>();
    var attack = new Behavior.ParamAttack() { SelectParam = select };
    // 1: 播放影片
    Behavior.MetaRoleAnim(self, "Atk1", 0.1f, false);
    // 2: 等待0
    yield return Tools.Time2Frame(0.2f);
    // 3: 沖刺
    Behavior.MetaRoleNextF(self, 5.0f, 0.3f);
    // 4: 等待1
    yield return Tools.Time2Frame(0.3f);
    // 5: 同步
    Behavior.MetaSyncMove(attack);
    // 6: 設定篩選引數
    select.Area = Mathm.Quad.New(0.5f, 0.0f, 1.0f, 2.2f);
    select.Flags = Const.BehaviorFlag.kSelectXor | Const.BehaviorFlag.kStopMotionNotSender;
    // 7: 設定攻擊引數
    attack.Attack = 20;
    attack.Stable = 10;
    attack.ForceDuration = 0;
    attack.ForceDistance = 0;
    attack.StopMotionTime = 0.3f;

    // 8: 命中特效
    Behavior.MetaEffectHit(attack, config.ID * 10 + 1);
    // 9: 播放特效
    Behavior.MetaEffect(config.ID * 10 + 0, attack);
    // 10: 矩形攻擊
    {
        var __ret__ = Behavior.MetaAttackQuad(attack);
        if (__ret__.HasFlag(Const.MetaAttackResult.kAbort))
        {
            yield break;
        }
        if (__ret__.HasFlag(Const.MetaAttackResult.kStop))
        {
            yield return 1;
        }
    }
    // 11: 等待2
    yield return Tools.Time2Frame(0.7f);
}

Github-地址

Demo下載地址-阿里云盤

再補充一個-空降我最喜歡的一段

轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/509027.html

標籤：其他

上一篇：2022ICPC網路賽 L LCS-like Problem（DP 子序列自動機）

下一篇：從零開始游戲開發——3.4 片斷處理