4. TIPS 集

4.1. ランキング

ここではランキング機能を使用する上での TIPS を紹介します。

多くのカテゴリでランキングを使用したい

RankingClient::GetRanking() を使用する場合、同時に一つのカテゴリしか指定できません。多くのカテゴリを使用する場合にはカテゴリ数だけ API 呼び出しを行う必要があります。しかし、ランキングの API の呼び出し回数は 5 分 15 回の制限があるため、最大で 5 分間に 15 のカテゴリしか取得することができません。

このようなときには、制限付きですが、キャッシュつきランキングを使用することで対応が可能です。キャッシュつきランキング取得は RankingClient::GetCachedTopXRanking() を使用することで利用できます。 この API を使用すると TOP ランキングを複数カテゴリから合計 100 件まで取得することができます。例えば、Top 5 ランキングのみ必要であれば、 20 カテゴリのデータを取得することができます。

また、キャッシュつきランキングは、他のランキングの API と比較してアクセス頻度制限が緩められており、5 分間に 20 回の呼び出しが可能です。上記 Top 5 ランキングであれば、5 分間に 400 カテゴリ分のデータを取得することが可能です。

キャッシュつきランキングを使用した場合、自分でスコアを登録しても、反映されるまで最大 5 分の時間がかかります。この場合ランキング登録直後に Top ランキングを取得しても自分のスコアが含まれていないランキングを取得することになります。このケースに対応するために、RankingCachedResult::LocalUpdate() を用意しています。この API に自分のランキングをセットすることで、自分のランキングをローカルでマージした状態のランキングを取得することができます。

キャッシュつきランキングで取得できるカテゴリ数は NMAS を使用して設定します。クライアントから設定することはできません。

色々なランキングを高い頻度で使用したい

RankingClient::GetCachedTopXRanking() を使用しても呼び出し頻度制限に収まらない場合や、Top ランキング以外のランキングを高い頻度で取得したい場合は、ランキング 2 の使用をご検討ください。
ランキング 2 では、ランキングを取得する Ranking2Client::GetRanking() の呼び出し頻度制限が 1 分間に 20 回までとなっており、また、すべての API について呼び出し回数のカウントが独立となっています。
ただし、ランキング 2 ではグループによるスコアの絞り込みが出来ないなど、ランキングとは仕様が異なる点がありますので、ご注意ください。

ランキングにたくさんのスコアを登録してデバッグをしたい

ランキング機能のデバッグ時には、ダミーデータを登録しての確認を強く推奨します。NEX のランキング API は一部、取得範囲に制限をかけており、ランキング数によって挙動が変わる可能性があります。具体的には、範囲ランキングの取得範囲を設定するためのオフセット値は、1000 未満の値にのみ対応しています。これ以上の値をオフセットとして指定すると、API の呼び出しがエラーになります。ダミーデータの登録を行うことにより、このようなランキング登録数によってフローが変わるようなケースの確認をすることができます。

ダミーデータの登録は、NMAS を使用することで利用できます。登録件数については、1500 件以上を推奨します。サーバ負荷に影響しますので、ダミーデータの総登録数は 100 万件までにしてください。また、ダミーデータ登録には時間がかかりますので、少ない件数から徐々に登録件数を増やしていくことを推奨します。

バージョンアップでランキングの互換を切りたい

バージョンアップ前後でランキングの互換を切りたい場合、バージョンアップ前後でカテゴリを変更し、投稿先を変更することで対応する事を推奨します。

バージョンアップ時の更新を必須とし、ランキングのデータをリセットすることも可能ですが、バージョンアップ版の配信時間と、サーバーのリセット時間、ユーザーをサーバーから一斉退出させる調整が必要になります。また、複数のリージョンでリリースしているタイトルについては、ゲームサーバーが共通になりますので、互換を切る場合、全世界同時にバージョンアップを行う必要があります。可能であればカテゴリの変更を行う事を推奨します。

リージョン毎にランキングを分けたい

ゲームサーバーをリージョン毎に分けることはできないため、リージョン毎にランキングを分けたい場合には、リージョン毎に別のカテゴリを使用するようにしてください。

データストアと連携したい

ランキングにスコアを登録する際にユーザーに関するデータなどを含めたい場合には、そのデータをデータストアにアップロードし、ランキングのスコアと紐づける方法があります。

あらかじめスコアを登録するユーザーはデータストアに必要なデータをアップロードしておき、そのデータのデータID を保管しておきます。そして、 RankingClient::UploadScore() を実行する際に、RankingScoreData オブジェクトのパラメータにデータストアのデータID をセットします。そうすることにより、ランキングを取得したユーザーはデータID を元にデータストアからデータをダウンロード出来ます。

4.2. マッチメイク

ここではマッチメイク機能を使用する上での TIPS を紹介します。

バージョンアップ時に、バージョンアップ前後のソフト同士でマッチメイクしないようにしたい

バージョンアップ前後でマッチメイクの互換を切りたい場合、バージョンアップ前後でゲームモードを変更し、検索条件を変更することで対応する事を推奨します。

バージョンアップ版配信後にすべてのユーザーがバージョンアップを行った状態でサーバーにアクセスするように設定することも可能ですが、バージョンアップ版の配信時間にあわせて、サーバーのリセットを行ったり、ユーザーをサーバーから一斉退出させる調整が必要になります。また、複数のリージョンでリリースしているタイトルについては、ゲームサーバーが共通になりますので、互換を切る場合、全世界同時にバージョンアップを行う必要があります。従って、ゲームモードの変更を行う事を推奨します。

バージョンアップ時にゲームモードを変更していく運用を行った場合、ゲームモードの増加に伴いマッチメイク成功率が低下するというデメリットがあります。ユーザーが複数のゲームモードに分散してしまうことを防ぐため、過去バージョンからの認証を拒否する対応を行うことを推奨します。パッチの配信時にアカウントサーバーや認証サーバーに過去バージョンのアプリケーションからの認証を拒否する設定をいれることで、新規にゲームサーバーにログインするユーザーが最新のパッチを適用していることを保証できます。パッチが最新であることを保証する対応についての詳細はオーバービューのパッチの項目を参照してください。

 

4.3. データストア

ここではデータストア機能を使用する上での TIPS を紹介します。

 

データの保存場所を組み合わせて使用したい(ストレージサーバーとゲームサーバー)

データストア機能を使用してデータを保存する場合、ストレージサーバーに保存する方法と、ゲームサーバーに保存する方法があります。

それぞれのメリットとデメリットは以下の通りです。

  ストレージサーバー ゲームサーバー
データ 1 つあたりの容量 10 MByte 1024 byte
1 度にダウンロード、アップロードできるデータ数 1 件 100 件
データ ID 指定アップロード できない できる
処理速度 ゲームサーバーの場合と比べ時間がかかる -

この 2 つを組み合わせて使用した場合、それぞれのメリットを生かすことができます。例えば、リプレイデータの本体をストレージサーバーに格納しておき、そのサムネイルをゲームサーバーの方に格納しておくことで、サムネイルだけ先にまとめて取得し、必要なデータをストレージサーバーから取得するという使い方も可能です。

 

カウンターとしてデータストアを使用したい

データストアのデータを評価することで、ゲーム参加者共有のカウンターとして使用する事が出来ます。

例えば、あらかじめアップロードされたデータに対して、クライアントが評価を行い、評価値の合計を取得することで投票機能が実現できます。クライアントからの評価の範囲を、0 から 1 に、評価の置き換えを有効にしておくことで、クライアントあたり 1 票といった制限をかけたり、重複ロックをかけることにより、一定の期間につき 1 度だけ評価できるようにするといった仕様を実現可能です。

ゲーム全体のカウンターとして使用する場合には、誰かがデータをアップロードする必要があります。この場合、データ ID 指定アップロード機能を使用することで、決められた ID のデータがアップロードされていない場合にのみアップロードするという運用が可能になります。この場合、評価を実施してみて、データが存在しない場合にアップロードするという流れになります。

評価値に負の値を設定することも可能ですので、ゲーム参加者のグローバルな変数として自由に使用することも可能です。

ただし、評価値に対する比較演算を行うことはできないため、特定の評価値以上のデータを絞り込むような使い方はできません。

ランダムなデータを取得したい

アップロードしたデータをランダムに取得したい場合、取得するデータのオフセット値として RESULTRANGE_ANY_OFFSET を指定することで、サーバー側で疑似的にランダムに選択したデータを返却します。これにより、毎回同じデータが取得されるのを防ぐことができます。

バージョンアップで、データの互換性を切りたい

バージョンアップ前後でデータストアの互換を切りたい場合、バージョンアップ前後でデータタイプを変更し、投稿先を変更することで対応する事を推奨します。

バージョンアップ時の更新を必須とすることも可能ですが、バージョンアップ版の配信時間と、サーバーのリセット時間、ユーザーをサーバーから一斉退出させる調整が必要になります。また、複数のリージョンでリリースしているタイトルについては、ゲームサーバーが共通になりますので、互換を切る場合、全世界同時にバージョンアップを行う必要があります。可能であればデータタイプの変更を行う事を推奨します。

ネットワーク経由で疑似的なすれちがい通信を行いたい

データストアを使用して、疑似的なすれちがいを実施したい場合には、データタイプにより受信済み、未受信を管理することで、実現できます。例えば、すれちがいに使用したいデータをアップロードする際にはデータタイプを1として アップロードし、検索条件としてデータタイプが 1 の物を 1 件取得します。このデータを取得したユーザーはデータタイプを 0 にすることで、同じデータが取得されるのを防ぐことができ、また、アップロードしたユーザーは取得されたデータがどのデータであるかを後から把握することができます。

タグによりデータのカテゴリを大きく分類して検索する方法も考えられますが、「3.4. データストア」にあるように NEX のデータストアは、このように大きな検索範囲からデータを検索する用途には向いていないため、データ総数が増えた場合にサーバ負荷が上昇し、サービスの劣化に繋がる可能性がありますので、避けてください。

いつの間に通信との連携を行いたい

いつの間に通信を利用して DataStore サーバーにデータのアップロード・ダウンロードが可能です。詳細は「プログラミングマニュアル - いつの間に通信編」を参照してください。

また、NEX のライブラリを利用して DataStore サーバーにデータをアップロードしておき、受信はいつの間に通信の機能を利用するなど組み合わせての利用も可能です。