チート対策
イントロダクション
オンラインマルチプレイヤーゲームでは、セキュリティとチート対策が重要なポイントになります。Quantumの決定論は、それらに対処するためのユニークな機能を提供します。このページでは、Photon Quantumに内蔵された保護機能について詳しく説明し、オンラインゲーム開発のためのベストプラクティスを提供します。
開発者は、セキュリティに関するすべての問題と、それを軽減するための手順、そしてどのタイミングで対処すべきか認識しておくことが非常に重要です。サーバーでシミュレーションを実行することは可能ですが、実用性とコストの面から、これが賢明であることは極めて稀です。
- サーバーの運用は、ゲームが収益を生まない場合には特にコストがかかります。
- ほとんどの場合、チーターがユーザー層に占める割合は非常に小さなものです。
- ゲームでチートを100%防止するのはユートピア的な考えであり、チーターの一歩先を行くだけでも負荷の高いタスクです。
- ゲームのジャンルによっては、できるだけ多くのセキュリティに依存する必要があります。
このドキュメントでは、以下の用語が使用されています：
- ゲームバックエンドは、顧客が作成しホストするオンラインサービスを指します。
- **カスタムサーバー（/プラグイン）**は、Photonによってホストされている、顧客がカスタマイズしたQuantumプラグインを指します。
- Quantum Public Cloudは、Photonによってホストされている、カスタマイズされていないQuantumサーバーを指します。
決定論によるチート対策
決定論的ゲームの大きな利点は、たとえシミュレーションを実行しているサーバーがなくても、チートを防止できる点です。あるプレイヤーが自分のクライアントを変更し、たとえばキャラクターの速度を変更しても、他のプレイヤーには影響しません。たとえば、あるプレイヤーがキャラクターの速度を変えるなどしてクライアントを変更しても、他のプレイヤーには**影響しません。不正を行ったプレイヤーの挙動がおかしい（たとえば、壁にぶつかり続ける等）と感じるかもしれませんが、それ以外はプレイ体験への影響はありません。
これは、各クライアントはローカルで完全なシミュレーションを実行し、他のクライアントとは入力のみを共有するためです。
信頼できるマッチの結果
マッチの結果は、ゲームバックエンドでプレイヤーの進捗を更新するのに使用されます。最も安全性の高いシナリオでは、これはゲームロジックが実行されるサーバーから実施されます。
ただし、オーソリテーティブ・ゲームサーバーへと進む前に、コスト効率の良い方法で結果を保護するため、数回の反復が可能です。
| プロトタイピング | クライアントは、個別の結果を開発者のゲームバックエンドにプッシュします。これはプロトタイピングに適しており、このセットアップでゲームを起動することもできます。まず、バックエンドに送信する結果で充填できるデータ構造にする必要があります。 |
|---|---|
| 多数決 | クライアントは、マッチング結果を個別にプッシュしますが、バックエンドは結果を多数決で選びます。改ざんされた (可能性のある) データを送信する異常値を識別することができます。クライアント側の確認を待つ必要はなく、ただちに結果を表示し、バックエンドで検証されてから進行状況を保存するだけで済みます。 |
| リプレイの再シミュレーション | 多数決や統計的評価で一致しない場合には、再確認のためのフラグを立て、プレイヤーの入力履歴を収集します。入力履歴、設定ファイル、およびアセット データベースがあれば、Quantum シミュレーションを Unity の外部で実行して結果を再確認 (リプレイ) することができます。Quantum SDKのquantum-console-runnerプロジェクトを参照のうえ、リプレイデータにアクセスする方法については、以下のセクションで確認してください。 |
| セルフホスティングの観戦者レフェリー | Netアプリケーションであるレフリー観戦者を使用すれば、ライブの試合に接続し、同時にシミュレーションを実行できます。選手から結果を送信させるのではなく、このシミュレーションから最終結果を送信します。 |
| カスタムのQuantumサーバー | サーバーでシミュレーションを実行し、結果を送信します（QuantumカスタムプラグインSDKを参照してください） |
リプレイデータへのアクセス方法
Quantum 2.1、およびそれ以前
- クライアントからリクエストを送信
- セルフホスティングの観戦レフェリーから送信
- カスタムのQuantumサーバーから送信
Quantum 3.0. (計画済み)
- Quantum Public Cloudユーザーが、検証済みの入力履歴を別のバックエンドにストリーミングするための、設定可能なWebhook
セルフホスティングの観戦レフェリー
Quantumシミュレーションには、観戦者として参加することができます。観戦者とは、サーバーに接続し、ゲーム全体を実行することができるクライアントのことを指しますが、入力を送信することはできません。観戦者、信頼できるソースからゲームを開始し、初期化するために使用できます。
- 観戦者アプリケーションを作成します（Unityの外部で実行します）。
- このアプリケーションを任意の場所で実行し、ゲームバックエンドと安全にやり取りして、Photonルームを開始および準備します。
- Quantumゲームを起動します。
- 他のクライアントを、後からシミュレーションに参加させます（Quantum SDK内のquantum-console-spectatorプロジェクトを参照してください）。
カスタムのQuantumサーバー
Quantumサーバーでカスタムコードを実行するには、Photon Enterpriseサーバーをレンタルする必要があります。これによって、以下を実施する権限が有効になります：
以下を実現する、サーバー上でのゲームシミュレーションを実行するためのオプション：
ゲーム結果の信頼できるソースを持つ点
(Public Quantum Cloudを使用中にクライアントから送信される)サーバースナップショットを有効化
サーバーが管理する秘密事項をゲームに注入するオプション(サーバーコマンド)
DeterministicConfig、RuntimeConfig、およびRuntimePlayerを傍受し、置換するオプション検証済みのリプレイを保存するオプション
クライアントが管理するゲーム設定の保護
2つの重要な共有設定ファイルが、マッチの最初にクライアントから送信されます：DeterministicConfig(Quantumの設定)とRuntimeConfig(ゲームの設定)です。サーバーは最初に受け取った設定ファイル(DeterministicConfig、RuntimeConfig)を受容しますが、これらはほとんどの場合ランダムです。
クライアントは、プレイヤーのロードアウトを記述した別の設定ファイルも送信します：
RuntimePlayer.です。
これを、バックエンドに保存されているプレイヤーの進捗と照合するには、Quantumサーバーのカスタムプラグインが必要です。
| Public Quantum Cloud | DeterministicConfigとRuntimeConfigに対して、ランダムなソースを選択します |
|---|---|
| Custom Quantum Server | すべての設定ファイルは、開発者のバックエンドから取得した後に傍受および置換可能です |
| ダッシュボード (Quantum 3.0から利用可能) | DeterministicConfigは、Photonダッシュボード内のAppIDと関連づけることで、Public Cloudサーバーに強制的に適用させることができます。 |
| Webhook (Quantum 3.0から利用可能) | RuntimeConfig とRuntimePlayer は、開発者のバックエンドがPhotonダッシュボードで設定したwebrequestを呼び出すことで確認できます。
|
カスタム認証
弊社は認証サービスやプレイヤーデータベースを提供していませんが、独自またはサードパーティーの認証サービスを強く推奨します。
決定論の欠点
決定論には多くの利点がありますが、この種の技術に固有のいくつかの欠点が顕著にみられます。
完全な情報の問題
Quantumでは、すべてのクライアントが、ゲームのシミュレーションに必要なすべての情報にローカルでアクセスできる(他のプレイヤーの入力は別個です)。すなわち、カードゲームやFog Of Warのような機能で使われる、クライアントが管理する秘密は容易にハッキングできるということです。
また、クライアントが次の乱数を「推測」できるといった二次的なケースや、ボットを作成する機能などもあります。
Checksumを使用して、チーターを検知
本番稼働しているゲームについて、チーターの検知にQuantumチェックサムを使用することは推奨されていません。
チェックサム計算が高価で、非常に高いコストになる可能性があります、また
ビルドインメカニズムは、ゲームセッション内のすべてのクライアントのシミュレーションを直ちに停止します。