手遊中載具物理如何同步實現？

FPS遊戲裏的載具，基本上是隨著BR玩法一起湧現的，基本上每一個大地圖的玩法都少不了載具係統。可能在很多人的印象裏，人物移動的網絡同步不是一件很複雜的事情，按照UE3狀態機+走路點的方式來實現，基本上最終結果就是可以接受的。但是載具的網絡同步卻要複雜的多，手遊中載具物理如何同步實現？接下來就帶大家做個了解！

見下表：

一、網絡同步的本質

我個人覺得對於客戶端來說，網絡同步可以類比為一個信號重建的過程，從remote端接受到原始信號的一係列離散的“采樣數據”，然後試圖在本地還原出原始信號，可以從信號采樣的角度描述成sampling->reconstruction filtering->resampling的過程。對於人和載具的移動同步來說，“原始信號"就是連續的運動軌跡。好的同步，就等同於好的信號重建結果。

對於移動同步來說，而它的特殊之處在於：

（1）網絡延時和傳輸速度的不穩定，也就是說得到的采樣數據（網絡同步包）不是等時間間隔的；

（2）手遊對網絡傳輸量有所限製，所以網絡同步包的頻率不可能太大，也就是說sampling rate比較低(注意到resampling rate其實是遊戲幀率)，undersampling在所難免；

（3）原始信號會有“突變”的情況，例如載具高速撞到牆上馬上停止下來；

（4）有實時性要求，本地做信號重建的時候隻能拿到曆史的有延遲的數據，而對於重建結果來說普通情況下隻能允許與原始信號存在幾百毫秒的延遲，特殊情況下要求幾乎零毫秒的延遲。

二、同步係統概要

2.1 名詞說明

（1）載具的權威端稱之為master或者1P，它代表著“原始信號”，它的運動狀態就是“正確的”那個狀態。它的host可以是服務器，也可以是操控著這個載具的那個客戶端。

（2）模擬端稱之為replica或者3P，它就是需要在某個客戶端上通過信號重建出來的載具對象。

（3）將用於同步的網絡包所包含的數據稱為snapshot，其中包含了物理狀態信息，例如狀態記錄時刻、位置、朝向、速度、加速度、角速度等。如上圖中的紅色圓形所示。

（4）同步算法中的Interpolation和Extrapolation

Interpolation：基於收到的一組snapshot，插值求出過去某個時刻master的位置。如果采取此策略，replica的狀態一定是跟master過去的某個狀態接近。

Extrapolation：基於最後一個snapshot，預測出當前/未來某時刻master的位置。因為是預測，所以肯定就會有錯的時候，但是如果master在發出最後一個snapshot之後，一直在做加速度恒定的運動的話，那麼推算出來的狀態就會跟master在目標時刻的狀態一致。

可以看到2個策略各有好處，interpolation與過去狀態高度相似，但是有延遲。expolation無延遲，但是可能會出現預測錯誤。

注：Unity的rigidbody就有一個類似的選項，其實表達的是同一個意思。

（5）Dead Reckoning[2]

中文名叫導航推測算法，它利用現在/過去物體位置及速度推定未來位置方向的航海技術。在移動同步的上下文裏，這個技術就是根據曆史的snapshot去猜測一段時間之後(例如50ms)master的位置。猜完之後還需要基於replica當前的運動狀態，設計一條“真實的”移動軌跡使得一段時間之後能夠與推測出來的master的移動狀態一致。

其實Unreal的rigidbody同步機製裏麵，也是包含了dead reckoning思想的，我記得對應的函數名叫做applyRBState()。

（6）Physics Simulation Blending表示將物理計算的結果和同步算法得到的結果進行混合，混合的權重是變化的。從實現的角度來說是在不斷修改物理引擎計算出來的結果。

2.2 係統概要

* master向replica所在客戶端以較低頻率(例如50ms)發送snapshot，包含當時的時刻和運動狀態，這個就是原始信號的采樣數據；

* master在生成snapshot的時候，會對一些數據求曆史均值，例如加速度，角速度等。這個其實是在做reconstruction filter，把一些高頻分量給去掉；

* 如果當前1P和3P沒有發生碰撞的可能，則：模擬端客戶端試圖重建出replica在過去某時刻的運動狀態，也就是基於snapshot進行interpolation；

* 如果當前1P和3P有發生碰撞的可能，則：客戶端基於dead reckoning技術確定replica在當前時刻的運動狀態，也就是基於snapshot進行extrapolation，同時確保replica開啟了物理模擬，如果1P和3P發生碰撞，則觸發physic simulation blending，碰撞的瞬間混合權重為1，控製權完全交給物理係統，隨著時間的推移，混合權重逐漸降低為0，最終完全受同步算法控製。

三、核心技術詳細說明

（1）網絡同步狀態下載具之間真實物理碰撞的實現

為了實現1P和3P載具的“正確的”碰撞表現，需要解決這3個問題：在碰撞發生之前replica的精確同步、碰撞時候的物理模擬、對物理模擬導致的replica和master的運動狀態不一致性的恢複。

設想下麵這個case，載具A和B麵對麵地高速行駛，最終發生碰撞。如果在A的宿主客戶端，B作為replica與它的master的位置差別較大的話，那麼很可能出現一個情況：在A的宿主客戶端已經發生了A和B的碰撞，而此時在B的宿主客戶端2者卻還相離幾米遠。這種不一致性，一般被稱作conflict。要較好的解決conflict，首先當然要保證replica和master不一致的狀態不能差的太多，那麼首先就要確保在A和B的宿主客戶端上發生碰撞的時間和位置是非常接近的。隻要replica的同步在時間和空間上都足夠精確，那麼這一點就能保證。我們通過基於Dead Reckoning技術的extrapolation同步策略來實現較精確同步。第二點，則是在碰撞發生時候讓本地的物理引擎去模擬出一個真實的碰撞效果。這一點隻要保證碰撞發生前物理模擬是開啟狀態就可以實現。如果3P不是始終開啟物理模擬的話，則需要預測碰撞的發生，在可能即將發生碰撞之前，啟用物理模擬。因為snapshot的網絡延時和extrapolation的預測本質，幾乎可以肯定，本地物理模擬之後，replica和其master的位置是不一致的，因此必定需要第三點，也就是conflict resolve。這個則是通過Physics Simulation Blending技術，來保證碰撞發生後的一小段時間內，replica的運動狀態逐漸趨於與其master一致，最終消除不一致性。

（2）Projective Velocity Blending

這是Dead Reckoning技術的一種，它是以物體在某個時間段內進行的是均加速直線運動為前提，來進行預測和本地軌跡的計算。算法保證得到的結果會是一條平滑的曲線。參見下麵的2張圖（聽起來很複雜，其實用的是初中物理知識）。

在本文所述的同步框架裏，Projective Velocity Blending用來實現expolation同步。

（3）Physics Simulation Blending

這個技術理解起來其實很簡單。想象replica載具存在兩條不同的運動軌跡：一個是基於snapshot用同步算法計算出來的軌跡，另一個是本地物理模擬出來的軌跡。Physics Simulation Blending就是將這兩條軌跡（包含位置和速度）進行混合，其中混合係數隨時間變化。在碰撞發生的一瞬間，係數為1，replica的運動完全受物理模擬控製，從而表現出真實的碰撞效果。隨著時間的推移，係數逐漸降低為0，replica的運動完全受到同步算法控製。

（4）Intepolation同步策略存在的意義

前麵說過，實現真實碰撞表現，必須使用extrapolation的同步策略，那麼interpolation同步策略存在的意義是什麼呢？extrapolation在實際運用中，最大的問題是，因為始終隻使用表征master的“最新”狀態的snapshot去做預測，所以抗網絡抖動能力，非常的差。網絡一不穩定，可能就幾百ms都收不到snapshot了，這種情況下還繼續做預測基本上就會誤差越來越大，導致網絡恢複正常之後的conflic resolve沒法做得很好。而從另外一個角度來說，如果1P和3P不會發生碰撞，那麼我們是完全可以接受replica的本地同步狀態具有延遲性的。那麼使用intepolation策略，配合一個snapshot buffer，就可以更好的適應網絡抖動的情況。具體來說就是假如我們的目標是同步replica在150ms之前的狀態，正常情況下的網絡延時是50ms，snapshot的發送頻率是50ms。在這種情況下，我們始終是使用倒數第2個和倒數第3個snapshot來做interpolation。如果網絡發生抖動導致最新的snapshot包沒按時接收到，我們可以使用倒數第2個和倒數第1個snapshot來做intepolation。如果更長的時間還收不到snapshot，我們還可以把同步策略切換成extrapolation。

小結：

同步框架非原創，參考了Watch Dogs 2 團隊在GDC2017上的一篇分享[1]。

在實際應用中，這套同步框架還可以被應用到了其他類型的載具上，包括了四輪車、兩輪車、直升機、船、無人機。

最後，非常感謝相關同學與我在一些實現技術細節上毫無保留的探討，謝謝。

作者：Ned，騰訊互動娛樂工程師