チート保護
はじめに
セキュリティとチート防止は、オンラインマルチプレイヤーゲームの重要な側面です。Quantumの決定論は、これらの問題に対処するための独自の機能を提供します。このページでは、ビルトイン保護の詳細に迫り、Photon Quantumを使用して生産-readyなオンラインゲームを作成するためのベストプラクティスを提供します。
開発者は、セキュリティに関する問題やそれを軽減する手段、そしていつそれを行うべきかを理解していることが重要です。サーバー上でシミュレーション全体を100%実行することは可能ですが、実際にはそれが実用的またはコスト効果的であることは稀です。
- サーバーは高価であり、特にゲームがまだ収益を上げていない場合はなおさらです。
- 多くの場合、チーターはユーザーベースのごく少数を占めます。
- ゲームを100%チート防止することは理想的な考えであり、彼らより一歩先に進むことさえも大きな課題です。
- できるだけ安全な方法をとるべきジャンルのゲームも存在します。
ドキュメント内で使用されている以下の用語:
- ゲームバックエンドは、顧客によって作成およびホストされるオンラインサービスを指します。
- カスタムサーバープラグインは、Photonによってホストされる顧客作成のQuantumプラグインを指します。
- Quantumパブリッククラウドは、PhotonによってホストされるカスタマイズされていないQuantumサーバーを指します。
- Webhookは、パブリッククラウドで動作するQuantum 3ゲームから呼び出される標準化されたHTTPリクエストです。
決定論によるチート防止
サーバーがシミュレーションを実行していなくても、決定論的ゲームの大きな利点は、チート防止が頑健であることです。例えば、プレイヤーがクライアントを変更してキャラクターの速度を変えたとしても、他のプレイヤーに影響を与えることはありません。チートをするプレイヤーが奇妙な行動を取っている(例えば、常に壁にぶつかっている)ことに気づくかもしれませんが、それ以外は彼らの体験には影響ありません。
その理由は簡単です:各クライアントは、シミュレーション全体を決定論的にローカルで実行し、他のクライアントと入力のみを共有します。
信頼できるマッチ結果
マッチ結果は、ゲームバックエンドでプレイヤーの進行状況を更新するために使用できます。最も安全なシナリオでは、これはゲームロジックが実行されているサーバーから行われます。
ただし、専用のゲームサーバーに移行する前に、コスト効果的な方法で結果を検証するために使用できるいくつかの反復があります。
プロトタイプ | クライアントは各自の結果を開発者のゲームバックエンドにプッシュします。これはプロトタイピングに適しており、この設定でゲームを立ち上げることができます。バックエンドに送信する結果を格納できるデータ構造を用意することが最初に行うべきことです。 |
---|---|
ゲーム結果Webook | クライアントは、シミュレーションの中で同時にQuantumサーバーに結果を送信します。オンラインゲームルームが最終的に解散されると、GameResultウェブフックが呼び出され、クライアントから送信されたすべての結果のリストが含まれています。このソリューションは、プロトタイピングの提案と似ていますが、すでにカスタムQuantumサーバー提案のGameResult APIを使用しています。 |
再シミュレーションリプレイ | ゲームの結果が不明瞭であるか、一般的に信頼できない場合は、キャプチャされた入力ストリームを使用してセッションを再シミュレートすることができます。これには、非Unityのセッションランナーアプリケーションを使用します。オンラインゲームセッションのキャプチャと再生に関する情報は、リプレイマニュアルを参照してください。 |
カスタムQuantumサーバー | Photon Enterpriseサーバーでシミュレーションを実行します。これにより、クライアントがデータを送信するのを待たずに、サーバーから自動的にGameResultウェブフックが呼び出されます。 |
クライアント主導のゲーム設定を保護する
実際のオンラインQuantumシミュレーションとゲームの多くの開始パラメータは、デフォルトでクライアントによって制御されています。
各クライアントは、セッションが開始される前にSessionConfig
(Quantum設定)およびRuntimeConfig
(ゲーム設定)ファイルをアップロードします。また、クライアントはゲームにプレイヤーが追加されるときに、通常はゲームのロードアウトや進行状況を説明するRuntimePlayer
もアップロードします。
パブリックQuantumクラウドで動作するゲームでは、クライアントから送信されるデータを保護するために、Quantum Webhooksを使用することができます。
パブリックQuantumクラウド | サーバーはクライアントから受け取った最初の `SessionConfig ` および `RuntimeConfig ` を選択しますが、これはほぼランダムです。 `RuntimePlayer ` は完全に保護されていません。 |
---|---|
Webhooks | クライアントから送信された `SessionConfig `、`RuntimeConfig `、および `RuntimePlayer ` は、Photonダッシュボードで設定されたHTTPウェブフックを使用して確認することができ、これにより開発者のゲームバックエンドを呼び出すことができます。 |
カスタムQuantumサーバー | すべての設定は、開発者のゲームバックエンドから取得された後にインターセプトされ、置き換えられる可能性があります。 |
カスタム認証
当社自身は認証サービスやプレイヤーデータベースを提供していませんが、独自またはサードパーティの認証サービスを追加することを強く推奨します。
決定論の欠点
決定論には多くの利点がありますが、このタイプの技術にはいくつかの著名な欠点も伴います。
完全情報問題
Quantumでは、各クライアントがゲームをローカルでシミュレートするために必要なすべての情報にアクセスできます(他のプレイヤーの入力を除く)。これは、カードゲームで使用されるクライアント主導の秘密や、フォグ・オブ・ウォーのような機能が簡単にハッキングされることを意味します。
また、クライアントが次のランダム番号を「予測」したり、ボットを作成したりする能力を許す周辺的なケースも存在します。
チーター検出のためのチェックサムの使用
ライブゲームでチーターを検出する手段として、Quantumのチェックサム検出を使用することはお勧めしません。
- チェックサム計算はコストが高く、処理の遅延を引き起こす可能性があります。
- ビルトイン機構は、ゲームセッション内のすべてのクライアントのシミュレーションを直ちに停止させます。