. 雖說多人聯機技術已經存在很多年，眾多上古遊戲就已經支援多人聯機，但隨著業務複雜度提高，多人聯機仍然有許多挖掘空間。從業很多年，參與的專案清一色都是狀態同步，相比影格同步化，狀態同步在同步這件事上並沒有多少技術難點，因為實現簡單，適用場景眾多，很多遊戲會採用狀態同步，但它並非全能，曾經的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演示
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預覽
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);
}
再補充一個-空降我最喜歡的一段