次の方法で共有

PlayFab 消費: ベスト プラクティス

  • [アーティクル]

PlayFab の消費ベース料金モデルでは、タイトルの実際のサービス使用量のみを支払います。 しかし、これには明らかな疑問が生じます: 必要なすべての機能を実装しながら、これらのタイトルを最大限に最適化してコストを節約する方法は? このドキュメントでは、これらの詳細について詳しく説明し、事前の計画に役立つベスト プラクティスについて説明します。

タイトルを開発モードからライブに移行する前に、ゲーム マネージャーの [請求概要] タブでメーター情報を確認できます。 最初の練習として、別のタイトルを使用して定期的にメーターを確認し、実際のプレーヤーのアクティビティのメーターの使用状況を確認することをお勧めします。 開発モードでは複数のタイトルを使用できるため、開発段階でその使用をチェックポイントにしたいときにその場でタイトルを作成し、完了後にそれらのタイトルを削除することができます。

イベント、プロフィール、コンテンツと構成、CloudScript、Insights、マルチプレーヤー サービスの 6 つの消費メーターがあります。 タイトルの最適化を開始する最善の方法は、タイトルが使用する各メーターを確認し、時間の経過とともにどのように累積するかを確認することです。 これにより、いくつかの明らかな改善につながります。 メーターの詳細については、料金メーター をご覧ください。

イベント

PlayFab には、PlayStream とテレメトリの 2 種類のイベントがあります。

PlayFab は PlayStream イベントを処理して、指定した PlayStream アクションをトリガーするかどうかを確認し、ユーザー セグメンテーションを更新します。 一部の PlayStream イベントは、認証や統計情報の更新などのサービス機能への呼び出しの結果として自動的に生成されます。 タイトルは、この機能を拡張するために、独自のカスタム イベントを生成することができます。

テレメトリ イベントは PlayStream によって処理されません。 これらのイベントは分析に使用され、データ ウェアハウスに直接移動します。 テレメトリ イベントは PlayFab で自動的に生成されません。 これらはタイトルによって生成されるカスタム イベントです。

いずれの種類のイベントについても、データのペイロードが大きくなると、メーターの使用量が増加します。 必要なデータのみを送信するようにして、全体的な使用量を減らすことができます。 おおまかな目安として、特定のイベントでは、イベント本文のデータ 1 KB ごとに問題のメーターが 1 ずつ増加します。

使用に最適なイベント パスを選択するには、生成する各カスタム イベントの使用方法について明確な計画が必要です。 タイトルのオフライン評価にのみ必要なイベントは、テレメトリ ルートに移動する必要があります。 Telemetry イベントの超過料金は PlayStream の半分以下であるため、これによりコストを大幅に削減できます。

ビルド済みの SDK のいずれかを使用している場合は、PlayStream Event Model リファレンス で説明されているように、ユーザーの行動に関する分析データが自動的に生成されることを覚えておくことが重要です。 オプションのイベントをオフにするには、PlayFab ゲーム マネージャーのゲームの [設定/データ収集] タブで分析設定を変更します。 同様に、デバッグ中に CloudScript を実行する場合は、「PlayStream イベントの生成」オプションをオンにしておくことをお勧めしますが、ライブに移行する前にそれを無効にしておく必要があります。 PlayStream アクションによってトリガーされる CloudScript の場合、実際の動作をデバッグする必要がある場合は、後でいつでもオンにできます。

プロフィール

プロフィールは、インベントリ、保存データ、統計情報などの一般的な要素を含む、実質的に「プレーヤーに関するすべて」です。 また、前述のユーザー セグメンテーションなど、PlayStream の LiveOps 機能を通じて、独自のエクスペリエンスを実現するために使用するメタ情報も含まれています。 さらに、タイトル データ、カタログ、ストアなど、タイトルレベルのレガシ機能の一部がこのメーターに含まれています。これは、それらのデータ実装がユーザー データと実質的に同じであるためです。 このメーターのセットはすべてのプレイヤーのアクションとプレイヤーに対して行われるアクションによって駆動されるため、圧倒的に最も最適化計画を必要とするものです。

料金メーターによって取得される使用量の主な要因は、読み取り、保存、および書き込まれるデータの量と、測定されるデータを生成する API を呼び出す頻度です。

これらのメーターで「スピン」が発生する特定の API 呼び出しの詳細については、料金メーター をご覧ください。

使用パターンは似ているため、ユーザー データと統計情報から始め、次にプレーヤーのインベントリ管理について説明します。

データと統計情報

ユーザー データの使用状況を評価する場合、イベントの場合と同じ概算ロジックが適用されます。1 KB ごとにメーター カウントが 1 ずつ増加します。ただし、この計算では、呼び出しの各「要素」を個別のものと見なす必要があります。 ユーザー データを更新する呼び出しの各キーと値のペアは、個別にカウントされます。 読み取りの場合、この 1 KB の計算は、キーと値のペアの数に関係なく、返されるデータの合計に適用されます。 つまり、 100 バイトずつ 10 個のキーを書き込むと、各キー値ペアの書き込みが最小の 1 KB になるため、プロフィールの書き込みメーターが 10 "ティック" になります。一方、これらの 10 個のキーを読み取ると合計 1 KB であるため、1 "ティック" になります。 使用方法の詳細については、料金メーター をご覧ください。

統計はプロファイルを更新し、リーダーボードにも影響を与える可能性があるため、少し複雑です。 一般的なルールとして、更新される各統計は完全なプロファイルの更新として考えることができますが、読み取りは各呼び出しで読み取られたデータの合計サイズに基づきます。 また、ストレージはギガバイト （GB） あたりの価格であり、統計情報では通常数バイトしか消費されないため、読み取りと書き込みに重点を置きます。

合計データ サイズは重要であるため、それを最適化することが最初のステップです。 幸いなことに、これにはさまざまなよく知られた手法があります。アイテムのスペルアウトされたテキストの代わりに列挙型または ID を使用したり、大きなデータをバイナリとしてパックしたり、ビットフィールドを使用してデータをより小さなスペースにパックしたりします。 完了したら、次のステップは、いつそれらの読み取りと書き込みの呼び出しを行う必要があるかを慎重に評価することです。

PC またはコンソールの開発 （特にシングル プレイヤー ゲーム） をしている場合、これは新しいパターンになる可能性があります。 ただし、これらの環境では、クライアント デバイスでのリソース ヒットとガベージ コレクションに注意する必要があります。これらは重要な時にパフォーマンスを低下させる可能性があるためです。 タイトルがクラウド内のリソースを使用する場合、パフォーマンス コストに加えて、各リソース ヒットに実際のコストがあると見なして、ロジックを拡張する必要があります。

読み取りと書き込みの最適な頻度をどのように決定しますか? データと統計情報をより頻繁に更新したい開発者にとって 2 つの最も一般的な懸念は、不正行為からの保護と、プレーヤー間の対話のため、またはゲームが予期せず終了した場合のデータ損失を防ぐために、サーバー側にタイムリーな情報を保存することです。

不正行為からの保護

重要なセキュリティを確保するためにバックエンド データを絶えず更新する必要があるように思えるかもしれませんが、ゲームがセッションの完全なサーバー認証制御を必要としない場合、頻繁な更新が必要になることはほとんどありません。 まず、基本的な問題は、実際に必要なセキュリティの量です。

一部のゲーム、特にゲーム内の広告を通じて主に収益化し、スコアボードを持たないゲームの場合、不正行為はあまり問題になりません。 この場合、クライアントが送信するデータを信頼することは、実行可能なアプローチになります。そのデータのセキュリティが実際には問題にならないためです。 不正行為を特定し、その対処方法を決定するには、プレーヤーのイベント、データ、統計情報を確認するプロセスを実装することをお勧めします。

競争の完全性をサポートするか、プレーヤー全体のエクスペリエンスを保護する必要がある他のゲームでは、より強力なセキュリティが重要になります。 特定の要件に応じて、特定のアプローチにより、これらの状況でのデータの読み取りおよび書き込みの頻度を減らすことができます。

ゲームがリアルタイムでない場合、推奨されるアプローチの 1 つは、一定期間 (多くの場合、数分かかるゲームの「ラウンド」) にわたってプレイヤーのゲームに関する情報を集約し、そのデータをスクリプトに送信することです。 それが有効かどうかを判断します。 評価する主な要素はゲームに依存する可能性がありますが、考慮すべき一般的な概念のいくつかの例を次に示します:

  • 前回のセッション レポートからどのくらい経ちましたか、また、クライアントは最新のセッション レポートでどれくらいの期間プレイしたと言っていますか?

  • プレーヤーはどのスコアを登録しましたか? レベルや装備などを考えると、それはそのプレーヤーにとって妥当ですか?

サーバー権限のあるプレーヤーの状態を頻繁に更新する必要があるなど、よりリアルタイムの要件があるゲームの場合、PlayFab に保存されたデータを頻繁に更新するよりも、ホストされているゲーム サーバーを使用する方が良い解決策です。 そのモデルでは、セッションの開始時にプレーヤーをサーバーに接続します。 サーバーは、プレーヤーのサービスから必要なデータをすべて読み取り、クライアントが必要な速度でサーバーとデータを交換しながら、そのプレーヤーのシミュレーション状態を長期にわたってホストします。 次に、サーバーは PlayFab の「長期ストレージ」を、セッションの終了時、またはセッションが特に長い場合は数分ごとに、プレーヤーの最新データで更新します。

これは、リアルタイム マルチプレイヤー ゲームで使用されるモデルです。 これは、サーバー権限のあるチェックが必要なシングルプレーヤーのタイトルにも有効な手法ですが、その頻度がプレーヤーごとに 1 分間に数回しかない場合は、Azure Functions CloudScript の方が適しています。 CloudScript の合計コストは簡単に計算できます。 これは、消費する総ギガバイト秒であり、実行ごとに最小 128 MB および 100 ミリ秒と、スクリプトが使用する他のすべてのサービス API 呼び出しの通常の計算を加えます。 たとえば、スクリプト コードとスクリプト内の変数の使用量の間のメモリ フットプリントの合計を 250 MB にする場合は、そのスクリプトを 4 秒間 （複数のユーザー間で） 実行して、1 GB/秒にする必要があります。 そのスクリプト コード内で、エンティティ オブジェクト、タイトル データ、ユーザー データなどを読み書きする場合は、それらの各呼び出しがプロファイル メーターに与えるスピンを計算する必要があります。 ホストされているゲーム サーバーのコストは、実行しているサーバーの数に依存し、サーバーで同時にホストできるプレーヤーの数に依存するため、損益分岐点が 2 つの間のどこにあるかを判別することは必ずしも簡単ではありません。 ただし、スクリプトを頻繁に呼び出す必要があり、そのたびにサービスからデータを読み書きする必要がある場合は、ゲーム サーバー ソリューションの方が適していると考えられます。

データの適時性

書き込み率の高い開発者の間でよく耳にするテーマの 1 つは、プレーヤーが進捗状況を失うことを懸念しているということです。 保存する前にプレーヤーがゲームを終了し、次回ゲームをプレイするときにローカル状態を使用できない場合、またはその状態をデバイス間で移動する必要がある場合は、PlayFab に保存されているプレーヤーの状態情報を次のように設定する必要があります。 できるだけ最新のものに。

多くのゲームでは、サービスに対する更新のハートビートを定期的かつ低頻度 (たとえば、15 分ごと) に行うことで、この問題に対処できます。 ただし、その頻度を延長または短縮するための追加のロジックを含めることも役立ちます。 次に例を示します。

  • プレーヤーが積極的に重要なことを行った場合に、内容が失われないように、即時書き込みを実行してタイマーをリセットする「重要な更新」オーバーライドを含めます。

  • プレイヤーの入力がないままゲームが進行し続ける場合、長期間入力がない場合はハートビート期間を長くすることを検討してください。 これは、プレイヤーが一晩中実行したままにすることが多いアイドル ゲームの場合に特に重要です。

  • ユーザー メニューのボタンなど、直接更新を強制する方法をプレーヤーに提供します。 ただし、この場合、クライアント デバイスから PlayFab への呼び出しが実際に行われる速度を必ず調整して、プレーヤーがそのボタンを何度も押して毎回呼び出しを生成しないようにしてください。

次にゲームをプレイするときにクライアントが状態情報を持っている場合は、タイムスタンプをサービスからのデータのタイムスタンプとローカルに比較して、どちらを使用するかを決定するか、プレーヤーに選択オプションを提供することもできます。

プレイヤーのプロフィール情報は、自分以外のものに関連する場合があります。 一部のゲームでは、競合を促進するか、非同期のフレンド インタラクションやチャレンジなどを通じてプレーヤーのエクスペリエンスに直接影響を与えるかどうかに関係なく、クロスプレーヤーをクエリする必要がある場合があります。

競争では、スコアボード は、サービスへの 1 回の呼び出しで他のプレーヤー （多くの場合、現在のプレーヤーのスコアに近いプレーヤー） に関する情報の一部を共有することにより、その緊張を生み出す理想的な方法です。 Profile View Constraints を使用して、統計やタグなどの他のプロフィール要素を返すことができるため、これらの他のプレーヤーに関する豊富な情報を提示できます。 ただし、スコアボードのすべてのプレーヤーのリストを反復処理せずに、それぞれから追加情報を読み取ろうとすることが重要です。プロフィールの読み取りの合計数が急速に増加し、コストが増大するためです。

セッションでクロスプレーヤー データを直接使用するゲームの場合、最も一般的な最適化は、ローカル プレーヤーが対話している少数の特定のプレーヤーに関する情報のみを読み取ることです。 リアルタイム アクション ゲームの場合、これは通常、セッションをホストしているサーバーで行われます。 その他 （プレーヤーがお互いのベースを攻撃できるゲームなど） の場合、最も一般的なアプローチは、すべてのデータをローカル デバイスに読み取るか、ローカル プレーヤーが知っておくべき他のプレーヤーのデータのサブセットのみをローカルプレーヤーに送信することです。 前者を実行するゲームは、サーバー側のロジックを使用して、クライアントが送信する最終結果を評価します。 後者を実行するゲームは、ローカル プレーヤーがデータにアクセスする必要がある場合、セッション中にデータを繰り返し更新し、より多くのデータを使用します。 しかしそれでも、サーバー側のロジックを使用して最終結果を評価します。 繰り返しますが、これをスクリプトで行うべきか、それともホストされたサーバーで行うべきかを決定する際の転換点は、頻度次第です。 それが 1 分間に数回を超える場合は、そのデータを必要とするセッションの部分でホスト サーバーを使用することをお勧めします。

エコノミーとインベントリ

インベントリ、およびエコノミー全般には、別のアプローチが必要です。 プレーヤーが実際の （お金） または知覚された （仮想通貨または消耗品のコンテナー） 値の何かを放棄している場合、彼らはトランザクションが優先されることを暗黙的に想定しているという事実を避けられません。 アプリ内購入のあるゲームでは、プレーヤーが実際の通貨で購入した場合のプロフィール メーターの増分は、わずかなコストです。 多くのタイプのゲームでは、インベントリの更新は頻繁ではないため、全体的な使用量を大幅に増加させる心配はほとんどありません。 ただし、ゲーム内での収益化がなくても、より頻繁にインベントリを更新する場合は、コストを削減するための最適化の秘訣があります。

ベスト プラクティスは、文字通りの意味でのインベントリのみを、合理的に有限なインベントリとして考えることです。 たとえば、インクリメンタル （または「アイドル」） ゲームでは、プレーヤーが取得した各リソースをアイテムとして考え、プレーヤーが別のアイテムを購入するたびに合計数をインクリメントするのは魅力的です。 ただし、プレーヤーがこれらのアクションを実行する頻度を計算すると、そのモデルは急速に崩壊します。 すぐに、セッションで数百回または数千回もメーターを打つ各プレーヤーに対処する必要があります。 このような状況では、これらの要素をユーザー データと見なし、上記のプロフィール セクションの推奨事項を使用してサービスに更新することをお勧めします。

インベントリの更新率が高いゲームに関しては、データの適時性の問題に戻ります。 たとえば、アクション ゲームはプレイヤーが持っている弾丸の数を追跡するかもしれませんが、特にゲームの状態が ホストされたサーバー。 Stackable を使用すると、アイテムの多くの仮想インスタンスをカウント付きの単一の実際のインスタンスとして表すことができるため、パフォーマンスとコストの利点が得られます。 多くの場合、アイテムのスタックへの変更を時間の経過とともに集約し、セッションの最後に、またはセッション全体で定期的に更新できます。 スタックを更新するときは、Player Item Management - Modify Item Uses を呼び出すことをお勧めします。スタックに追加するためにそれぞれ処理してクリーンアップする必要があるアイテムの N インスタンスを追加するのではなく、スタックのカウントを変更できるかどうかを確認します。

その性質上、収集可能なカード ゲームなどの特定のゲーム ジャンルでは、やや高い割合でプレーヤーのインベントリを更新する必要があります。 ただし、ここでも、インベントリの変更を集計してプロフィール メーターの総使用量を減らす機会はまだあります。 たとえば、ドロップ テーブル を使用するゲームでは、デザインには、いくつかの異なるドロップ テーブルのそれぞれからの 1 つ以上の「プル」を持つコンテナーを頻繁に使用します。 通常、これらのプルが偶発的なアクションにすぎない場合、増分コストは問題の原因にならない程度です。 しかし、プレーヤーがそれらのコンテナーの多くを収集し、短期間に複数を開くことができる場合は、「open N」または「open all」オプションを提供することもできます。 その場合は、PlayFab CloudScript using Azure Functions またはカスタム ゲーム サーバーを使用して、ドロップ テーブルのセットの Player Item Management - Get Random Result Tables を取得するか、インベントリ アイテムを生成せずに Player Item Management - Evaluate Random Result Table を呼び出します。 次に、必要な場所にインスタンスを追加し、残りのアイテム スタックの数を更新するだけで、プレーヤーのインベントリをはるかに効率的に更新できます。

コンテンツと構成

プロフィールが主にプレーヤーに関するものであるのに対し、コンテンツと構成は主にタイトルに関するものです。 このメーターには、プッシュ通知、メール サービス、タイトル ニュースなど、タイトルレベルのコンポーネントがすべて含まれています。 さらに、これはエンティティ ファイルの使用状況を追跡するために使用されるメーターです。 同様に、CDN ファイルをアップロードおよびダウンロードするための URL のリクエストはこのメーターで追跡されますが、CDN のコストは別個であり、Content Delivery Network （CDN） で説明されているようにダウンロードされた総ギガバイトに基づいて請求されることが重要です。 コンテンツと構成の読み取りおよびストレージ メーターの計算は、データのサイズに基づいているという点でプロファイル メーターと似ていますが、単位は明らかに 1 KB より大幅に大きくなります。 コンテンツおよび構成の書き込みメーターの場合、書き込み操作の合計数のみに基づいており、書き込み操作ごとにメーターが 1 ずつ増加します。

補足として、エンティティ ファイル システムは、タイトル、グループ、または個々のプレーヤーに関連付けられているかどうかに関係なく、大きなデータに推奨されるサービスです。 プレーヤーごとに大量のデータを保存するゲームの場合、エンティティ ファイル システムの方が一般に費用対効果が高くなります。 ただし、これらの更新の頻度は追跡される使用量に影響することを覚えておいてください。 更新する必要がある頻度に対して、必要なファイルの数を最適化することをお勧めします。

コンテンツと構成メーターのコストを最適化するという観点から、追跡する最も重要なものとして、タイトルがめったに変化しない構成データを要求する頻度があります。 これは主にタイトル データであり、ゲームのバランス/チューニング データ、実績の定義、ローカリゼーション データなど、すべてのユーザーで同じゲームの側面を管理するために一般的に使用されます。

CloudScript を使用するゲームにおいて、スクリプトへの呼び出しごとにこのタイトルレベルのデータに依存していることがわかった場合は、そのデータをスクリプトに直接「ベイク」することを検討してください。 これを行うには、スクリプト自体にハードコードされたデータとして定義するだけではなく、静的変数をキャッシュの手段として使用することによって、仮想マシン （VM） インスタンスごとに 1 回サービスから情報を読み取ります。 このようにして、タイトルレベルのデータは、特定の VM が初めてスクリプトを実行するときに読み込まれ、その後の実行でその VM によって再利用されます。 ここで注意すべき 3 つの点: 最初に、スクリプトは多くの異なるユーザーによって使用されるため、実行間で個々のユーザーに一貫性があると見なされるものはありません。 もう 1 つは、1 人のプレーヤーが呼び出しごとに異なるマシンをヒットする可能性があるため、データの処理はステートレスと見なす必要があります。 最後に、そのデータの経過時間を追跡し、定期的に再読み込みして、最新バージョンであることを確認する必要があります。

CloudScript

これは PlayFab サービスの主要な「拡張ジョイント」の 1 つであり、クライアント デバイスまたはサーバーからサーバー認証ロジックを実行したり、PlayStream ルールを介してトリガーすることもできます （たとえば、プレーヤーがセグメントに入るとき)。 カスタム ゲーム サーバーをホスティングする場合とは異なり、スクリプトの実行にかかるギガバイト秒 （GB/秒） に対してのみ料金がかかります。実行ごとの最小値は 128 MB と 100 ミリ秒です。 したがって、スクリプトが合計 250 MB のスペース （スクリプト コードとデータの間） を使用する場合、1 GB/秒に到達するには、合計 4 秒 （複数の実行で可能性が高い） を実行する必要があります。

CloudScript のユース ケースは通常、プレーヤーに代わってアクションを実行することを中心に展開するため、プロフィールとコンテンツ/構成メーターに関する最後の 2 つのセクションでは、最適化について考慮すべき大部分を取り上げました。 ただし、タイトルの実行の総数は、CloudScript の使用状況の測定の一部として追跡されるため、プレーヤーごとに CloudScript を呼び出す必要がある頻度を確認することは重要です。 一部のゲームでは、CloudScript の反復呼び出しでデータ ストアを管理するよりも、ホストされたゲーム サーバーを使用してアクティブ プレーヤー用の「ホット」データ ストアを作成する方がはるかにコスト効率が高い場合があります。

Insights

このメーターは、イベントの取り込みとエクスポートからイベント履歴の検索やデータ エクスプローラーのクエリに至るまで、PlayFab サービスのすべての分析機能に関連付けられています。 ここでの使用量は、イベントの処理速度、(ゲーム マネージャーでのクエリ用に) ホストされた「ホット」な状態に保ちたいイベント データの量、およびデータ エクスプローラーを介してデータを評価するためにサービスを使用する量によって影響を受けます。 データに直接接続するクエリや視覚化ソフトウェア。 このメーターは、ゲーム内アクティビティ （イベント） とゲーム外アクティビティ （分析） の両方の影響を受けます。

つまり、Insights のコストは、プレーヤーから取得するイベント データの量と、そのデータに対して実行する分析処理の量によって決まります。 ベスト プラクティスの観点では、上記のイベントに関するアドバイスは前者に適用されますが、後者の場合は 2 つの方法でコストを制御できます。 まず、最も簡単なのは、ゲーム マネージャの [Insights 管理] タブでタイトルの合計ストレージを設定して、PlayFab に保持するイベント データの合計量を制御することです。 次に、同じタブで、タイトルのパフォーマンス レベルを設定できます。 これにより、タイトルに割り当てられる CPU リソースの合計量と、イベント履歴のクエリ用に「ホット」に保存されるデータの量が決まります。 それぞれに必要な量は、データ分析チームのメンバーのニーズによって異なります。そのため、これを確認して、設定がどうあるべきかを理解することをお勧めします。

Insights とその使用方法については、「PlayFab Insights とは」を参照してください。

Insight のベスト プラクティスについては、「ベスト プラクティスと FAQ」を参照してください。

マルチプレイヤー サービス

料金は全く変更されていないため、これは最も簡単です。 つまり、ホスト型 Multiplayer Servers と Party サービス は常に使用量に基づいて課金されます。

特にホスト型ゲーム サーバーの場合、できるだけ多くのプレーヤーをサポートするために同時に実行する必要があるサーバー コアの数を最適化することで、コストを最小限に抑えることができます。

これらのサーバーで ping 時間を短くすることが重要な場合は、サーバーを実行する地域を選択できます。 ほとんどのゲームでは、プレーヤーの最大集中は特定の主要な地域に限定されますが、プレーヤーの人口が広範囲に分散している場合 （特に、ゲームの長い尾にいるとき） は、プレーヤーの近くのすべてのリージョンでサーバーを実行するコストと、プレーヤーが少ないエリアでのプレーヤーのサブセットに対する長い ping 時間の影響を比較検討する必要があります。 これに役立つことの 1 つは、QOS サービス を使用して、プレーヤーを配置する地域を選択し、その地域を存続させるためにその地域でプレイする必要があるプレーヤーの最小数に対するカットオフを決定することです。

費用をかけずに開発を進めることができるように、ホスティング サービスではかなりの数の無料サーバー時間を提供しています。また、Party サービスはすべての開発モード タイトルで無料です。 また、パーティー サービスは、Xbox Live のサインイン プレイヤーですべて無料で使用できます。また、標準、プレミアム、エンタープライズの各層のタイトルについては、21st Century Communications and Video Accessibility Act (CVAA) のコンプライアンスを支援するために、追加費用なしで接続、音声、Cognitive Services (音声文字変換および翻訳) を十分に利用できます。

Live ゲームの管理

これはメーターの基本をカバーしていますが、タイトルが公開されたら、何を考えるべきですか? プレーヤーのコミュニティの管理には、主に分析 （上記のセクションの Insights） とコンテンツと構成の更新が含まれます。 さらに、ほとんどのゲームでは、ゲーム自体との通常のやり取りの外でプレーヤーと関わりを持つ必要があります。 再契約キャンペーン （プレイヤーを呼び戻す） からメタゲーム アクティビティのコミュニティ特典まで、そしてゲーム外でのコミュニティ作業に対するプレイヤーへの感謝まで、最近の一般的な方法は LiveOps テクニックを使用してプレイヤーを維持することです。

このための鍵の 1 つは、コストを低く抑えるだけでなく、ロジックを迅速に処理するために、セグメンテーションを明確に定義されたグループに効果的にターゲティングすることです。 たとえば、プレーヤーの再契約を考えてみましょう。一定期間プレイを停止した後に、プレーヤーを再び呼び戻すことができます。 このアプローチを使用するには、いくつかの経過したユーザーの時間枠を定義することです。たとえば、3、7、および 21 日間プレイしていないプレーヤーです。 それぞれについて、単純な「会いたかった」というメッセージから始まり、「無料のゴールドやエネルギーなどを差し上げます」というメッセージで最高潮に達するまで、再エンゲージメントに異なるアプローチを取ることができます。 メッセージ (もちろん、プレイヤーのアカウントに自動的に追加されます)。 それぞれに推奨されるアプローチは、プレーヤーが最後にサインインしてゲームをプレイした時間に基づいて 1 時間のウィンドウを定義することです。 そうすることで、プレイヤーが最後にプレイした時間をターゲットにするだけでなく、操作をできるだけ効率的にするために、セグメント内のプレーヤーのセットを最小化することもできます。 これらの各セグメントで 1 時間に 1 回起動するスケジュールされたタスクを使用して、メッセージを送信し、アイテムまたは仮想通貨 （VC） をプレーヤーのインベントリに追加します。

サマリー

最終的に、PlayFab のようなバックエンド サービスの使用を決定するのは、ゲームに必要な機能です。 実際、それはすべて 1 つの包括的な質問に要約されます: これらの機能にはどのような要件がありますか? セキュリティ、データの適時性、プレーヤーの相互作用/競争のレベル、またはその他すべてを優先するかどうかに関係なく、バックエンド データとのより高いレベルの相互作用に向かって進むことができるいくつかの要因があります。 これらの要件を批判的な目で見て、どれが難しいニーズでどれがそうでないのかを識別できることは、ゲーム内の他のコードの最適化と非常によく似ています。 リソースの使用率が高い場所を注意深く調べ、本当に必要かどうか、またはロジックを再設計して使用量を減らす方法があるかどうかを判断することが重要です。

インタラクションがプレーヤー間でリアルタイムの場合、それはそのインタラクションの複雑さによるものです。 このタイプのほとんどのゲームでは、シミュレーションの状態を管理し、セッションの最後 （またはセッションが長い場合は数分ごと） にのみバックエンド データを更新するホスト型サーバーが通常最も適しています。 ただし、協力的なゲームや、友達とのみ （または友達に対して） プレイするなど、やり取りが完全に信頼されている場合が多く、不正行為のインセンティブを最小限に抑えます。 さらに、セッションのデータをチェックする方法について最小限の要件しかなく、両方のプレーヤーが各セッションの後にレポートを送信するだけでよいので、サーバー側のチェックで 2 つを比較できます。

リアルタイム要件のないゲームでは、プレーヤーが本当に最新の精度を必要とするかどうかを検討してください。 強いコミュニティ インタラクションを伴う非常に競争の激しいゲームでは、それはよくあるケースです。 ただし、多くのゲームでは、数分前の情報はプレーヤーのエクスペリエンスに影響を与えません。

見通し

サービスとして、PlayFab は進化を続けています。また、必要な機能を強化するサービスを利用しながらコストを管理できるように、ドキュメントを更新し続けます。 これをどのように改善できるかについての提案やご意見がある場合は、メイン サイトの [お問い合わせ] フォームからチームまでお気軽にお問い合わせください。 検討している機能を最適化する方法に関するフィードバックや、PlayFab の使用に関する一般的な技術的な質問については、コミュニティ フォーラムからサポート チームにお問い合わせいただくか、有料レベルの場合はサポート チームにお問い合わせください。 このサービスを利用するには、PlayFab ゲーム マネージャーでチケットを送信します (タイトルの任意のページで右上隅にある [?] をクリックします)。 開発者コミュニティとのパートナーシップにより、成長を続け、お客様のニーズを先取りするために必要なフィードバックが提供されています。いつでもご連絡をお待ちしております!