イベント vs ポーリング
イントロダクション
Unity内部でシミュレーションの情報を読み込んで関連データをユーザーに表示することは、Quantumゲームではよくおこなわれます。
これをおこなうには2つのアプローチがあります。1つ目のアプローチはpollingで、Updateループの中など一定の間隔でUnityに情報を要求します。2つ目のアプローチでは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のイベントはfire-and-forgetなので、遅れて参加した人は、参加する前に実行されたイベントを受け取れません。そのため、イベントから作成されたビジュアルは、クライアントが参加したときに手動で再作成する必要があります。
ポーリングコードは一般的に書くのが簡単で理解しやすいため、通常は非常に頻繁に変化する（毎フレームなど）ビジュアルデータの表現に使用するのがよいでしょう。ポーリングの性質上、遅れてきた参加者が受信したゲームステートにはビジュアル構築のためのすべてのデータが含まれている点が保証されるため、遅れてきた参加者のビジュアルの初期化は自動でおこなわれます。
予測 vs 検証
これらのテクニックを使用する場合、予測または検証のいずれかのフレームを選択します。両者にはそれぞれメリットとデメリットがあります。予測フレームはより即座にフィードバックを得られますがロールバックによって不正確になる可能性があります。一方、検証済みフレームは具体的ですが認証のためにサーバーへのラウンドトリップを含むため、効果を発揮するまでに時間がかかります。例えばゲームスコアの表示には検証済みフレームを使い、雲をジャンプするまたはパーティクルにヒットするなどのエフェクトには予測済みフレームを使うなど、開発者はこれらを組み合わせて使用することができます。