ランキングのリファレンス アーキテクチャ
これらのリファレンス アーキテクチャでは、ランキングのユース ケースと、さまざまな選択肢を使用した実装について説明し、自分のゲームのデザインにぴったり合った完全な制御とカスタマイズが可能な独自のクラウド ソリューションを構築できるようにします。
ヒント
すぐに使えるランキング ソリューションを探している場合、PlayFab は、ランキングのサポートがあるクラウド接続ゲームを構築、ローンチ、拡大するための完全なバックエンド プラットフォームです。
ランキングのデザイン
ランキングを定義する際には、考慮できる変数が多数あります。 考慮する変数のいくつかの例を以下に示します。
- 地域: プレイヤーがいる物理的な場所。 国から地域、大陸、さらに広範囲まで、必要に応じた細かさで設定できます。 例: フランス、中国、米国、北アメリカ、アジア、EMEA。
- プラットフォーム: ゲームがプレイされるデバイスまたはサービス。 複数のプラットフォームを組み合わせたランキングを有効にすることも検討できます。 例: Xbox、PlayStation、PC、iOS、Android、モバイル、コンソール。
- モード: ゲームプレイを変化させ、他のゲームの仕組みの動作に影響を与える独特の構成。 例: ソロ、デュオ、スクワッド、PvE、PvP、キャンペーン。
- 難易度: ユーザーが選択した難しさ。 例: 易しい、普通、難しい。
- オプション: プレイヤーが選択した個別のオプション。 例: キャラクター (人間、車両)、アイテム (武器、ツール)、設定 (手動または自動シフト)。
- レベル: ゲーム内のレベルやステージ。 例: レベル 2-1、トラック 3。
- 統計: 使用またはアクションに基づいてプレイヤーが生み出す個別の値。 例: スコア、勝ち数、負け数、集めたコイン数。
プレイヤー認証と ID
このリファレンス アーキテクチャでは、プレイヤー認証とプレイヤー ID は扱いません。 これらについては各自で調べてみてください。
PlayFab には複数の認証形式が用意されているため、複数のデバイスにわたってプレイヤーを追跡できます。
- ゲスト ログイン用のデバイス ID
- ユーザー名/パスワード
- Google アカウント
- GameCenter アカウント
- Facebook アカウント
- Steam アカウント
- Kongregate アカウント
- Twitch アカウント
- その他の oAuth プロバイダー
- Android デバイス ID
- カスタム プレイヤー ID
サイズと複雑さ
ランキングは、スコアに基づいてプレイヤーをランク付けする非常に単純なシステムから、複数の統計、オプション、レベル、プラットフォームなどを組み合わせて追跡する大規模で複雑なものまで多岐にわたります。 たとえば、変数プラットフォーム、地域、モード、レベル、統計を組み合わせたランキングについて考えてみましょう。 これにより、"フランス (地域) で、Xbox One (プラットフォーム) をモード プレイヤー対プレイヤー (モード) のレベル 3 (レベル) に使用しているプレイヤーのスコア (統計)" のような値を使用したゲーム シナリオでプレイヤーをランク付けできます。 このデータを追跡している状態で地域フィルターを除外すると、住んでいる場所に関係なくすべてのプレイヤーをランク付けできます。
別の例として、変数システム、レベル、統計を組み合わせた場合について考えてみましょう。 これにより、"PC (システム) 上で対戦するプレイヤーが、トラック ニュルブルクリンク (レベル) を完了するのにかかった時間" のようなレーシング ゲーム シナリオでプレイヤーをランク付けできます。
もちろん、個々のゲームには、プレイヤー同士をランク付けするためのさらに多くの方法がある可能性があります。 ここで説明するサンプル実装は出発点であり、上に示した変数のごく一部だけを使用します。 このユース ケースでは、プレイヤーのスコアは 2 つの変数、プラットフォームとレベルに基づいてランク付けされます。 それぞれのプラットフォームのプレイヤーが、それぞれのレベルで最高スコアを競い合います。 ここから始めて自由に構築し、ゲームのニーズに合わせて変更してください。
データの更新
古いデータが含まれているランキングは、ランキングがまったくないのと同じくらい役に立ちません。 ただし、コスト上の理由から、頻繁なデータ更新を避けたほうがよい場合もあります。 ランキングの更新と再計算を行う間隔を、毎分から毎時間までの範囲内で設定してみてください。 場合によっては、1 日に 1 回の更新でも意味があります。 しかし、ランキング データをほぼリアルタイムで更新する必要がある場合は、このリファレンス アーキテクチャで対応できます。
ランクの近いプレイヤー
ランキング上でユーザーの位置を示して、プレイヤーが自分の上下にいる人を確認できるようにし、もっと上に行ける可能性を示すことがベスト プラクティスです。 ゲームでトップ ランク プレイヤーのみを表示してプレイヤーの意欲をそぐのではなく、ランキングのもっと上に簡単に行けることを見せることで、プレイヤーの熱意を高めることができます。
不正行為対策
一部のプレイヤーが偽のスコアをランキングに挿入しようとすることは避けられませんが、コミュニティに悪影響を及ぼします。 不正行為を難しくするために実行できる対処方法がいくつかあります。
- パケット スニッフィングを防ぐために、クライアントとクラウド間の通信を暗号化します。
- テレメトリを追加してサーバー側で使用して、スコアが理にかなっているかどうかを (できれば自動的に) 確認し、不正なスコアをその場で検出できるようにします。 簡単なチェックとして、次の 2 点があります。
- プレイヤーは現実的にその時間内でレベルを完了できるか?
- プレイヤーはどのくらいの頻度でスコアを送信しているか?
- 不正なスコアは破棄しないでください。 代わりに、スコアと、そのスコアを送信したプレイヤーの両方を疑いありとしてマークします (誤って正当なユーザーに影響を与える可能性があるので、慎重に行ってください)。その後、既知の正当なユーザーがランキングにアクセスするときは、不正行為の可能性ありとしてマークされていないスコアのみを取得します。 不正行為者がランキング表示の要求を送信したときは、不正なスコアのみを取得します。 その目的は、偽のスコアの挿入がうまくいかなかったことを不正行為者に直接フィードバックせず、成功したと思わせることです。
参照実装の詳細
ランキング情報を格納するデータベースの選択に関して最初に決定すべき点の 1 つは、リレーショナルと非リレーショナル (NoSQL) データ構造のどちらを使用するかということです。 注意すべき違いがいくつかあります。
| リレーショナル | 非リレーショナル | |
|---|---|---|
| 準備 | データの構造/スキーマは事前に決定しておく必要があり、後からの変更は破壊的になる可能性があります | 最小限の構造が必要 |
| 厳格さ | すべてのデータが同じ構造を使用する必要があります | 各データ エントリが独自の構造を持つことができ、新しいフィールドを後から簡単に追加できる |
| プライマリ ストレージ モデル | テーブル ベース | ドキュメント ストア、グラフ データベース、キー/値ストア、またはワイド列ストア |
| スケーラビリティ | 垂直方向の拡張が可能 - サーバー、CPU、RAM、またはストレージの増加 | 水平方向の拡張が可能 - シャーディングまたはサーバーの追加 |
さまざまなストレージ モデルの詳細については、「適切なデータ ストアの選択」ドキュメントを参照してください。
最後になりますが、どちらかの選択肢に関する個人的な専門知識も考慮する必要があります。 よく知っている方法を選択することで、まったく新しい一連の未知の問題に対処する必要がなくなり、新しいベスト プラクティスと概念を習得するのにかかる時間を節約できます。
以下は、入門用の単純なランキングのユース ケースの 2 つの異なる実装です。
- 非リレーショナル (NoSQL): 小規模向けには Azure Cache for Redis、大規模向けには Azure Cosmos DB を使用します。
- リレーショナル: 小規模向けには Azure SQL Database または MySQL、大規模向けには Azure SQL Database を使用します。