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