手遊中載具物理同步的實現方案

遊資網發表於2019-09-17
作者介紹|Ned,騰訊互動娛樂工程師

一.載具同步的難點


手遊中載具物理同步的實現方案

FPS遊戲裡的載具,基本上是隨著“吃雞”玩法一起湧現的,基本上每一個大地圖的玩法都少不了載具系統。可能在很多人的印象裡,人物移動的網路同步不是一件很複雜的事情,按照UE3狀態機+走路點的方式來實現,基本上最終結果就是可以接受的。但是載具的網路同步卻要複雜的多,見下表:

手遊中載具物理同步的實現方案

二.網路同步的本質

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

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

(1)網路延時和傳輸速度的不穩定,也就是說得到的取樣資料(網路同步包)不是等時間間隔的;

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

(3)原始訊號會有“突變”的情況,例如載具高速撞到牆上馬上停止下來;

(4)有實時性要求,本地做訊號重建的時候只能拿到歷史的有延遲的資料,而對於重建結果來說普通情況下只能允許與原始訊號存在幾百毫秒的延遲,特殊情況下要求幾乎零毫秒的延遲。

三.同步系統概要

名詞說明

手遊中載具物理同步的實現方案

(1)載具的權威端稱之為master或者P,它代表著“原始訊號”,它的運動狀態就是“正確的”那個狀態。它的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表示將物理計算的結果和同步演算法得到的結果進行混合,混合的權重是變化的。從實現的角度來說是在不斷修改物理引擎計算出來的結果。

系統概要

*master向replica所在客戶端以較低頻率(例如50ms)傳送snapshot,包含當時的時刻和運動狀態,這個就是原始訊號的取樣資料;

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

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

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

四.核心技術詳細說明

(1)網路同步狀態下載具之間真實物理碰撞的實現

為了實現P和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就是將這兩條軌跡(包含位置和速度)進行混合,其中混合係數隨時間變化。在碰撞發生的一瞬間,係數為,replica的運動完全受物理模擬控制,從而表現出真實的碰撞效果。隨著時間的推移,係數逐漸降低為0,replica的運動完全受到同步演算法控制。

(4)Intepolation同步策略存在的意義

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

五.小結

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

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

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

引用:


[]Replicating Chaos:Vehicle Replication in'Watch Dogs 2':
https://www.gdcvault.com/play/024597/Replicating-Chaos-Vehicle-Replication-in
[2]Defeating Lag With Cubic Splines:
http://archive.gamedev.net/archive/reference/articles/article94.html


作者:Ned  
來源:騰訊遊戲學院
原地址:https://mp.weixin.qq.com/s/9j8TFGeJno1fD8jqzK6eWg

相關文章