ここでは、クラウド プラットフォーム上にゲームインフラをホスティングする場合に使用する共通のコンポーネントとデザイン パターンについて説明します。
ビデオゲームの世界は大幅に進化し、盛況なエンターテイメント ビジネスに成長しています。インターネットの普及に伴い、オンライン ゲームは業界の成長に不可欠な要素となっています。
オンライン ゲームの形態は 1 つではありません。セッション型で複数のプレーヤーが対戦するものや、大量のプレーヤーが参加する仮想世界、1 人で楽しむものまで、さまざまです。
以前は、クライアント / サーバー型のゲームを実現するために、専用のサーバーを購入してオンプレミスまたは共同で配置し、メンテナンスを行う必要があり、大規模なスタジオかパブリッシャーでなければ、このようなインフラストラクチャを持つことはできませんでした。また、ハードウェアの固定費を予算内に抑えながらお客様のニーズに応えるため、綿密な予測や容量計画を行う必要がありました。現在では、クラウドベースのコンピューティング リソースを活用することで、規模の大小にかかわらず、どのゲーム デベロッパーやパブリッシャーでも、高額な初期投資を行わずに、必要なリソースを適宜利用できるようになりました。
コンポーネントの概要
次の図は、ゲーム アーキテクチャのオンライン部分を表しています。
ゲーム アーキテクチャのフロントエンド コンポーネントは次のとおりです。
- 高度なゲーム機能を提供するゲーム プラットフォーム サービス。
- ゲームをホスティングする専用ゲームサーバー。
ゲーム アーキテクチャのバックエンド コンポーネントは次のとおりです。
- システムに記録されるゲームデータ。通常、ゲーム データベースに保存されます。
- 分析データとゲームプレイ イベントを保存し、照会する分析スタック。
これらのコンポーネントは、オンプレミス、プライベート クラウド、パブリック クラウドにホスティングされます。また、フルマネージド ソリューションの場合もあります。コンポーネントとエンドユーザー間の通信要件を満たしていれば、どのシステムでも問題ありません。
フロントエンド
フロントエンドは、クライアントが直接またはロードバランサ層を介してやり取りするためのインターフェースを提供します。
たとえば、セッション型のファースト パーソン シューティング ゲームの場合、通常はフロントエンドに Open Match などのマッチメイキング サービスが含まれます。このサービスは、専用ゲームサーバー インスタンスの接続情報をゲーム クライアントに配信します。
- クライアントがマッチメイキング サービスにリクエストを送信します。
- マッチメイキング サービスは、一致条件に基づいてプレーヤーを専用ゲームサーバー インスタンスに割り当てます。
- マッチングメイキング サービスがクライアントに接続情報を送信します。
- 接続情報を受け取ったクライアントは、User Datagram Protocol(UDP)を使用して専用ゲームサーバー インスタンスに直接接続できます。
外部のクライアントだけがフロントエンド サービスを使用するわけではありません。通常、フロントエンド サービスは相互に通信を行うか、バックエンドに接続します。
フロントエンド サービスはインターネット経由で利用できるため、攻撃を受ける可能性が高くなります。サービス拒否攻撃や不正なパケットから保護するため、フロントエンド サービスを強化し、セキュリティと信頼性の問題を解決する必要があります。フロントエンド サービスと比較すると、バックエンド サービスは通常、信頼できるコードにのみアクセス可能であるため、攻撃を受けにくくなります。
ゲーム プラットフォーム サービス
このコンポーネントの一般的な名前は、「プラットフォーム サービス」または「オンライン サービス」です。プラットフォーム サービスでは、重要なメタゲーム機能とのインターフェースを提供します。たとえば、このインターフェースを利用してプレーヤーが専用ゲームサーバーのインスタンスに参加したり、ゲームのソーシャル グラフを維持したりします。これらのサービスは通常、Steam、Xbox Live、Google Play Games など、ゲームを実行するプラットフォームから提供されます。
- スコアボードと対戦履歴
- マッチメイキング
- オンライン ロビー
- チャット
- インベントリの管理
- 承認
- パーティ / グループ
- プロファイル
- ギルド
- クロスプラットフォームの認証
- フィード
- ソーシャル アイデンティティのマッピング
- 分析
- プレゼンス
ゲーム プラットフォーム サービスは、ウェブサービスと同じように進化しました。
2000 年代の初め、プラットフォーム サービスの多くはモノリシック サービスとして実行され、多くの場合はシングルトンとして実装されていました。 統合を行ったとしても、このパターンはクラウドには適していません。
現在のサービス指向アーキテクチャ(SOA)のパターンが広まったのは 2000 年代中頃で、さまざまなサービスが個別にスケーラブルな形態で提供されるようになりました。また、このサービスはゲーム クライアントやサーバーだけでなく、ウェブサービスやスマートフォンのアプリからのアクセスも可能になっています。
この 5 年ほどで、多くのウェブ企業が支持するマイクロサービス アプローチを採り入れるデベロッパーが増えています。プラットフォーム サービスとウェブ アプリケーションが抱える基本的な課題は同じです。どちらも、開発サイクルを短縮し、世界中にサービスを分散させ、実行することが求められています。マイクロサービスを利用すると、このような問題を解決できます。特に、クラウド プラットフォームでアプリケーションを設計する場合には最適な選択肢となります。
さらに、プラットフォーム サービスまたはフルマネージド プラットフォーム サービスを構築する方法として、ホスティング サービスまたはマネージド サービスが利用されるケースが増えています。
バックエンド プラットフォーム サービス
大半のプラットフォーム サービスは外部のクライアントからアクセスされますが、インターネットに公開されない内部プレーヤー ランキング サービスを提供する場合などはオンライン インフラの他の部分からのアクセスのみを許可します。このようなバックエンド プラットフォームには通常、外部ネットワークのルーティングや IP アドレスが設定されず、フロントエンド プラットフォーム サービスと同じ方法で設計されます。
Google Cloud ゲーム プラットフォーム サービスのリソース
以下のリソースでは、Google Cloud でプラットフォーム サービスを構築する方法について詳しく説明しています。
- Unity プロジェクトに Firebase サービスを追加する
- Unity 向けのクロスプラットフォーム リーダーボード
- Google Play Games サービスのセットアップ
- Open Match: オープンソース マッチメイキング フレームワーク
- App Engine のマイクロサービス間で通信を行う API の設計
専用ゲームサーバー
専用ゲームサーバーはゲームロジックを提供します。ユーザーの待ち時間を最小限に抑えるため、クライアントのゲームアプリは専用ゲームサーバーと直接通信を行います。この機能は、フロントエンド サービス アーキテクチャの一部となります。
業界でも標準的な用語はまだ確立していませんが、この記事では次のように定義します。
- 「マシン」は、ゲームサーバーのプロセスが実行される物理マシンまたは仮想マシンを意味します。
- 「ゲームサーバー」は、ゲームサーバー プロセスを意味します。1 台のマシン上で複数のゲームサーバー プロセスが同時に実行されることもあります。
- 「インスタンス」は、単独のゲームサーバー プロセスを意味します。
専用ゲームサーバーの種類
専用という言葉は、バックエンドのゲームサーバーを意味するわけではありません。もともとは、1:1 の比率で専用のハードウェア上で実行されるゲームサーバーのことを表す用語です。現在では、多くのゲーム パブリッシャーが 1 台のマシン上で同時に実行される複数のゲームサーバー プロセスを管理しています。これらのプロセスがマシン全体を占有することはまずありませんが、専用ゲームサーバーという言葉はいまでもゲーム業界でよく使われています。
専用ゲームサーバーは、実行されるゲームの種類によって異なります。以下では、ゲームサーバーのカテゴリについて簡単に説明します。
リアルタイム シミュレーション
最近まで、専用ゲームサーバーは主に、市販のリアルタイム シミュレーション ゲームのフロントエンドとして使用されていました。リアルタイム シミュレーションのゲームサーバーは垂直方向のスケーリングに課題があります。最も需要の高いゲームでは、各マシンでの複数のサーバー プロセスの実行、地理的なシャーディング、水平方向でのスケーリングが行われています。カスタムフローを制御し、信頼性が高く、混雑を回避できる UDP 通信が主にネットワークで利用されています。
大半のリアルタイム シミュレーションのゲームサーバーは、エンドレス ループとして実装されていますが、一定の時間予算内にループを終了することを目標としています。標準的な時間予算は 16 または 33 ミリ秒で、それぞれ 1 秒あたり 60 回または 30 回の状態更新を行います。この更新レートは、フレームレートまたはチックレートともいいます。サーバーは高頻度でシミュレーションを更新しますが、複数の更新を行った後で状態の更新をクライアントを送信することも珍しくありません。この方法では、必要なネットワーク帯域幅を適切な範囲に抑えることができます。更新頻度が下がることによる影響は、ラグ補償、内挿、外挿などの方式を使用することで軽減できます。
リアルタイム シミュレーションのゲームサーバーでは、レイテンシが重要な問題となり、多くのコンピューティング リソースと帯域幅を必要とするワークロードが実行されます。このため、ゲームサーバーの設計と計算パターンは慎重に検討する必要があります。Google Cloud では、Google Kubernetes Engine(GKE)などの Kubernetes クラスタでの専用ゲームサーバーの実行を簡素化するために、Agones オープンソース プロジェクトが設立されました。
セッション型または対戦型のゲーム
現在では、サーバーで個別のセッションを実行するゲームが一般的です。たとえば、Call of Duty™、Fortnite™、Titanfall™ などのファースト パーソン シューティング(FPS)ゲームや、Dota 2™ や League of Legends™ などのマルチプレーヤー オンライン バトルアリーナ(MOBA)ゲームのマルチプレーヤー セッションなどがその一例です。これらのゲームのサーバーは、ゲームプレイの展開を迅速に行い、ゲーム状態の詳細な計算を行う必要があるため、スレッドが AI または物理シミュレーションで占有されることが多くなります。
大量のプレーヤーが参加する持続型ゲーム
大規模マルチプレーヤー オンライン ゲーム(MMOG)の先駆けとなったのが約 20 年前に登場した Ultima Online™ です。World of Warcraft™ や Final Fantaxy XIV™ など、現在人気の MMO は、機能が常に進化し、複雑なサーバー デザインになっています。
MMOG サーバーではこの複雑さが常に問題となります。たとえば、サーバー インスタンス間でゲーム エンティティを受け渡し、ゲーム世界を複数の環境にシャーディングし、隣接するゲーム領域のシミュレーションを行う必要があります。何百人、何千人ものプレーヤーが参加する永続的な世界の状態更新を計算するのに必要な計算量とメモリ量は、Eve Online™の時間拡張のような解決策につながる可能性があります。
リクエスト / レスポンス型のサーバー
技術的にみると、どの専用ゲームサーバーも一連のリクエストとレスポンスをベースにしています。ただし、モバイルゲームのサーバーの場合には、リアルタイムで通信を行う必要性が低いため、ウェブ ホスティングと同様に HTTP リクエスト / レスポンスで通信を行います。
リクエスト / レスポンス型のゲームサーバーは、ウェブサービスと同じ課題を抱えています。
- ゲームサーバーのレスポンス時間をできるだけ短縮する。
- レイテンシを減少し、冗長性を追加するため、世界各地にゲームサーバーを分散させる。
- サーバー上でゲーム クライアントのアクションを検証し、攻撃や詐欺を未然に防ぐ。
- ゲームサーバーを強化して、サービス拒否攻撃などの攻撃を防ぐ。
- クライアント側の通信に指数的減衰を実装する。
- スティッキー セッションを構築するか、プロセスの状態を外部化する。
リクエスト / レスポンス型のゲームサーバーには、通信手段がコンパクトになり、アプリケーションやネットワークの障害後に簡単に再試行できる利点がありますが、このようなメリットはターン制のモバイルゲームにも有効です。このタイプのサーバーでは、App Engine や Cloud Run などのプラットフォームでサーバーレス API を使用することをおすすめします。
ゲーム状態の外部化
プレーヤーはゲームが中断しないことを期待し、その期待はますます強くなっています。このニーズに応えるには、個々のサーバー インスタンスに影響を及ぼす問題からユーザーの体験を保護しなければなりません。この課題は、プレーヤーの状態データを単一のゲームサーバー プロセス以外で管理することで解決できます。これにより、サーバー プロセスのクラッシュによる影響を最小限に抑え、効果的な負荷分散を行うこともできます。
しかし、ウェブサービスでよく利用されている状態パターンの外部化をそのまま利用することはできません。さまざまな点で問題があります。たとえば、次の点が問題になります。
- 外部の状態ファイルに更新を書き込む速度。特に、1 秒間に十数回更新を行うエンティティが数多く存在する場合は問題になります。Memcached や Redis など、メモリキャッシュのキー値ストアを使用している場合も同様です。
- 外部の状態キャッシュに対するクエリのレイテンシ。1% または 0.1% のクエリでレイテンシが発生すれば更新期限を過ぎてしまうため、状態更新の期限を守ることは難しくなります。
- 外部状態キャッシュに対するアクセス権(読み取り専用または読み取り / 書き込み)の設定。サーバーモデルが複雑になります。
しかし、これらの問題を解決することによるメリットが複数あります。状態を外部化し、適切なアクセス管理を実施して多くのプロセスにアクセスを許可すると、ゲームの状態更新の計算を並行して実行できます。また、インスタンス間のエンティティの移動も簡単になります。
Google Cloud 専用ゲームサーバーのリソース
Google Cloud で専用ゲームサーバーを実行する方法については、次の記事をご覧ください。
バックエンド
バックエンド サービスは、他のフロントエンドまたはバックエンド サービスに対してのみインターフェースを提示します。外部クライアントはバックエンド サービスと直接通信できません。バックエンド サービスはデータの保存とアクセスの手段を提供します。たとえば、データベースへのゲームの状態データの保存や、データ ウェアハウスへのロギング イベントまたは分析イベントの保存を行います。
ゲーム データベース
プレーヤーがゲームを中断し、そのまま抜けてしまう可能性があるシナリオとして、サーバー障害とプレーヤーの進捗データの消失が挙げられます。いずれの状況も、データベース レイヤの設計に問題がある場合に発生します。
ゲームの状態とプレーヤーの進行状況データを保存するデータベースは、ゲームインフラの最も重要な部分となります。
データベースの能力を評価する場合には、予想されるワークロードだけでなく、ゲームが広く普及した場合に必要になるワークロードも検討する必要があります。予想されるプレーヤー数に基づいてバックエンドを設計し、テストを行っても、負荷が急増した場合、信頼性のあるサービスの提供はできなくなります。予期しない負荷急増への対応も計画していないと、データベース問題によりゲームが利用不能になり、ユーザーが離れる結果となります。
これはゲームの弱点です。成功したサービスを提供している企業の大半は段階的な成長を想定しています。しかし、ゲームの場合、最初に大きな関心を集めるものの、その勢いは急速に衰え、ユーザー数が激減していきます。ゲームの人気が急騰すると、データベースが過負荷状態になり、進行状況データを保存する前に遅延が発生したり、保存できなくなったりします。リアルタイムでの更新を打ち切る機能を決める必要があっても、ゲーム デベロッパーが反対することもあります。データベース リソースの計画は慎重に行う必要があります。
ゲーム データベースを設計する場合には、次の点に注意が必要です。
- 十分な情報に基づいて判断する。テスト作業が楽という理由で、すべてのオプションを評価せずに開発中のデータベースを本番環境のデータベースにはしないでください。予測されるプレーヤー数がデータベースにアクセスする方法と頻度を把握し、その 10 倍を前提とします。これにより、想定するシナリオに最適なバックエンドを選択できます。データベースに対するアクセスが急増したときに対処方法を探すような状況は避けなければなりません。
- 適切な解決策は 1 つとは限らない。1 種類のデータベースしか利用してはいけない、という規則はありません。成功しているゲームの多くは、リレーショナル データベースにアカウント情報を保存してゲーム内購入を処理し、NoSQL データベースを使用してゲームの状態情報を保存しています。リレーショナル データベースではトランザクションが保証されますが、大容量で低レイテンシのワークロードの処理には NoSQL データベースのほうが適しています。
- データをバックアップする。データベースの障害から復旧できるように、バックアップを定期的に行い、地理的に離れた場所に保存する必要があります。
リレーショナル データベース
多くの開発チームは、1 つのリレーショナル データベースで開発を始めています。データとトラフィックが増加し、データベースのパフォーマンスが許容範囲に近づくと、データベースのスケーリングを検討します。スケーリングが可能でない場合、カスタムのデータベース サービス レイヤを実装します。このレイヤでクエリの優先度を設定し、結果をキャッシュに保存することで、データベースに対するアクセスを制限できます。スケーリングとデータベース サービス レイヤを追加することで、大量のプレーヤーに対応可能なゲーム バックエンドを構築できますが、これらの方法にも問題があります。
- スケーリング - 従来のリレーショナル データベースはスケールアップ(垂直方向のスケーリング)を前提としています。クラウド ネイティブのゲーム バックエンドを計画する場合には、スケールアウト(水平方向のスケーリング)を使用してください。1 つの VM のコア数には制限があります。クラウド プロジェクトに VM を追加するほうが簡単です。リレーショナル データベースでも、シャーディング、クラスタリング、階層のレプリカなどの手法で水平方向にスケーリングできますが、実行中のデータベースを停止せずにこれらを追加するのは簡単なことではありません。トラフィックやデータの量が 1 つのデータベースで処理可能な範囲内であれば、小さいクラスタから始めます。危機的な状況になってからスケーリングを検討するようなことは避けるべきです。実行中のクラスタにノードを追加することは簡単ではありませんが、不可能ではありません。
- スキーマの変更 - ライフサイクルを通じてデータベース スキーマが変わらないゲームで成功例はほとんどありません。プレーヤーは常に新しい機能とコンテンツを求めています。このような追加を行うには、新しい種類のデータをデータベースに保存しなければなりません。開発プロセスの初期の段階で、スキーマの更新方法を決めておくべきです。所定のプロセスがない状態でゲームのリリース後にスキーマを更新すると、予期しない停止時間が発生したり、プレーヤー データが消失したりする可能性があります。
- 管理 - 稼働中のリレーショナル データベースのスケーリングやスキーマの更新は複雑な操作になります。Cloud Platform では自動的に管理されるリレーショナル データベースは一般的なサービスですが、今のところ、ゲーム バックエンドでのこうした自動管理のデータベースの普及率は高くありません。これは、ゲーム バックエンドでのワークロードは書き込みが多いためです。
Google では、このような問題を軽減するうえで役立つマネージド リレーショナル データベースである Spanner を提供しています。Spanner は、スケーラブル、エンタープライズ クラスでグローバルに分散され、強整合性を備えた、クラウド向けに構築されたデータベース サービスです。リレーショナル データベース構造の利点と、非リレーショナル データベースの水平方向のスケーラビリティを兼ね備えています。多くのゲーム会社が、本番環境規模のシステムでゲームの状態と認証の両方を管理するのに Spanner が適していることを認識しています。Google Cloud コンソールを使用してノードを追加することで、パフォーマンスやストレージをスケールできます。Spanner は、強整合性によりグローバルなレプリケーションを透過的に処理できるため、リージョンのレプリカを管理する必要はありません。詳細については、ゲーム データベースとして Spanner を使用する場合のベスト プラクティスをご覧ください。
NoSQL データベース
非リレーショナル データベースは大規模な運用が可能で、特に、書き込みが多いワークロードの処理に適しています。ただし、NoSQL データモデル、アクセス パターン、トランザクションの保証について、よく理解しておく必要があります。
NoSQL データベースには多くの種類があり、ゲーム状態の保存に適しています。このデータベースの特徴は次のとおりです。
スケーリング - 水平方向のスケーリングを前提に設計されています。デフォルトで使用されていることも少なくありません。通常、データベースを停止せずにクラスタのサイズを変更できますが、追加ノードが完全に統合されるまでは、パフォーマンスが低下する場合もあります。
スキーマの変更 - スキーマは動的で、アプリケーション レイヤによって適用されます。これは大きなメリットで、新しいゲーム機能のフィールドを簡単に追加できます。
管理 - ほとんどのクラウド プロバイダでは少なくとも 1 つのホスト型またはマネージド NoSQL データ ストレージ エンジンを使用できます。Google Cloud ではこうした NoSQL データ ストレージ エンジンを複数使用できるようになっています。
Google Cloud ゲーム データベースのリソース
- Cloud SQL for MySQL の第 2 世代をモバイルゲーム バックエンド データベースとして使用する
- ゲーム データベースとして Spanner を使用する場合のベスト プラクティス
- ホット スタンバイで高可用性とレプリケーションを行えるように PostgreSQL を設定する方法
- ポケモン GO データベースのスケーリング
- Google Cloud でのモバイルゲーム オンライン アーキテクチャのベスト プラクティス
分析
現在のゲームでは、分析は重要なコンポーネントになっています。オンライン サービスとゲーム クライアントの両方が分析結果とテレメトリー イベントを共通の収集ポイントに送信します。イベントはデータベースに保存されます。この情報は、ゲームプレイのプログラマー、デザイナーだけでなく、ビジネス インテリジェンスのアナリストやカスタマー サポートの担当者も利用できます。収集する分析結果が複雑になっても、クエリを簡単に実行できるように、イベントに同じフォーマットを使用する必要があります。
この 10 年間で、Google で公開されたオープンソース フレームワークである Apache™ Hadoop® の利用者が大幅に増加しました。Hadoop エコシステムの拡大により、複雑な ETL(抽出、変換、読み込み)を実行して分析イベントをデータ ウェアハウスに挿入する一括処理が増えています。MapReduce の使用により、アクション可能な結果が配信される速度が向上した結果、より計算量の多い新しい分析が可能になりました。
一方、クラウドで利用可能な技術も進化を続けています。その多くはマネージド サービスとして提供され、専任の人員を確保しなくても、簡単に利用できます。Google の最新のストリーミング ETL のパラダイムでは、一括処理とストリーミング処理の両方に統合アプローチを採用しています。このパラダイムは、マネージド クラウド サービスとオープンソース プロジェクトの Apache Beam の両方で利用できます。クラウドデータ ストレージの料金体系も継続的に改善されています。データの書き込みと読み取りを最適な方法を行う大規模なクラウド データベースに大量のログと分析イベントを保存できるようになりました。これらのデータベースの最新のクエリエンジンは TB 単位のデータを数秒で集計します。たとえば、500 億の Wikipedia ページビューを 5 秒で分析します。
今後のために、分析の形式を決めることをおすすめします。ゲームにより、アナリティクス バックエンドに書き込まれるイベントと指標を決める場合は、分析情報のデータを引き出すための最も簡単な形式を考慮します。ETL を使用すると、アプリが分析クエリに適した形式に書き込むデータをコピーできますが、これには時間と費用がかかる場合があります。分析出力形式の設計に投資すると、費用を大幅に削減し、リアルタイムの分析情報を取得できる可能性があります。
既存の形式にバッチ処理を使用する
制御できない出力形式の指標データ(たとえば、サードパーティ統合またはサービスからのデータ)を分析する場合は、指標データを Cloud Storage に保存することから始めることをおすすめします。データ形式がサポートされている場合は、BigQuery 連携クエリを使用して BigQuery インターフェースから直接クエリできます。データ形式がサポートされていない場合は、ETL を使用して、Dataflow またはその他のツールを使用することにより Cloud Storage からデータをコピーし、生成された書式設定済みのデータを他のソースのデータとともに BigQuery に保存できます。リアルタイムでデータが緊急に必要な場合を除き、コストを節約するためにストリーミングではなく定期的なバッチジョブを設定することをおすすめします。
実績のあるモデルでチャーンと支出を予測する
Remote Config、アプリ内メッセージング、Firestore クライアント ライブラリなど、多数の Firebase 機能のいずれかをすでにモバイルゲーム用に使用しているかもしれません。Firebase には、組み込みのチャーンおよび費用の予測 ML モデルも用意されています。Remote Config のカスタマイズを統合して分析データに ML を適用し、ユーザーの予測される行動に基づいて動的ユーザー セグメントを作成できます。このデータを使用して他の Firebase 機能をトリガーしたり、BigQuery にエクスポートして柔軟性を高めたりできます。Firebase では Unity と C++ クライアントも提供しており、その使用はモバイルゲームに限定されません。
AutoML Tables カスタムモデル トレーニング用のデータの正規化
効果的な ML モデルを生成するには、通常、関連する特徴を選択し、ハイパーパラメータを調整するために、広範な ML の専門知識が必要です。ただし、データ準備のガイドラインに沿うことで、最新の自動化ツールの機能が向上し、ユーザーの代わりにこれらのタスクを実行して、有用なモデルを生成します。モデルの生成後、Google Cloud でホストして、オンライン予測やバッチ予測を行うことができます。たとえば、プレーヤーがゲーム内で購入を行うか、プレイを終了するかを予測できるようになります。
分析イベントとプレーヤー データは、従来の分析クエリとビジネス インテリジェンス指標に役立ちますが、ML モデルのトレーニングには別の形式が必要です。ゲームでの ML の一般的なユースケースは、プレーヤーが最初にゲームにお金を投じるタイミングを予測するカスタムモデルを作成することです。AutoML Tables を使用すると、トレーニング プロセスを簡素化できます。AutoML Tables の詳細については、トレーニング データの準備とトレーニング データを作成するためのベスト プラクティスをご覧ください。
複数のゲームスタジオやパブリッシャーは、日単位のロールアップ形式をトレーニングの基礎として使用することで、結果を達成してきました。日単位のロールアップは、重要な分析イベントごとに 1 つのフィールドを持つ正規化された行形式になります。この行形式には、プレーヤーがその日までにイベントをトリガーした回数の累積数が含まれます。この行には、プレーヤーがこれまでにトリガーしたすべての潜在的に重要なイベントの日単位のスナップショットと has made a purchase
フラグの true または false が表示されます。
AutoML Tables のクイックスタート ドキュメントに記載されているプロセスを使用して、この方法でフォーマットされたデータをトレーニングする際、高品質なモデルを構築できます。次に、モデルに日単位のロールアップ行を指定して、プレーヤーが購入する可能性がどの程度あるかを予測できます。また、データをフォーマットする同様の方法をさまざまなフラグとともに使用して、離脱や他のプレーヤーの振る舞いなど、さまざまな予測を行うようにモデルをトレーニングすることもできます。正規化されたデータ形式の構築に事前に投資することで、必要なプレーヤーのアクションを予測するモデルをすばやく試すことができます。このモデリングは、ゲームの収益化や、望ましいプレーヤーの結果をもたらす機能の優先順位付けに役立つ可能性があります。
Google Cloud のゲーム分析ソリューション
- Google Cloud とスクエア エニックスによりデータの価値を引き出す(GDC 2019)
- King BigQuery と ML のユースケース
- LINE GAMES BigQuery のユースケース
- Firebase 向け Google アナリティクス データを BigQuery にインポート
次のステップ
オンライン ゲームのソリューションには共通のパターンがあります。クライアントがサービスのフロントエンドとゲームサーバーに接続し、これらのコンポーネントがバックエンドに接続して分析や状態の保存を行います。これらのコンポーネントは、オンプレミス、クラウド、あるいはその両方で実行できます。パターンの詳細については、ゲーム ソリューションをご覧ください。
- Google Cloud に関するリファレンス アーキテクチャ、図、ベスト プラクティスを確認する。Cloud アーキテクチャ センターをご覧ください。