多人聯機之研究

.　　雖說多人聯機技術已經存在很多年，眾多上古遊戲就已經支持多人聯機，但隨着業務複雜度提高，多人聯機仍然有許多挖掘空間。從業很多年，參與的項目清一色都是狀態同步，相比幀同步，狀態同步在同步這件事上並沒有多少技術難點，因為實現簡單，適用場景眾多，很多遊戲會採用狀態同步，但它並非全能，曾經的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下載地址-阿里雲盤

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

Tags: Unity 多人聯機幀同步獨立遊戲自娛自樂