Events vs Polling
概述
在Unity內部時從模擬讀取資訊,以顯示相關資料給使用者,在Quantum遊戲中是一個常見的做法。
為了這樣做,可以採取兩種方法。第一種方法是polling
,其涉及以常規間隔從Unity來請求資訊,比如在Update
迴圈之中。第二種方法是使用Quantum事件,其涉及訂閱方法到Quantum的事件系統,並且使用它們來更新檢視。
輪詢
一個簡單的輪詢方法可能看起來如此:
C#
// This snippet is extracted from the Quantum API Sample.
// Update is called once per frame
private void Update()
{
// The QuantumGame used here can be found, for example, via "QuantumRunner.Default.Game"
var kcc = _game.Frames.Verified.Unsafe.GetPointer<CharacterController3D>(_entityRef);
bool isMoving = kcc->Velocity.Magnitude.AsFloat > 0.2f;
_animator.SetBool(BOOL_IS_MOVING, isMoving);
if (isMoving)
{
_animator.SetFloat(FLOAT_MOVEMENT_SPEED, kcc->Velocity.Magnitude.AsFloat);
_animator.SetFloat(FLOAT_MOVEMENT_VERTICAL, kcc->Velocity.Z.AsFloat);
}
else
{
_animator.SetFloat(FLOAT_MOVEMENT_SPEED, 0.0f);
_animator.SetFloat(FLOAT_MOVEMENT_VERTICAL, 0.0f);
}
}
這個程式碼片段從模擬來輪詢,以讀取最新的已驗證幀,以讀取玩家的KCC速度,並且應用適當的動畫。
基於事件
一個簡單的基於事件的方法可能看起來如此:
C#
private void Start()
{
// subscribe to the simulation event
QuantumEvent.Subscribe<EventOnDamaged>(this, OnDamaged);
}
private void OnDamaged(EventOnDamaged e)
{
// play a particle effect to show a damage indication
GetComponent<ParticleSystem>().Play();
}
這個程式碼片段訂閱到一個使用者建立的模擬事件,以在Unity中生成一個粒子效果。甚至可以在事件類別中發送遊戲資料,其已經含有一個參照到可以找到該幀的遊戲。
如需更多關於事件的資訊,請造訪事件及回調。
優點及缺點
兩種方法都有它們自己的缺點。
當資訊不需要被太頻繁地發送到Unity時,基於事件的程式碼可以更有效能。不是在每個幀發生的,並且對遊戲檢視有影響的遊戲情況,通常以事件來更好的代表。但是如果該遊戲資料需要在每個刷新發送,事件的效能可能比輪詢更差。然而,Quantum事件是 即發即棄的,這意味著延遲加入者將不會接收到在他們加入之前執行的事件。所以從該事件建立的任何視覺效果,在客戶端加入時將需要被手動地重新建立。
輪詢程式碼一般更容易撰寫,並且更容易理解,並且通常更好地用於代表非常頻繁改變(每個幀)的視覺效果資料。因為輪詢的性質,針對延遲加入者將自動初始化視覺效果,因為它保證組建視覺效果的所有資料都已經包含在延遲加入者接收的遊戲狀態中。
已預測 Vs 已驗證
使用這兩種技術時,您可以選擇使用Predicted
或Verified
幀。兩者都有它們的缺點及優點。雖然已預測幀將給您更立即的回饋,但它們可能會因為復原而變得不準確。雖然已驗證幀更具體,但它們將需要一些時間來生效,因為它包含一個來往到伺服器以驗證它們的過程。一般而言一個開發者將使用它們的混合,舉例而言,他們可以使用已驗證幀來顯示遊戲得分,以及已預測幀用於一些效果像是跳躍雲或打擊粒子。