Server and Client Roles
イントロダクション
決定性システムでは、ゲームクライアントは全てのクライアントのローカルで実行中のシミュレーションでプレイヤー入力を交換するのみです。
過去には、他の全てのゲームクライアントが入力するのを待つのに、ゲームクライアント全員に対してシミュレーションの各ティック・フレームをアップデートする前にロックアップアプローチが必要でした。quantumのアドバンスト予測ロールバックシステム はこれを過去の遺物とし、リアルタイムの決定性シミュレーションを可能にしました。
Quantumでは予測システムによってゲームクライアントが入力予測を使用することでローカルでシミュレーションを進めることが可能になっています。またロールバックシステムがローカルのゲームステートの復元を処理し、予測ミスを再シミュレーションします。
ゲーム不可知のオーソリテーティブコンポーネント（Photonサーバープラグイン）は入力レイテンシをクロック同期、クライアントを管理します。そのため、遅いクライアントがロールバック・シミュレーション続行の確認を行うのを待つ必要がありません。
サーバー
Quantumはサーバーに基づいたソリューションです。Quantumサーバープラグインは2種類あり、1つは完全にゲーム不可知のバージョンで、もう一つはカスタムバージョンです。ゲーム不可知のバージョンはパブリッククラウドで実行中の全てのゲームに対して等しく、カスタムバージョンは専用Photonエンタープライズクラスタ上でデプロイされます。
現在のゲームセッションの 設定 はPhotonルームを作成したクライアントからサーバーに送信されたDeterminsticConfigによって定義されます。ここには、サーバーが問題のセッションを管理するのに使用する更新数や入力受付に対するハードの耐性などの情報も含まれます。
デフォルト
全ての QuantumAppIDに対して実行中のデフォルトプラグインは、全ての要求される
リレー処理し、クライアント入力を同期してクライアントがローカルで決定性シミュレーションを実行するのを確認します。これには以下が含まれます。:
- 入力管理（タイミング及び確認）
- クロック同期
- プレイヤーインデックス割当
問題なく安定した入力確認ストリームがすべてのクライアントに届くには、入力の管理が特に重要です。ロールバックしすぎて困るということはありません。
入力とフレーム確認
よく聞く質問に次のようなものがあります。「確認済み のフレームの署名・認証は誰がお行うのですか？」
答えはこうなります。「厳密には、誰かがフレームを確認するわけではありません。むしろフレームが次の2つの基準を満たします。」:
- フレーム・ティックNについて確認された入力は全てサーバーから受信する;
- 事前のフレーム・ティックN-1は各々に確認された入力を使用してシミュレーションされる
これらの条件が両方とも満たされると、フレームが 確認済み となります。フレームのステータスの確認方法についての詳細はマニュアルの フレーム ドキュメントを参照してください。
サーバーは受け入れた入力の公式ストリームに「署名」し、確認したそれらの入力をセッション内のクライアントに転送します。
入力はローカルのシミュレーションを進めるの中枢であるため、すべてのクライアントが確認済みの決定性フレームをローカルでシミュレーションするのに特定のティック・フレームに関連して 確認済み の入力があれば十分です。
カスタムプラグイン
専用サーバー(Photon Enterprise) を使用すると基本以上のことができるようになります。
Quantumカスタムプラグイン を使用して入力解釈、設定データやなどサーバーによるセッション管理のカスタムに必要な多くのカスタムコントロールを追加できます。
注意: カスタムプラグインの開発とデプロイによるゲームプレイ・クライアントコードへの変更は必要ありません。中心となるゲームが完了した後に付随的に行うオプショナルなステップとなります。
オーソリティ
ゲームオーソリティの維持を目的とする場合は、カスタムプラグインで以下のいずれかを
行ってください。
サーバーからバックエンドへの完全な入力ストリームをプッシュする
ゲームを終了した全てのクライアントからゲームマッチ結果をチェックする
- すべてが一致する場合、結果をそのまま受け入れます。
- 一致しないものがある場合は、一時的に多数勢（例：大多数のクライアントから送信された結果）を受け入れ、後からの検証用に合わないものをマークします。
自動ポストファクト確認：Quantumのコンソールランナーで保存済みのリプレイを実行します。Unityを必要とせず、マッチ全体が数秒でシミュレーションされます。
注意: 上記で説明したアスペクトのどちらにもサーバーサイドのシミュレーションは要求されません。
サーバーサイドシミュレーションとチート
サーバーでシミュレーションを全て実行することは技術的に可能です。それを行うことに対する壁はありません。ただし、効果の面でもコストの面でも、あまり意味がありません。
通常、チートを行う人へ対処する中でこのの疑問がわきます。これが大きな影響を持つ懸念だとすれば、問題ではありません。
ゲームは決定性であり、通常の解釈の範疇では「チート」する方法はありません。マッチや結果を確認する場合、不平に応える場合は、マッチ結果を自分側で完全に承認するため既にサーバーから確認されている公式の入力ストリームを使用できます（前のセクション参照）。これはサーバーでのシミュレーションのマスターコピーを実行することなく行うことができます。
クライアント
ローカルのクライアントがゲームを実行します（Quantumでのシミュレーション+Unityでのビュー）。以下が行う内容です。:
- 時間内に入力をサーバーに送信する。入力がサーバーに到達しない場合は、置き換えられる。
- 同期されたクロックに基づいてフレームを予測する。
- サーバーからの連続する入力認証のストリームを受信し、ロールバックを行い（必要な場合）、フレームを確認する。入力とフレームの確認 の全体的な手順については前のセクションを参照してください。
確認済み のフレームのローカルでのシミュレーションは固定の更新レートで実行されます。予測された フレーム数は変動し、ローカルセッションでシミュレーションに十分なデルタタイムが蓄積されると即座に予測が続行されます。
頻繁なロールバックを想定すると、30ヘルツのシミュレーションレートで実際に予測フレームに対しては300ヘルツで実行できるということになります。異常なくらい高いように感じますが、これは単に1確認済みフレームごとの1ロールバック＋10予測フレームという意味です。予測フレームはすでにシミュレーションされていますが、ロールバック上で再度シミュレーションされます。
Unityでのビューのアップデートレートはシミュレーションレートとは別のものです。例を簡単にするため、Unityアップデートを30ヘルツと考えましょう。このとき、各Unityアップデートは以下の様になります。:
- 確認済みティックを1つ進める（シミュレーションされた完全な重いフレーム1つ+同期済みイベントがディスパッチされる）;
- すべての予測ティックをロールバックし、最後に確認されたものから同期済みクロックまで再度シミュレーションを行う（RTT/2と比例）
高pingでもスムーズな予測ロールバックシステムの動きを保証するため、予測ティックが「軽量」であることを確認する必要があります。負荷を軽くする一つの方法は、カメラ周り（例：プレイヤー視点）のエンティティの予測を助ける予測カリングでビルドを使用することです。
入力、Ping、レイテンシ
サーバーはDeterministicConfig でHardToleranceを入力受け入れのタイミング上限として使用します。サーバーが定義された時間フレーム内で入力を受信しなかった場合、クライアントの入力を置き換えます。
クライアントのローカルロールバックの 最長 の長さはハード耐性 + RTT/2 + ジッタとなります。サーバーはこの上限を全てのクライアントに強制します。これにより、プレイヤーの人数に関わらず一貫性が保たれます。プレイヤーの使用感とプレイヤー 自信 のネットワークの質が結び付き合うからです。言い換えると、クライアントの一人が接続不良になったとしても、影響があるのはそのクライアント自身のみで、他のクライアントにはスムーズな使用感が保たれます。
ゲームセッションに参加するプレイヤーが増えるほど、この重要性も増します。ネットワーク障害を持つプレイヤーが少なくとも一人はいる可能性が増えるからです。
TL;DR:
Quantumゲームの基本的なビルディングブロックがあります。:
クライアント:
- ゲームクライアントシミュレーター：Quantumサーバーと通信し、ローカルシミュレーションを実行し、入力予測とロールバックを全て行う。
- カスタムゲームプレイコード：顧客により、Quantum ECSを使用した独立した純C#シミュレーション（Unityからデカップリング）として開発された。
高性能コードを組み立てる方法についてのフレームワークを提供するほか、QuantumのAPIは広範囲にわたり事前にビルドされたコンポーネント（データ）とシステム（ロジック）を備えている。これらは、決定性＃Dベクターマスや2D・3Dの物理エンジン、navmeshパスファインダーなどどのようなゲームにも再度利用することが可能。
サーバー:
- Quantumサーバープラグイン：入力タイミングとゲームクライアント間のデリバリーを管理し、クロック同期のソースとして動く。
- Quantumカスタムプラグイン：サーバープラグインを拡張して顧客ホスティングのバックエンドシステム（マッチメイキング、プレイヤーサービスなど）と統合できる。
予測フレーム vs 確認フレーム:
予測: クライアントは軽CPUの「予測」フレームをローカルクライアントが予測した入力に基づいた任意のフレームレートでシミュレーションする。確認: クライアントはサーバーが入力ストリームの受信を確認したときに重CPUの「確認」フレームを決められたフレームレートでシミュレーションする。予測の誤りはロールバックされ、再度予測される。