サーバーとクライアントの役割
はじめに
決定論的システムでは、ゲームクライアントはすべてのクライアントでローカルに実行されているシミュレーションとの間でプレイヤー入力のみを交換します。
過去には、すべてのゲームクライアントがシミュレーションの各ティック/フレームを更新する前に、他のすべてのプレイヤーからの入力を待つロックステップ方式が必要でした。 Quantumの先進的な予測ロールバックシステム により、これは過去の遺物となり、リアルタイムの決定論的シミュレーションが可能になりました。
Quantumでは、予測システムによりゲームクライアントは入力予測を使用してローカルでシミュレーションを進めることができ、ロールバックシステムはローカルゲーム状態の復元と、誤った予測の再シミュレーションを行います。
ゲームに依存しない権威あるサーバーコンポーネント（フォトンサーバープラグイン）が入力遅延やクロックの同期を管理するため、クライアントは最も遅いクライアントがロールバックまたはシミュレーションを前に進めるのを待つ必要がありません。
サーバー
Quantumはサーバーベースのソリューションです。Quantumサーバープラグインは、完全にゲームに依存しないバニラ版とカスタム版の2種類があります。前者はパブリッククラウドで実行されるすべてのゲームにおいて同一であり、後者は専用のフォトンエンタープライズクラスターにデプロイすることができます。
現在のゲームセッションの構成は、フォトンルームを作成したクライアントによってサーバーに送信されるDeterministicConfigで定義されます。この構成には、アップデートレートや入力受け入れに対する厳格なトレランスなど、サーバーが該当セッションを管理するために使用する情報が含まれています。
デフォルト設定
すべてのQuantumアプリIDで実行されるデフォルトのプラグインは、クライアントの入力を中継し、同期させ、クライアントがローカルで決定論的シミュレーションを実行できるようにするために必要なすべての機能を提供します。これには以下が含まれます：
- 入力管理（タイミングと検証）
- クロック同期
- プレイヤーインデックスの割り当て
特に入力管理は、すべてのクライアントに対して健全で安定した入力確認のストリームを維持することが重要であり、これにより過剰なロールバックを防ぐことができます。
入力と検証フレーム
よくある質問は、「誰が__検証された__フレームに署名/認証するのか？」です。答えは、技術的には誰もフレームを検証しないということです。むしろ、次の2つの条件を満たすフレームが存在します：
- フレーム/ティックNのためのすべての検証された入力がサーバーから受信されていること。
- すべての前のフレーム/ティックN-1が、それぞれの検証された入力を使用してシミュレーションされていること。
これら両方の条件が満たされると、フレームは__検証された__ものと見なされます。フレームの状態を確認する方法についての詳細は、マニュアルの_フレーム_ドキュメントを参照してください。
サーバーは受け入れられた入力の公式ストリームに「署名」し、それらの検証された入力をセッション内のクライアントに転送します。入力はローカルシミュレーションを進めるための重要な要素であるため、特定のティック/フレームに関連付けられた検証された入力は、すべてのクライアントがローカルで決定論的__検証された__フレームをシミュレートするために十分です。
カスタムプラグイン
専用サーバー（Photon Enterprise）を使用すると、基本的な機能を超えたことが可能になります。Quantumカスタムプラグインを使用することで、入力のインターセプト、構成データ、その他のカスタムコントロールを追加し、サーバーによるセッション管理をカスタマイズできます。
注意： カスタムプラグインの開発とデプロイには、ゲームプレイやクライアントコードに変更を加える必要はありません。これは、コアゲームが完成した後に段階的に行うことができるオプションのステップです。
オーソリティ
ゲームのオーソリティを保持することを目指す場合、カスタムプラグインを使用して以下のいずれかを行うことができます：
サーバーからバックエンドに対して完全な入力ストリームをプッシュする。
ゲームを終了したすべてのクライアントからのゲームマッチ結果を確認する。
- すべての結果が一致する場合、そのまま結果を受け入れます。
- 一致しない場合は、一時的に多数決を受け入れます。つまり、最も多くのクライアントから送信された結果を受け入れ、マッチを事後検証用にマークします。
自動的な事後検証；Quantumのコンソールランナーを使用して保存されたリプレイを実行します。これにはUnityは必要なく、数秒以内にフルマッチをシミュレーションできます。
注意： 上記のいずれの側面もサーバー側のシミュレーションを必要としません。
サーバー側のシミュレーションとチート
技術的には、サーバー上で完全なシミュレーションを実行することは可能であり、特にそのための障壁はありません。しかし、実用的かつコストの観点からはあまり意味がありません。
通常、この質問はチーターと戦うための努力の一環として浮上します。それがあなたの主な懸念事項である場合、問題はありません。
ゲームが決定論的であるため、通常理解される意味で「チート」を行う方法はありません。マッチ結果を検証したり、クレームに対応したりする場合、サーバーによって既に検証された公式の入力ストリームを使用して、あなたの側でマッチ結果を完全に確認できます。（前のセクションを参照） これは、サーバー上でシミュレーションのマスターコピーを実行することなく行うことができます。
クライアント
ローカルクライアントは、ゲームを実行します（Quantum内のシミュレーション + Unityでの表示）。その役割は以下の通りです：
- 入力を時間通りにサーバーに送信する。入力が時間内にサーバーに届かない場合は、代わりに置き換えられます。
- 同期されたクロックに基づいてフレームを予測する。
- サーバーからの入力確認の継続的なストリームを受信し、ロールバック（必要に応じて）し、フレームを検証します。プロセスの概要については前のセクションの入力と検証フレームを参照してください。
検証された フレームのローカルシミュレーションは、固定の更新レートで実行されます。__予測された__フレームの数は変動し、シミュレーションがローカルセッション内に十分なデルタタイムを蓄積すると、予測は続けられます。
頻繁にロールバックが発生する場合、これは30Hzのシミュレーションレートが実際には予測されたフレームについて300Hzで実行されることを意味します。このように見えるかもしれませんが、実際には1つの検証されたフレームごとに1回のロールバックと10回の予測されたフレームへの変換に過ぎません。予測されたフレームに関しては、それらはシミュレーションされ、その後ロールバック時に再度シミュレーションされるというものです。
Unityでの表示の更新レートは、シミュレーションレートとは独立しています。この例を簡単にするために、30HzのUnity更新を仮定しましょう。これにより、各Unity更新は以下を行います：
- 1つの検証されたティックを進めます（1フルの重いフレームがシミュレーションされ、同期されたイベントがディスパッチされます）。
- すべての予測されたティックをロールバックし、最新の検証されたティックからSYNCEDクロック（RTT/2に比例して）まで再シミュレートします。
高いピン数でも予測ロールバックシステムがスムーズに機能することを保証するためには、予測されたティックが上述のレートで実行できる「軽量」なものであることを確認する必要があります。負担を軽減する方法の一つは、カメラの周囲のエンティティを予測するのに役立つ組み込みの予測カリングを使用することです。つまり、プレイヤーの視界内のエンティティを予測します。
入力、ピン、遅延
サーバーは、DeterministicConfig の HardTolerance を入力を受け入れるためのタイミング制限として使用します。サーバーが定義された時間枠内に入力を受信できない場合、クライアントの入力は置き換えられます。
クライアントのローカルロールバックの__最大__長さは、hard-tolerance + RTT/2 + jitter です。サーバーはこの制限をすべてのクライアントに対して厳守します。これにより、プレイヤーの体験の質が__自分自身の__ネットワーク品質に結び付けられるため、プレイヤー数にかかわらず一貫した体験が保証されます。言い換えれば、あるクライアントに接続の問題があったとしても、そのクライアント自身の体験だけが影響を受け、他のすべてのプレイヤーの体験はスムーズに保たれます。
ゲームセッションに参加するプレイヤーが増えるほど、少なくとも1人がネットワークの問題を抱えている可能性が高くなるため、これが重要になります。
TL;DR:
Quantumゲームの基本的な構成要素は次のとおりです：
クライアント:
- ゲームクライアントシミュレーター: Quantumサーバーと通信し、ローカルシミュレーションを実行し、すべての入力予測およびロールバックを行います。
- カスタムゲームプレイコード: Quantum ECSを使用して、Unityから切り離された独立した純粋なC#シミュレーションとして顧客により開発されます。高性能なコードを整理するためのフレームワークを提供するだけでなく、QuantumのAPIは決定論的な3Dベクトル数学、2Dおよび3D物理エンジン、ナビメッシュパスファインダーなど、あらゆるゲームで再利用できる様々なプリビルドコンポーネント（データ）やシステム（ロジック）を提供します。
サーバー:
- Quantumサーバープラグイン: ゲームクライアント間の入力タイミングと配信を管理し、クロックの同期源として機能します。
- Quantumカスタムプラグイン: サーバープラグインを拡張して、顧客がホストするバックエンドシステム（マッチメイキング、プレイヤーサービスなど）と統合できます。
予測フレームと検証フレーム:
予測フレーム: クライアントは、ローカルクライアントによって予測された入力に基づいて、任意のフレームレートでCPU負荷の少ない「予測フレーム」をシミュレートします。検証フレーム: サーバーによって検証された入力ストリームを受信した際、クライアントは定められたフレームレートでCPU負荷の高い「検証フレーム」をシミュレートします。誤予測が発生した場合はロールバックし、再度予測されます。