ゲーム統合のベストプラクティスを使用する
注釈：本資料はAI技術を用いて翻訳されています。
概要
ゲーム統合のベストプラクティスに従うことで、問題の発生を防ぎ、発生した問題の影響を最小限に抑え、プレイヤーにより良いユーザーエクスペリエンスを提供できます。
この記事では、ゲーム統合に使用するいくつかのベストプラクティスについて説明します。
接続の問題
ゲームのメインメニューからは、ゲームを初期化するためにいくつかの呼び出しが行われます。例えば、ログイン、ユーザープロファイルの取得、クラウドセーブ情報の取得、ストアの取得、ユーザーエンタイトルメントの取得、ロビーへの接続などです。これらの呼び出し中に問題が発生し、操作に支障をきたす可能性があります。このような問題はプレイヤーに適切に伝える必要があります。
避けるべき：すべてのエラーを 1 つのハンドラーにまとめる
すべての問題を一括で処理するエラーハンドリングを使用すると、具体的に何が問題だったかをプレイヤーに伝えることができず、一般的なエラーメッセージしか表示できません。これにより、プレイヤーはトラブルシューティングの手段がなくなり、サポートチケットを提出せざるを得なくなります。
推奨：プレイヤーのアクティビティを制限し、失敗ポリシーを実装する
ゲームはバックエンドからのエラーを適切に処理し、エラーの種類に応じてプレイヤーの操作を制限することで、ユーザーエクスペリエンスを段階的に制限する必要があります。例えば次のようなケースがあります。
- ログイン失敗が発生した場合、 適切なエラーメッセージを表示し、バックオフ再試行ループを実行しながら 1 分後と 5 分後に再接続を試みるカウントダウン UI を実装します。
- クラウドセーブの取得に失敗した場合、 バックグラウンドで再試行ループを使用してデータを取得しようとしながら、ゲームのデフォルトのオフライン値を使用します。
- ロビーへの接続に失敗した場合、 ゲームのマルチプレイヤーエリアを無効にし、マルチプレイヤーが一時的にアクセスできないことをプレイヤーに説明するメッセージを表示します。プレイヤーがストアやロードアウトなどの他のエリアを探索できる間、バックグラウンドで再試行ループを実行します。
各タスク（ログインなど）に対して、タスクが失敗した場合にクライアントに何をさせたいかを決定する指示を設定できる「失敗ポリシー」を実装する必要があります（例：ログして続行、ログインフローを停止、エラーダイアログを表示など）。ゲームロジックを変更せずにバックエンドからこの失敗ポリシーを制御できれば（例：クラウドセーブから JSON として最新の失敗ポリシーを取得）、さらに強力になります。
偶発的な DDoS 攻撃
オンラインゲームは、分散型サービス拒否（DDoS）攻撃の標的になることがあり、プレイヤーがゲームのオンライン機能を使用できなくなります。時には、無害なバグや最適化されていない呼び出しパターンにより、ゲームロジックから偶発的に DDoS が発生することがあります。このセクションでは、偶発的または実際の DDoS 攻撃を防ぎ、発生した場合に対処するためのベストプラクティスについて説明します。
避けるべき：DDoS を悪用可能なロジックをゲームに入れる
DDoS 攻撃の発生を防ぐために、バックエンドに自動的に呼び出すロジックの使用を避けてください。例えば、次の週のローリングを取得するために UTC の真夜中にクラウドセーブのゲームレコードを取得するなどです。このロジックは、適切に処理されない場合、偶発的な DDoS 攻撃を引き起こします。
推奨：手動、ローカル、オンデマンドのロジックを使用する
タイマーによる自動取得の代わりに、レベルのリロード時やプレイヤーがメインメニューに戻ったときなど、よりオンデマンドな方法でクラウドセーブのチェックを行います。また、適切な場合はデータのローカルキャッシュと非同期呼び出しのバッチ処理を行います。これにより、DDoS 攻撃に悪用されにくくなります。
推奨：早期かつ頻繁にコミュニケーションを取る
DDoS 攻撃が発生した場合、プレイヤーの混乱とフラストレーションを軽減するために、できるだけ早く、できるだけ最新の情報を提供するようにしてください。
推奨：影響を受けるエリアへのアクセスを防ぐ
ゲーム内でそれらのエリアへのアクセスをゲートすることで、攻撃されたエリアのみに被害を封じ込めます。
推奨：バックグラウンド再試行を実行する
オンライン機能へのアクセスを回復しようとするために、バックグラウンドで継続的に実行される再試行を設定します。これにより、できるだけ早く復旧できます。
ゲームで再試行を使用する際のベストプラクティスについては、次のセクションを参照してください。
バックグラウンド再試行
プレイヤーができるだけ早くオンライン機能へのアクセスを回復できるように、ゲームにバックグラウンド再試行を実装できます。このセクションでは、バックグラウンド再試行を使用する際のベストプラクティスについて説明します。
避けるべき：すべてのエラーに対して再試行を使用する
すべてのエラーが再試行を必要とするわけではありません。例えば、新しいプレイヤーがクラウドセーブのプレイヤーレコードを取得しようとすると、Player Record Not Found error (18022) が発生します。新しいプレイヤーはレコードを持っていないため、これは予想されることであり、再試行は必要ありません。
推奨：バックオフ再試行ループを使用する
ゲームは、積極的な再試行でバックエンドを圧倒しないように、バックオフ再試行ループを実装する必要があります。
バックオフ再試行ループは、失敗した呼び出しの試行ごとに再試行タイムアウトを指数関数的に増加させ、意図しない協調的な再試行の試みを軽減するために少量の分散を追加します。バックオフ再試行ループの詳細については、Amazon のこの「Retry with backoff pattern」の記事を参照してください。
今後の AGS SDK リリースでは、一部の API にバックオフ再試行ロジックが組み込まれます。詳細は近日公開されます。
プレイヤーコミュニケーション
フラストレーションを軽減し、より良いエクスペリエンスを提供するために、プレイヤーにできるだけ多くの情報を伝えることが最善です。
避けるべき：コミュニケーションを一般化する
ゲームのプロセスの複数のステップを説明するために広範なメッセージを表示すると、プレイヤーは何も起こっていないと思い、我慢できなくなる可能性があります。
例えば、マッチメイキングは完了するまでに複数のステップが必要です。「マッチメイキング進行中、お待ちください」のようなメッセージを使用すると、プレイヤーはマッチメイキングがプロセスのどの部分にいるのかわかりません。マッチメイキングがマッチを見つけるのに時間がかかっている場合、プレイヤーはスタックしているかエラーが発生したと思うかもしれませんが、実際には追加のプレイヤーを探しているだけかもしれません。これにより、プレイヤーはマッチメイキングをキャンセルし、サポートチケットを提出する可能性があります。
推奨：プレイヤーに何が起こっているかを伝える
マッチメイキングには、検索中、マッチ発見、参加中、サーバー待機中など、さまざまな状態があります。UI 要素を使用してプレイヤーに何が起こっているかを伝え、何かをする必要があるのか、ただ待つ必要があるのかをわかるようにします。
これはエラー状態にも適用されます。可能な限り関連情報をプレイヤーに知らせて、問題を修正しようとすることができるか（例：接続不良）、できないか（例：内部サーバーエラー）を知らせます。
この情報を提供することで、サポートチームとのコミュニケーションにも役立ちます。このプレイヤーコミュニケーションの哲学を、適用可能な場所でゲームに使用してください。
セキュリティ、アクセス制御、フェイルセーフ
機能アクセス制御を実装し、セキュリティのベストプラクティスを使用することで、問題が発生した場合の影響を最小限に抑えることができます。
推奨：Cloud Save ゲームレコードで機能キルスイッチを使用する
Cloud Save ゲームレコードを使用して、ゲームの特定の部分や機能へのアクセスを迅速に無効にする機能キルスイッチを作成する必要があります。これにより、発生した問題による被害の拡大を防ぐことができます。
バックエンドから Cloud Save のゲームレコードにアクセスできない場合のフォールバックプランを用意してください。優先順位は次のとおりです（高い順）：
- Cloud save
- 起動パラメータ（デバッグモードのみ）
- ローカル設定
- デフォルト値
Cloud Save を使用した機能キルスイッチのリファレンス実装を実装するためのガイドを準備中です。
推奨：すべてのロールと権限を再確認する
すべてのユーザーが必要最低限の権限を持っていることを確認する必要があります。例えば、ゲームが競争的なマルチプレイヤーである場合、または専用サーバーを活用している場合、統計を更新するユーザー権限を持たせたくありません。専用サーバーのみがこの更新権限を持つようにする必要があります。
AccelByte サービスの使用
このセクションでは、AccelByte が提供するサービスを使用する管理者と開発者向けの一般的なベストプラクティスについて説明します。
推奨：呼び出しの依存関係を理解する
ゲームクライアント、ゲームサーバー、カスタムサービスから行われるバックエンド呼び出しと、必要に応じて依存関係チェーンを理解する必要があります。
例：
- AccelByte バックエンドへのすべての呼び出しは、適切にログインしているか、有効な AccelByte トークンを持っているまで、ほとんどの場合ブロックされます。これは、ユーザー資格情報ログインであろうと、クライアント ID とシークレットを使用したログインであろうと同様です。
- ゲームは、プレイヤーインベントリやプレイヤーレコードの取得とストア情報の取得の間に依存関係を作成する必要はおそらくありません。
- チェックアウトまたは購入呼び出しを行う前に、ストアと価格情報を取得します。
特にバックエンドから順不同で返される可能性のあるコールバックについて、競合状態に関する仮定には注意することをお勧めします。
例：
- 開発中、AccelByte API への非同期呼び出しは非常に迅速に完了し、一見決定論的な順序で完了する可能性がありますが、異なる環境または異なる負荷プロファイルで実行すると、次のことに気付きます：
- コールバックが異なる順序で発火するようになった
- 誰かが誤ってコールバックの解決順序についてステートフルベースの仮定を行っていた
- 結果がキャッシュされているため、すぐに返されることがあるコールバック（例：要求関数が終了する前に発火する）を処理しますが、呼び出しコードはコールバック/デリゲートが「後で」トリガーされると仮定しています。
推奨：AccelByte サービスの使用状況を分析して最適化する
他のシステムと同様に、さまざまなシナリオでオンラインサービスのアクセスパターンのヘルスチェックを実行し、それに応じて最適化する必要があります。
ゲームの Well-Architected Review を調整できるように、AccelByte にご連絡ください。これには、最適化されていない使用法（例：不要な順次呼び出しチェーン、大きなペイロード、処理されていないエラーレスポンスなど）を検出するためのゲームのプロファイリングが含まれます。
例：
- ページネーションサポートを持つ API を使用している場合は、ページネーションを適切に使用してください。
max=<number>に大きな数値を使用すると、バックエンドに負担がかかり、レイテンシテスト中にゲームが認証に失敗したり、インターネット接続が悪いプレイヤーに悪いユーザーエクスペリエンスを作成したりする可能性があります。- SDK は、ページネーションの使用など、一部の API が適切に使用されていない場合に警告を表示するか、エラーを出す可能性があります。
- バックエンドでそのデータを変更するリクエストを発行する前に、ローカルにキャッシュされたデータを比較してみてください。例えば、クラウドセーブレコードを更新しようとしている場合、そのレコードで実際にデータが更新されていることを確認するチェックが必要であり、バックエンドへのリクエストを節約し、サービスへの不要な負担を防ぎます。別のケースは、プレゼンス情報の更新です。
- オブジェクトにダーティフラグを実装して、フラッシュまたは更新を行う時期を知ることをお勧めします。
- 意味のある場合は、設定可能な時間間隔で複数の順次 API 呼び出しをバッチ処理します。例えば、プレイヤーの統計に影響を与える頻繁なバルクゲーム内アクション。
- Bulk API が不足していると思われる場合は、AccelByte にお問い合わせください。喜んで議論させていただきます！
コンソール認証
認証への対応は困難な場合がありますが、その苦労を軽減したいと考えています。
推奨：AccelByte 認証ガイドラインを確認する
認証フローを成功させるために必要な手順のリストを準備中です。例えば：
- さまざまな名前空間、環境、設定の管理。
- PlayStation と Xbox のコンソール認証に合格するために知っておく必要があること。
- クロスプラットフォームゲームで新しいゲームパッチをロールアウトする。
これが早急に必要な場合は、AccelByte テクニカルプロデューサーにお問い合わせいただくか、カスタマーサポートのために support@accelbyte.net にご連絡ください。
ローンチとローンチ後
このセクションでは、ゲームのローンチ中およびローンチ後に最高のエクスペリエンスを得るための一般的なアドバイスを提供します。
推奨：最善を期待し、最悪に備える
誰もが成功したローンチを望んでいますが、何かがうまくいかない場合に備えて事前に計画してください。想像力を使って何が起こり得るかについて教育的な推測を行い、それらを書き留めてください。最悪の恐怖をリストアップしたら、次の質問を自問してください：
- 何かがうまくいかない場合、どのように検出しますか？
- この記事で提供されているような軽減策は実施されていますか？
- 問題が特定され、対応中であることをプレイヤーにどのように伝えますか？
- 軽減策をどれだけ早く実施でき、誰が実施しますか？
- 軽減策が実施された後の計画は何ですか？従業員は、ライブの問題が将来の作業よりも重要であることを認識していますか？ライブの問題に関する作業をどのように追跡しますか？
例えば：
サーバーの 20% がクラッシュしており、コアダンププロセスがコアコレクターサービスに負荷をかけてクラッシュさせています。最も人気のあるプラットフォームは、最新版に脆弱性があるためクライアントバージョンをロールバックしました。従業員の 1 人がローンチの 2 週目に睡眠不足で、誤って間違った Amazon Web Services (AWS) アカウントを削除しました。
この記事で提供されているアドバイスを使用して、これらのタイプの状況を防ぎ、計画し、対処してください。
推奨：負荷テストを実施し、破壊ポイントを特定し、軽減策を設定する
負荷テスト、浸漬テスト、スパイクテスト、ピークテストを実施します。システムに圧力をかけるバリエーションはたくさんあります。一般的に、最大容量と最大レートは、制限をテストする必要がある 2 つのメトリックです。これらの主要な運用メトリックに監視を追加し、メトリックが最大値に近づいたときにアラートを追加します。
例えば：
ゲームには専用サーバーごとに 10 人のプレイヤーがいます。AWS との契約で 100 台の仮想マシン (VM) があり、各 VM は 50 台の専用サーバーを実行できます。これで最大容量が定義されました（10 プレイヤー x 100 VM x 50 専用サーバー = 50,000 プレイヤー）。VM と専用サーバーの割り当てが平均して 1 分あたり 100 台の専用サーバーであると仮定すると、レートは 10 プレイヤー x 100 専用サーバー = 1 分あたり 1000 プレイヤーがゲームに参加できます。0 プレイヤーから 50,000 プレイヤーになるには、50 分かかります。この 50 分間、プレイヤーには何が見えますか？
ボーナス：マッチメイキング設計のヒント
オンラインサービス統合とは関係ありませんが、オンラインゲームの改善に役立つ可能性のあるボーナス設計のヒントをいくつか紹介します。
マッチメイキングルールとゲームの設計に基づいて多くの異なるキューを作成している場合は、プレイヤーがより満員のマッチに参加できるように Quick Match を実装することを検討してください。
ゲームと、ゲームにとって重要なことを制御するために持っているオプションを理解してください。プレイヤーを迅速にマッチに参加させたいですか（待機時間が短い）、それともより高いマッチ品質のためにプレイヤーをキューで長く待たせますか？
「優れたマッチメーカーは最高のマッチを作ることではなく、悪いマッチの数を最小限に抑えることです。プレイヤーは良いマッチがあったからといって Reddit に投稿しませんが、ひどいマッチにいた場合は投稿します。」- Laurent Bourcier、Moonshot studio。
マッチメイキングはゲームデザインに非常に特化している可能性がありますが、一般的には、より多くのプレイヤーが一緒にプレイすることを望んでいます。人間のエクスペリエンスは AI とプレイするよりも優れています。
より多くのプレイヤーを一緒にマッチングするための 2 つの良いアプローチがあります：
- フレキシングルールを活用して、まずプレイヤーを一緒にプレイさせ、次により少ない数のプレイヤーにフレックスダウンします。
- プレイヤーを参加させ、バックフィルを活用してプレイヤーが参加できるようにします。
{
"alliance": {
"min_number": 1,
"max_number": 1,
"player_min_number": 4,
"player_max_number": 4
},
...
"alliance_flexing_rule": [
{
"duration": 10,
"min_number": 1,
"max_number": 1,
"player_min_number": 3,
"player_max_number": 4
},
{
"duration": 20,
"min_number": 1,
"max_number": 1,
"player_min_number": 2,
"player_max_number": 4
},
{
"duration": 30,
"min_number": 1,
"max_number": 1,
"player_min_number": 1,
"player_max_number": 4
}
],
"auto_backfill": true,
}
最後に、ソロプレイヤーを活用してパーティーを完成させ、バックフィルとより制限の少ないマッチメイキング要件（「Quick Match」オプションなど）で満員でないマッチを埋めます。
この記事の執筆を手伝ってくれた Final Strike Games と Dreamhaven の友人たちに特別な感謝を捧げます。