Gaming

AI を活用した「生きたゲーム」への移行: 遊び方をレベルアップさせるお客様とパートナーをご紹介

Thu, 04 Sep 2025 01:15:00 +0000

※この投稿は米国時間 2025 年 8 月 18 日に、Google Cloud blog に投稿されたものの抄訳です。

ゲーム業界は、イノベーションとプレーヤーエクスペリエンスへの注力を原動力に、力強く前進しています。長年にわたり、業界の進化は、おなじみの IP のグラフィックとゲームプレイが向上することによって定義されてきました。Google Cloud は、カートリッジから CD-ROM への移行や、2D グラフィックから 3D グラフィックへの移行に匹敵する、はるかに大きな変化が目前に迫っていると考えています。この新しい時代は、「生きたゲーム」の台頭によって定義されます。これは、AI を活用したダイナミックで常に進化する新しい形式のゲームで、プレーヤーを何年も魅了するでしょう。

2024 年のゲームの世界市場は 1,800 億ドルを突破しており、ゲームの開発、プレイ、体験方法の根本的な変化は、業界にとってまったく新しい機会を生み出しています。この変化を推進する大きな要因は、クラウドコンピューティングと AI の変革力です。最先端のデベロッパーやスタートアップの多くは、すでにこれらの進歩を活用しています。

クラウドプラットフォームは現在、ゲーム業界の129 億ドル規模のエコシステムの中核を担っており、AI の導入が成長の主要な推進力として浮上しています。実際、Google Cloud が The Harris Poll に委託して実施した新しい調査では、AI がどれほど深く統合されているかが明らかになっています。ゲームデベロッパーの 97% が、AI がゲーム業界を再構築していることに同意しています。すでに、この進化するテクノロジーは、ゲームの制作方法やプレーヤーの期待を根本的に変えるものとして認識されています。この新しいテクノロジーにより、数週間かかっていたライブオペレーションのサイクルが、AI による瞬時のフィードバックループに変わり、真に生きているようなゲームの世界が生まれます。

「生きたゲーム」というビジョンは、もはや遠い夢ではなく、今日実現しつつあります。Google Cloud は、Google の豊富なライブサービスに関する専門知識と、最先端のクラウドおよび生成 AI テクノロジーを組み合わせることで、この取り組みを推進しています。

このようなイノベーションが、Atlas、Embody、Ludeo、Nacon、Nitrado など、ゲーム業界の素晴らしいお客様やパートナーとの新たなコラボレーションや拡大されたコラボレーションを推進しています。これらの先駆者たちは、より没入感のあるプレーヤーエクスペリエンスの創出から、ゲーム開発の加速、運用のスケーリングまで、ゲームの可能性の限界を押し広げています。

Atlas: 広大な 3D ゲームの世界を創造する AI

Atlas は、プロのゲームスタジオ向けに設計されたエージェント型の 3D コンテンツ作成プラットフォームで、ゲーム対応のアセット、環境、ツール、ワークフローを生成できます。1 回限りのアセット生成ではなく、本番環境規模のワークフローに焦点を当て、マルチエージェント AI システムを通じてクリエイティブアシスタントとして機能します。開発者は、自然言語プロンプトを使用してインテリジェントな AI エージェントと共同で作成し、出力が特定の技術的および美的目標に合わせて調整されるようにします。Atlas は、Unreal Engine、Unity、Houdini などの業界標準のパイプラインと統合されているため、複雑なゲームを大規模に構築する AA+ チームに最適です。

Atlas の最高経営責任者である Ben James 氏は次のように述べています。「AI ネイティブゲームは、インタラクティブエンターテイメントの次の章を定義するものになると考えています。「これらのエクスペリエンスは、動的でパーソナライズされ、常に進化し続けるものであり、新しいクリエイティブインフラストラクチャが必要になります。Google Cloud との提携により、そのビジョンを実現するためのコンピューティング基盤とオーケストレーションサポートが得られます。」

Atlas は Google Cloud と連携して、マルチエージェント AI インフラストラクチャを強化し、AI ネイティブゲームの開発を加速させています。このプラットフォームは完全に Google Cloud のインフラストラクチャ上に構築されており、Vertex AI などのモデルオーケストレーションツールを使用しています。これにより、Atlas はそのビジョンを実現するために必要な堅牢なコンピューティング基盤とオーケストレーションサポートを得て、ダイナミックで進化するインタラクティブエンターテイメントの新時代を切り開きます。

「Atlas は、高度にカスタマイズされた当社のワークフローとシームレスに統合できるため、大変革をもたらしています」と、スクウェア・エニックスのイノベーションテクノロジー部門のテクニカルディレクターである Joseph Burnette 氏は述べています。「パイプラインのニュアンスを深く理解していただいており、高品質でパフォーマンスが最適化されたソリューションを驚くほどの俊敏性で提供できる貴重なパートナーとなりました。」

Embody: 臨場感あふれるパーソナライズされた空間オーディオ

Embody は、Immerse AI Engine を通じてゲーム、音楽、XR エクスペリエンスのサウンドに革命を起こしている AI テクノロジー企業です。このエンジンは、機械学習、3D ニューラルネットワーク、コンピュータビジョンを使用して、あらゆるヘッドフォンでパーソナライズされた空間オーディオを実現します。Embody は、プレーヤーの頭と耳をスマートフォンで短時間撮影した動画を分析するだけで、超リアルで没入感の高い体験を実現する独自のサウンドプロファイルを作成します。AI ネイティブのヘッドトラッキングとアダプティブ EQ により、オーディオがさらに強化され、すべてのデバイスで一貫した最高水準のサウンド体験が実現します。

Embody は、こうした複雑なリアルタイム計算を可能にし、数百万人のゲーマーに対応するために、Google Cloud のインフラストラクチャを利用しています。費用対効果の高い大規模な GPU コンピューティング能力は、パーソナライズされたオーディオプロファイルを数秒で生成し、空間音響の継続的なイノベーションを実現するために不可欠です。また、Google とのコラボレーションにより、Embody の研究開発チームは新しいアイデアを迅速にプロトタイピングし、その技術が経済的に実現可能で、グローバルにスケーリングできることを確認できます。Embody の Immerse はすでに、『Call of Duty: Black Ops 6』、『War Zone』、『ファイナルファンタジー XIV』、『サイバーパンク 2077』、『ウィッチャー 3 ワイルドハント』などの AAA タイトルを強化しており、『Sea of Thieves』との提携も発表されたばかりです。

Embody の最高経営責任者である Kapil Jain 氏は次のように述べています。「サウンドはあらゆるゲームの感情的な核であり、パーソナライズされるべきだと考えています。「Google Cloud を使用することで、AI を活用したサウンドパーソナライズエンジンをスケールアップし、世界中の数百万人のゲーマーの需要に対応しています。」

Ludeo: プレイ可能なハイライトを通じたゲームの発見

Ludeo は世界初のプレイ可能なメディアプラットフォームで、ユーザーはゲームのハイライトクリップをすぐに再生できます。ゲームプレイの体験を一方的な動画にする、現在一般的なゲームプレイコンテンツとは異なり、Ludeo はスタジオやパブリッシャーと直接連携して、ユーザーがすぐに参加して体験できる「プレイ可能なハイライト」である Ludeo を作成します。ゲームを所有しているかどうかに関係なく、ダウンロードや長いインストールは不要です。

Ludeo の瞬間は、ソーシャルメディアプラットフォームからメッセージアプリまで、あらゆる場所でリンクを共有できます。受動的な視聴者が、あっという間に積極的な参加者になります。これにより、ゲームスタジオは新しいプレーヤーを引き付け、新しいコンテンツを紹介して既存のプレーヤーを再エンゲージメントできます。また、プレーヤーはゲーム内アイテムを「購入前に試す」ことができるため、関心とコンバージョンが向上します。

このビジョンを実現するために、Ludeo は Google Cloud を使用してコアインフラストラクチャを強化しGoogle Kubernetes Engine（GKE）と GPU を使用して、プラットフォームに必要な、高度に最適化された低レイテンシのインフラストラクチャを構築しました。Ludeo は「プレイ可能な YouTube」の構築も目指しており、人気 AAA タイトルから AA、インディーまで、プレーヤーがゲームを発見し、ソーシャルにゲームに参加する方法を根本的に変えることを目指しています。

「Google Cloud のインフラストラクチャは、Ludeo プラットフォームの機能と規模を強化します」と、Ludeo のビジネス開発およびパートナーシップ担当バイスプレジデントである Uri Levanon 氏は述べています。「この強力な組み合わせにより、ゲームスタジオに新たな成長の機会がもたらされるだけでなく、プレーヤーはゲームのハイライトをただ見るだけでなく、すぐにプレイできるという魔法のような体験を得られます。」

NACON: AI による変革でゲーム制作を加速

NACON は、AA ビデオゲーム会社として著名であり、ハイエンドゲームハードウェアのリーダーでもあります。RoboCop: Rogue City、Ravenswatch、Test Drive Unlimited Solar Crown などの人気タイトルで知られています。15 のゲームスタジオを傘下に持つ NACON は、ゲーム開発からマーケティングまでの業務で、AI を中核に組み込むという大胆な戦略的ピボットを行っています。

NACON の目標は、年間のゲームリリース数を増やすことです。そのためには、AI を活用してプロセスを合理化し、創造性を高めることが不可欠です。このビジョンには、魅力的なトレーラーやゲーム内シネマティクスの制作から、レーシングタイトルのゲームマップの最適化まで、すべてが含まれており、プレイヤーエクスペリエンスとデベロッパーの効率性を高めるように設計されています。

Google Cloud は、NACON の AI 主導の変革におけるパートナーとして、NACON がイノベーションを加速し、忘れられないゲームエクスペリエンスを提供できるよう支援しています。NACON は、ゲームサーバーの優先パートナーとして Google Cloud を選択し、多様なポートフォリオに対応するスケーラブルで信頼性の高いインフラストラクチャを確保しています。また、映画のような予告編の制作を支援する補完的なツールとして Google の Veo 3 モデルを使用し、ローカライズ作業をサポートする Google の Gemini モデルを使用することで、NACON はより効率的に新しいグローバル市場に参入できるようになりました。さらに、NACON は Looker を使用してゲーム内分析とプレーヤーの行動に関する詳細な分析情報を取得し、Google Threat Intelligence を使用して業界の脅威に対する運用をプロアクティブに保護する能力を強化する予定です。

NACON の社長兼最高経営責任者である Alain Falc 氏は次のように述べています。「Google Cloud との提携は、AI を中心としたゲーム開発の変革を目指す NACON の取り組みにおいて、重要な転換点となります。「Google Cloud の最先端のツールにより、チームはイノベーションを加速し、制作を合理化して、世界中のゲーマーに豊かで没入感のあるエクスペリエンスを提供できます。」

Nitrado: 完璧なマルチプレーヤー型ゲームのためのハイブリッドクラウドスケーリング

ゲームサーバーホスティングのグローバルリーダーである Nitrado は、オーケストレーションソリューション GameFabric の新機能により、スタジオがマルチプレーヤー型ゲームをさらに簡単に作成できるようにしています。このプラットフォームは統合されたオーケストレーションレイヤとして機能し、ゲームデベロッパーは Nitrado の高パフォーマンスのベアメタルインフラストラクチャとクラウドの弾力性をシームレスに組み合わせることができます。これらはすべて GameFabric を通じて管理されます。

つまり、スタジオは Google Cloud を自動的に使用して、大規模なゲームのリリース時や週末の繁忙期など、トラフィックの急増に対応できます。さらに、スタジオは Google の地球規模のネットワークを使用して、新しいリージョンにサーバーを即座にデプロイすることで、ゲームをプレーヤーに近づけることができます。これにより、世界中のユーザーに低レイテンシのパフォーマンスを確保できます。GameFabric は自動的にスケールアップまたはスケールダウンできるため、開発者はインフラストラクチャではなくプレーヤーエクスペリエンスに集中できます。また、スタジオは、オンラインプレーヤーの数や場所に関係なく、ゲームをスムーズかつ費用対効果の高い方法で実行できます。

GameFabric の優先クラウドプロバイダとして Google Cloud を採用することで、スタジオは Google Cloud の低レイテンシのグローバルネットワークを利用して完璧なプレーヤーエクスペリエンスを実現し、無制限のスケーラビリティを実現する弾力的なインフラストラクチャを利用できます。このパートナーシップは、ゲームサーバーを効率的かつ確実に管理できる信頼性の高い GKE や Agones などの運用ツールを基盤としています。さらに、Google Cloud の組み込みのセキュリティと信頼性により、ゲームとプレーヤーのデータが 24 時間保護されます。

「GameFabric は、ベアメタルとクラウドを統合されたオーケストレーションレイヤにまとめるため、スタジオはスケールアップし、高速を維持し、費用を予測可能に保つことができます」と、Nitrado の最高経営責任者である Raphael Stange 氏は述べています。「このパートナーシップにより、マルチプレーヤー型ゲームのスタジオのニーズに応えるために構築したハイブリッドモデルが強化されます。」

「生きたゲーム」の世界を体験

「生きたゲーム」の未来は単なるコンセプトではなく、クラウドと AI のダイナミックな組み合わせによって今まさに構築されています。Google は、あらゆる規模のゲームデベロッパーやスタジオの基盤となるパートナーとして、真にダイナミックで没入感のある、成功するゲームを世界中のプレーヤーに提供するために必要なスケーラブルなインフラストラクチャ、強力な AI ツール、深い専門知識を提供することに取り組んでいます。お客様とパートナー様が創造性とテクノロジーの限界を押し広げ続けることで、どのような新しいエクスペリエンスが生まれるのか、今から楽しみです。

Google Cloud for Games を使用して、AI を活用した POC を構築してみるには、 cloud.google.com/solutions/gamesをご覧ください。

-Google Cloud、ゲーム担当グローバルディレクター Jack Buser

生成 AI とクラウドゲームでマルチプレーヤーゲームを強化: 技術解説

Mon, 24 Mar 2025 02:00:00 +0000

※この投稿は米国時間 2025 年 3 月 18 日に、Google Cloud blog に投稿されたものの抄訳です。

生成 AI は、ゲーム業界に革命をもたらそうとしています。パーソナライズされた NPC、動的なストーリー生成、カスタマイズされた環境の提供を可能にし、多くのゲームではすでにそれらを実現していることで、プレーヤーエクスペリエンスを再構築しています。これは、「生きたゲーム」として知られるようになったコンセプトです。

最近発表された、Google DeepMind による Genie 2: 大規模な基盤世界モデルは、この可能性を示す好例です。Kubernetes、Agones、Open Match を基盤とし、生成 AI と統合された生きたクラウドゲームは、パフォーマンスやゲームの楽しさを犠牲にすることなく、こうした進歩を幅広いゲームプレーヤーに提供できます。

このブログ投稿では、Google の Gemini やオープンモデル（Gemma など）といった最先端の生成 AI モデルを、Google Kubernetes Engine（GKE）と Agones を活用したスケーラブルなマルチプレーヤーゲームサーバーに統合する方法について説明します。また、生成 AI でサンプルゲームを強化する方法も紹介します。これにより、デベロッパーはスケーラビリティと信頼性を維持しながら、ゲームプレーヤーへのインタラクティブなガイダンス、リアルタイムチャット機能、ゲームプレーヤーの進捗状況のパーソナライズされた要約など、AI を活用した機能でゲームを充実させることができます。

Agones によるクラウドゲーム: スケーラブルなマルチプレーヤーゲーム体験の基盤

Agones は、デベロッパーが多数の専用ゲームサーバーを効率的に管理できるようにする、Kubernetes ベースのオープンソースゲームサーバーホスティングソリューションです。あらゆる Kubernetes Deployment で動作しますが、GKE 上で実行することで Google Cloud のお客様は公式サポートを受けることができます。

Agones は、Open Match とも統合されています。Open Match は、スキルレベルや場所などのプレーヤーの条件に基づいてマルチプレーヤー対戦を簡単に作成できる、オープンソースのマッチメイキングフレームワークです。

Agones と Open Match の組み合わせは、スケーラブルなクラウドゲームの強力な基盤となります。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud を無料で試す'), ('body', <wagtail.rich_text.RichText object at 0x7fa3a7961730>), ('btn_text', '無料で開始'), ('href', 'https://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', None)])]>

クラウドゲームにおける生成 AI の可能性

生成 AI をリアルタイムで活用することで、従来のライブサービスを超越した生きたゲームの実現が可能になり、デベロッパーが継続的に関与しなくても、ゲームプレーヤーはダイナミックで魅力的な体験をすることができます。生きたゲームは、動的なストーリー展開、NPC とのレスポンシブなインタラクション、パーソナライズされたゲーム内コンテンツなどの特徴によって、プレーヤーとゲームの世界との深いつながりを育み、プレイのたびにユニークな体験を提供できます。

生成 AI を使用した言語学習ゲームの開発: 技術チュートリアル

Agones と生成 AI とのインテグレーションの簡単な例を紹介するために、Lexitrail という言語学習ゲームを作成しました。Lexitrail は、インタラクティブな方法で漢字を覚えられるだけでなく、マルチプレーヤーモードで他のプレーヤーと競い合うこともできます。

Lexitrail では、React フロントエンド、Python Flask バックエンド、MySQL データベースを使用しています。これらはすべて、Google Kubernetes Engine（GKE）のクラスタ内にデプロイされています。ゲームセッション管理レイヤが重要なコンポーネントとなり、ゲームセッションをシームレスに処理するために Agones ゲームサーバーとしてデプロイされます。

Lexitrail では、Gemini モデルと Imagen モデルの力を活用しています。これらのモデルは、プレーヤーが単語を記憶したり想起したりするのを助ける、巧妙かつ曖昧なヒント画像を生成します。また、ゲームをさらにパーソナライズするために、LLM プロンプトに加えて、プレーヤー固有のコンテキストを追加します。

Lexitrail アーキテクチャの概要

次の図は、Lexitrail システムの基盤となる基本的なアーキテクチャとコンポーネントを示しています。

このアーキテクチャは、ゲームの楽しさを向上させる次の主要機能を提供できるように設計されています。

シームレスなゲームセッション: ゲームセッションの管理に Agones を利用することで、シングルプレーヤーモードとマルチプレーヤーモードのどちらでも迅速に状態を切り替えることでき、プレイが中断されなくなります。
生成 AI のインテグレーション: 生成 AI インテグレーションレイヤの適応性により、デベロッパーは、クローズドモデル（Gemini、Imagen など）とオープンモデル（Llama、Stable Diffusion、Gemma など）の両方に対応するエンドポイントを作成できます。これらのエンドポイントをゲームアプリケーションの他のコンポーネントと統合することで、個々のゲームの要件に合わせて特別に調整された、詳細で示唆に富んだヒント画像を作成できます。
スキルベースのマッチメイキング: マルチプレーヤー環境では、Open Match がプレーヤーのスキルレベルに基づいて対戦相手を決定し、バランス良く楽しくプレイできる対戦ペアを作成します。
スケーラビリティと信頼性: このアーキテクチャの基盤は GKE であり、ゲームサーバーの管理と自動スケーリングに必要な Kubernetes インフラストラクチャを提供します。GKE で Agones と Open Match を実行することで、小規模な学習グループから大規模なトーナメントまで、世界中のプレーヤーに簡単に対応できます。

スムーズでスケーラブルなマルチプレーヤーゲーム体験を実現するために設計された、Lexitrail ゲームアプリケーションのアーキテクチャを詳しく見ていきましょう。

Lexitrail フロントエンド: プレーヤーに最初に表示されるインターフェースであり、Google ログインによる認証を管理します。ユーザーインターフェースコンポーネントと、そのインタラクションを管理するビジネスロジックの両方が、フロントエンド内で管理されます。さまざまなゲームモードが用意されており、プレーヤーはソロモードで練習したり、マルチプレーヤーモードで他のプレーヤーと対戦したりできます。また、異なる HSK（漢語水平考試）レベルに基づく単語セットをゲームモードごとに選択することもできます。プレーヤーがマルチプレーヤーモードを選択すると、ゲームのフロントエンドによってマッチメイキングプロセスがトリガーされます。このプロセスでは、Open Match コンポーネントにマッチメイキングリクエストが送信されます。
Open Match: Lexitrail では、マッチメイキングシステム用の GKE サービスとしてデプロイされる Open Match を使用しています。現在の設定は単純で、同じ単語セットを選択したプレーヤーがペアになります。ただし、Open Match の柔軟性により、デベロッパーはゲーム固有の要件に合わせて、より複雑なマッチメイキングアルゴリズムを実装できます。対戦が決定すると、Open Match はゲームサーバーのオーケストレーションシステムと連携して、その対戦専用のゲームサーバーを指定します。ゲームの状態がメモリ内シミュレーションであることから、各クライアントが直接接続する必要のあるアドレスとポートはマッチメーカーにより（フロントエンドを介して）ゲームクライアントに返され、その後、Lexitrail がプレイされます。
ゲームサーバー: Lexitrail では、ペアになったプレーヤーのゲームセッションをゲームサーバーが管理します。ゲームプレイのロジックを監視し、中間的な単語想起の結果を追跡し、最終的なスコアボードを維持します。さらに、ゲームサーバーはバッファレイヤとして機能することでパフォーマンスを向上させます。データベースの更新といった時間のかかるタスクをバッチ処理し、非同期的にバックエンドにフラッシュすることで、これらのオペレーションがフロントエンドの応答性に悪影響を及ぼさないようにします。
Agones: Lexitrail ではゲームサーバーのオーケストレーションに Agones を使用しており、そのアロケータサービスを活用して、マッチごとに専用のゲームサーバーを割り当てるマッチメーカーのリクエストを容易にしています。Agones は、これらのゲームサーバーの可用性を確保し、ゲームプレイ中にプレーヤー操作が中断されないように管理しています。さらに、Lexitrail では Agones のフリートオートスケーラーを利用して、需要に応じてゲームサーバーの数を動的に調整します。
ゲームバックエンド: GKE サービスとしてデプロイされた Lexitrail のゲームバックエンドは、API インターフェースとデータベースの操作に関するビジネスロジックを管理します。フロントエンドとゲームサーバーの両方からのリクエストを処理し、単語セット、単語、想起履歴などのプレーヤーデータを取得し、更新します。さらに、バックエンドは生成 AI エンドポイントと統合され、プレーヤーが単語を記憶したり想起したりするのを助けるヒントのテキストや画像を生成します。
データベース: Lexitrail のバックエンドデータベースは MySQL を基盤とし、GKE 環境内にデプロイされます。このデータベースには、ユーザープロファイル、単語セット、個々の単語のエントリ、プレーヤーの想起履歴など、ゲームに不可欠なすべてのデータが格納されます。データベーススキーマはこちらで確認できます。
生成 AI のインテグレーション: ゲームのユーザーインターフェースには、ゲームプレイ中に記憶すべき単語が表示され、想起を助ける視覚的なヒントも示されます。これらのヒント画像は、GKE 環境内にデプロイされた生成 AI エンドポイントと統合することで生成されます。ゲームのバックエンドは、画像生成モデルのエンドポイントにクエリを送信して、各単語のヒント画像を作成します。Kubernetes ベースの柔軟なアーキテクチャは、デベロッパーが基盤となるさまざまな LLM を簡単に選択して画像生成に利用することを可能にしています。

次のステップ

ゲームにおける生成 AI の可能性は計り知れず、ツールもかつてないほど利用しやすくなっています。まずは、こちらのリポジトリをご参照ください。

生成 AI の統合を試す: Agones と GKE を使用して、生成 AI モデルを独自のアプリケーションに統合してみましょう。
Vertex AI と GKE のモデルを活用する: Vertex AI または GKE のオープンモデルのインテグレーションを試して比較してみましょう。AI がゲーム体験をどのように変革するかを確認できます。
コミュニティに参加する: Agones、Open Match、広範な GKE AI プロジェクトのデベロッパーコミュニティに参加して、インサイトを共有し、他社から学び、AI を活用したゲームの未来をともに築きましょう。

スケーラブルな AI 駆動型の機能を取り入れ、ゲームテクノロジーの最先端を走り続けましょう。こうした機能は、プレーヤーに新たなレベルのパーソナライズとエンゲージメントをもたらし、生きたゲームを現実のものにします。

Kubernetes と GKE に Agones と Open Match を組み合わせれば、最先端のコンポーネントを活用するクラウドゲーム向けに、スケーラブルで運用実績のあるエンタープライズグレードのソリューションを提供できます。スケーラブルかつ AI を活用したゲームの取り組みは始まったばかりです。皆様が構築されるソリューションを楽しみにしております。

-シニアソフトウェアエンジニア Max Gong
-シニアエンジニアリングマネージャー Alex Bulankou

Co-op モード: AI でゲームの未来を推進する新たなパートナー

Mon, 24 Mar 2025 01:00:00 +0000

※この投稿は米国時間 2025 年 3 月 18 日に、Google Cloud blog に投稿されたものの抄訳です。

ゲーム業界のリーダーは、Google Cloud の AI を活用してよりスマートかつ高速な、没入感のあるゲームエクスペリエンスを提供するなど、ゲーム開発における前例のない進化を遂げています。ゲームスタジオの成功には多様性に富んだ大規模なチームワークが不可欠です。Google Cloud のパートナーエコシステムは、ゲーム業界専用の AI ツールなどを提供することで、あらゆるプロジェクトのレベルアップを支援します。この連携により、エンジニアリングの労力を最小限に抑え、制作の効率を最大限に高め、ゲーム企業のビジネスの成長を支援できます。

Google Cloud は、今年の Games Developers Conference で、nunu.ai、ElevenLabs、Common Sense Machines との新たなパートナーシップを発表します。これらの革新的なスタートアップは、Vertex AI、Google Kubernetes Engine（GKE）、Agentspace などの Google Cloud の AI プラットフォームを活用して創造性を高め、ワークフローを自動化し、プレーヤーの没入感を高めています。

nunu.ai: AI エージェントによるゲームテストの改善

従来、時間と費用のかかる作業であったゲームのテストと品質保証が、AI によって変革されつつあります。Google Cloud は nunu.ai と提携し、AI を活用した革新的なゲームテストソリューションを世界中のデベロッパーに提供しています。ゲームの複雑化が進むなか、nunu.ai のマルチモーダル AI エージェントが、ゲームのテストの実施方法を変革しています。このエージェントは、Gemini モデルを活用し、Google Cloud インフラストラクチャ上で実行されます。

nunu.ai のエージェントは人間のプレーヤーと同じようにゲーム環境をナビゲートし、従来のテストでは見逃される可能性のあるバグを見つけ出します。これらの AI エージェントは、レンダリングされたフレームを通してゲームを観察し、キーボードとマウスによる入力を使用して操作することで、人間によるものと同じテスト環境を提供します。

Google Cloud と nunu.ai のパートナーシップにより、次のようなメリットがもたらされます。

人間が実施するようなテスト: AI エージェントは人間と同じようにゲームをプレイし、他のテストソリューションでは見逃されるバグも見つけ出します。
コスト効率: nunu.ai を導入したゲームスタジオは、反復的なテストタスクを自動化することで、手動による品質保証にかかる費用を最大 50% 削減しました。
24 時間 365 日フル稼働: 人間のテスターと異なり、nunu.ai の AI エージェントはパフォーマンスと規模を維持したまま 24 時間体制で作業するため、増大する需要に対応できます。
製品化までの時間の短縮: nunu.ai は、テストプロセスを自動化し効率化することで、開発者が問題を迅速に特定して修正できるようにしています。これにより、開発サイクルが大幅に短縮され、品質を損なうことなく短期間でゲームをリリースできます。
簡単な統合: デベロッパーは、nunu.ai の軽量な SDK を簡単に導入できます。また、互換性のあるゲームにブラックボックステストを使用し、メンテナンスを最小限に抑えることもできます。
マルチプレーヤー型ゲームに対応した機能: AI エージェントを簡単に増やし、実際のプレーヤーの操作をシミュレートして、マルチプレーヤー型ゲームのテストにまつわる積年の課題を解決できます。
クロスプラットフォーム対応: 現時点では PC ゲームとモバイルゲーム（iOS と Android）に対応しており、コンソールゲームにも近日中に対応予定です。

これらの高度な AI エージェントは、開発パイプライン全体でゲームを自動的にテストするため、あらゆる段階で継続的な品質保証が可能になります。nunu.ai は、反復的なテストタスクを自動化することで、開発者が最も重要な作業、つまり「プレーヤーに卓越したゲームエクスペリエンスを提供すること」に集中できるようにします。

aside_block: <ListValue: [StructValue([('title', 'Google Cloud を無料で試す'), ('body', <wagtail.rich_text.RichText object at 0x7fa39c3aaf40>), ('btn_text', '無料で開始'), ('href', 'https://console.cloud.google.com/freetrial?redirectPath=/welcome'), ('image', None)])]>

ElevenLabs: AI を活用した音声合成による没入型エクスペリエンス

AI は、ゲームプレイの仕組みや品質保証だけでなく、プレーヤーの没入感を高める別の基本的な要素も強化できます。それは「音声」です。ElevenLabs は、この変革の最前線に立つ企業です。

ElevenLabs が提供する AI を活用した音声テクノロジーにより、没入感のある動的でスケーラブルなエクスペリエンスを生み出すことができます。ゲームスタジオは、Google Cloud のインフラストラクチャと ElevenLabs の音声 AI を組み合わせることで、これまでにない新たなリアルタイムのやり取りを実現し、ゲームのローカライズと制作を簡単かつ迅速に行うことができます。

ElevenLabs の AI 音声ソリューションには、次のようなメリットがあります。

リアルタイムの対話型キャラクター音声: AI を活用した NPC との没入感のある交信。
カスタム音声デザイン: 独自の音声の迅速な作成とカスタマイズされたサウンドエフェクト。
迅速な会話制作: AI による、会話やボイスオーバーのテキスト読み上げ。
容易になったグローバルローカライズ: 自動化された高品質の音声翻訳。
マーケティングや予告編用の合成ボイスオーバー: ゲームのプロモーションやストーリーテリング向けに、AI による魅力的なボイスオーバーを生成できます。
AI 生成のナレーションとオーディオブック: ゲームの世界観、カットシーン、インタラクティブなストーリーテリングに適した長尺の音声コンテンツを効率的に制作できます。
マルチモーダル AI の統合: 音声 AI と LLM やその他の生成 AI ツールを組み合わせて、コンテキストを認識したインテリジェントな会話を実現できます。
AI を活用したコンタクトセンターとサポート: 応答性に優れた自然な AI 音声エージェントで、顧客とのやり取りを強化できます。

ゲームスタジオは、Google Cloud のスケーラブルな AI インフラストラクチャと ElevenLabs の業界をリードする音声合成により、プレーヤーの没入感を高め、制作費用を削減し、ゲームの世界を生き生きと表現できます。

Common Sense Machines（CSM.ai）: 3D コンテンツ制作のための最高水準の AI モデル

Common Sense Machines（CSM）は、3D コンテンツ制作のための最高水準の AI モデルを構築することで、AI ネイティブゲーム開発を刷新しています。同社は最近、世界最大規模の AI モデルベンチマークサイトである Hugging Face の 3D Arena カテゴリで、世界ナンバーワンの 3D / AI モデルであるという評価を受けました。

CSM のモデルは、AI で生成された高品質なアセットの新しい基準となります。これにより、アーティストは創造性を高め、没入型の環境を構築し、リトポロジーや UV リマッピングなどの単調な作業に費やす時間を減らすことができます。

CSM は、戦略的パートナーシップを通じて、すでに具体的な成果を上げています。独自の AI 搭載パズルゲームエンジンを活用するゲームスタジオ、Cosmic Lounge と連携して、マーケティングと LiveOps コンテンツ用の 3D アセットを生成しています。LiveOps コンテンツとは、ゲームのリリース後に継続的に更新され、ゲームをレベルアップする動的要素（新しいキャラクターのスキン、季節アイテム、環境アセットなど）です。ゲームスタジオは、ユーザー獲得と収益を促進するユースケースに焦点を当てることで、効率の向上と制作のボトルネックの解消だけでなく、成長の促進にも AI を活用できます。

CSM は、アーティストの代わりとなることではなく、アーティストを支援することを重視しています。AI ハイブリッドワークフローが急速に進化していますが、CSM は、創造的なプロセスにおいて人間のモデラーが引き続き重要な役割を果たすと考えています。

AI を活用したゲームの未来

ベンチャー企業 Andreessen Horowitz の一部門である A16Z Games のパートナー Macy Mills 氏は、次のように述べています。「ゲーム業界は大きく変化しており、AI がクリエイターや開発者を支援して、かつてないレベルの没入感と効率性を達成しています。nunu.ai、ElevenLabs、CSM.ai の先駆的なツールにより、ゲーム開発は大きく変化するでしょう。これらのツールのおかげで、ゲームスタジオは真の魅力を持つ世界とエクスペリエンスを作り出すことに集中できます。」

AI は、ゲームの制作、テスト、エクスペリエンスの手法を刷新しています。Google Cloud は、nunu.ai、ElevenLabs、CSM などの革新的なスタートアップと提携することで、ゲームデベロッパーが可能性の限界を押し広げ、よりスマートかつ高速な、没入感のあるゲームエクスペリエンスを提供できるよう支援しています。

この記事の冒頭の画像は、Vertex AI で実行されている Imagen 3 に次のプロンプトを入力して作成しました。「ファンタジー、シューティング / ミリタリー、8 ビットなど、さまざまなゲームジャンルのキャラクターたちが崖の上に立ち、エキサイティングな世界と地平線を眺めているところを背後から見た、リアルなビデオゲームスタイルの広角の俯瞰ショット。全体的に『ゲームの未来』というコンセプトを表現してください。」...「もう少し 8 ビット風にして。」

-Google Cloud、ゲーム担当グローバルディレクター Jack Buser

バンダイナムコエンターテインメント / バンダイナムコスタジオ: GKE と Spanner で『鉄拳8』のグローバルなプレイ環境を支える

Mon, 09 Dec 2024 02:00:00 +0000

2024 年に 30 周年を迎えた 3D 対戦格闘ゲーム「鉄拳」シリーズ。

累計販売本数 5,800 万本以上を誇り、eスポーツの正式種目にも採用される同作は、世界中でファンを熱狂させ続けているビッグタイトルの 1 つです。

その最新作『鉄拳8』のシステム基盤には Google Cloud が採用されています。

国や地域を超えて行われる対戦の競技性を成立させるため、プレイヤーに安定的かつ公平な環境を提供することが求められる中、精密な同期通信を Google Cloud がどのように支えているのか。

最高の環境で最高のプレイ体験の提供を目指し進化し続ける『鉄拳8』への思いとともに、バンダイナムコエンターテインメントおよびバンダイナムコスタジオのキーマン 2 名に語っていただきました。

利用しているサービス:
Google Kubernetes Engine（GKE）, Spanner

利用しているソリューション:
Google Cloud for Games

TEKKEN™8 & ©Bandai Namco Entertainment Inc.

インタビュイー:

株式会社バンダイナムコエンターテインメント
QM室
デジタルテクノロジー部
シニアテクニカルオフィサー
河原真太郎氏

株式会社バンダイナムコスタジオ
技術スタジオ第３グループ
オンラインテクノロジー部
ディレクター
中野茂生氏

その他の導入事例はこちらをご覧ください。

バンダイナムコエンターテインメント、Google Cloud のスケーラブルで安全なインフラストラクチャを利用して、人気シリーズ全体でのシームレスなゲーム起動を実現

Thu, 05 Sep 2024 03:10:00 +0000

※この投稿は米国時間 2024 年 9 月 4 日に、Google Cloud Press Release に投稿されたものの抄訳です。

Google Cloud は本日、株式会社バンダイナムコエンターテインメント（以下、バンダイナムコエンターテインメント）により、2024 年 1 月にリリースされた人気格闘ゲーム『鉄拳8』のクラウドプロバイダーに選ばれたことを発表しました。今回の選出は、Google Cloud、バンダイナムコエンターテインメント、株式会社 Diarkis（以下、Diarkis）の三者の連携により実現したものです。『鉄拳8』は Google Cloud を活用し、数万人のユーザーが同時にゲームをプレイするピーク時でも信頼性の高いパフォーマンスを提供します。

ライブサービスゲームの長期的な成功は、多くの場合、その立ち上げの成功によって決まります。プレイヤーがゲームにアクセスできないというネットワークの問題や、ライブゲームプレイを妨げるネットワークの遅延は、ゲーム会社の懸念事項です。Google Cloud を使用することで、バンダイナムコエンターテインメントは地球規模でライブゲームのワークロードを処理しながら、世界中で常にゲームプレイの一貫性と信頼性を確保できます。

バンダイナムコエンターテインメント『鉄拳』シリーズのエグゼクティブゲームディレクター / チーフプロデューサーである原田勝弘氏は次のように述べています。

「『鉄拳』シリーズは生誕 30 周年を迎え、シリーズ史上最高のコンテンツをお届けしたいと考えました。『鉄拳8』には過去作のノウハウを活かしつつ、全体のクオリティを高めるために多大な投資を行ってきました。格闘ゲームとしての要素だけでなく、オンラインで他のユーザーとのコミュニケーションを楽しめる大規模なビジュアルロビーなどの新要素も追加しました。信頼できるクラウド上で動作する『鉄拳8』は、自信を持ってユーザーの皆様にお届けできるタイトルに仕上がりました。」

『鉄拳8』は、Google Cloud の安全なネットワークと、Google Kubernetes Engine (GKE) と Spanner の自動スケーリング機能を活用しています。これらの製品はコミュニティ機能と対戦モードを強化し、プレイヤーはオンラインおよびマルチプレイヤーコンポーネントにシームレスにアクセスできるようになります。大規模なライブゲームコンピューティングを処理する最良の方法の 1 つである GKE は、プレイヤーの所在地に関係なく、接続する近くのサーバーを迅速かつ簡単に見つけられるよう支援します。

オンラインマルチプレイヤーゲームを専門とする日本のゲーム・ミドルウェア開発会社である Diarkis は、カリフォルニア州サンフランシスコで開催されたゲーム開発者会議 Game Developers Conference (GDC) 2024で『鉄拳8』のケーススタディを紹介しました。プレゼンテーションでは、プレイヤーが対戦相手をすばやく簡単に見つけて接続できるようにする、『鉄拳8』の高速マッチング機能を紹介しました。この機能は、Google Cloud のグローバルインフラストラクチャと Diarkis 独自のマッチメイキングアルゴリズムの組み合わせによって実現しています。

Diarkis の CEO である高橋信頼氏は次のように述べています。

「Google Cloud との連携により、当社のすべてのタイトルでシームレスでスケーラブルかつ安全な起動が保証され、最高のパフォーマンスを維持しながら大量のプレイヤーを同時にホストできるようになりました。」

Google Cloud のゲーム部門ディレクターのジャックビューザーは次のように述べています。

「Google Cloud では、ゲームの成功はレガシーオンラインインフラストラクチャの制約なく、プレイヤーが得るゲーム体験によってのみ評価されるべきであると考えています。Google Cloud の優れた機能を世界中のゲーム開発者に提供することで、今後何世代にもわたってプレイヤーの心に残る忘れられないゲームプレイ体験を生み出すというバンダイナムコエンターテインメントのミッションをサポートします。」

Tencent: より良いゲーム開発のために分析文化を醸成する

Mon, 20 May 2024 03:00:00 +0000

※この投稿は米国時間 2024 年 5 月 11 日に、Google Cloud blog に投稿されたものの抄訳です。

Tencent は、中国の深センに本社を置くインターネットとテクノロジーの大手企業です。当社のミッションは「Value for Users, Tech for Good（使う人に価値を与え、社会を良くするための技術）」です。『Level Infinite』『PUBG MOBILE』『王者栄耀』『GTFO』『Assassin's Creed Jade』など、世界的によく知られたゲームを開発している会社でもあります。2020 年 2 月には、先日創業 30 周年を迎えた Funcom を買収しました。Funcom は、『The Longest Journey』『Anarchy Online』『Metal: Hellsinger』などのゲームで高い評価を得ています。

Funcom の買収により、優れた技術と業界屈指のゲーム会社が結合しました。これを受け、私たちは Google Cloud の支援を得ながら、Funcom で分析文化を醸成するという決断を下しました。その過程で直面した課題と実装したソリューションをご紹介します。

説明するために、オンラインマルチプレーヤー型サバイバルゲームの『Conan Exiles』を例として使用します。Funcom が開発し、2017 年にリリースされたこのゲームは、常にアップデートと新コンテンツのリリースが行われており、2022 年にはライブサービスゲームモデルに移行されました。そのためには、ビジネス上の意思決定を後押しするデータが必要でした。

スケーラビリティと成長のためのアーキテクチャ

Funcom のアーキテクチャは、社内の開発チームをライブオペレーションで支援し、ゲームサーバーの健全性をモニタリングするために開発されたものでした。アーキテクチャ全体がオンプレミスの仮想マシンとオープンソースのフレームワークで構成されていたため、ユースケースとスケーラビリティが制限されていました。以前の技術スタックは、ライブサービスゲームモデルの観点から見て、データドリブンなアプローチを考慮して構築されたものではありませんでした。

Funcom のデベロッパーと経営陣の関心を踏まえ、私たちは Google Cloud と協力して新しいアーキテクチャを開発することにしました。『Conan Exiles』の最初のシーズンのリリースまで数か月しかなかったため、Google Cloud チームは完全に機能するデータウェアハウスを提供してくれました。このデータウェアハウスを使用してダッシュボードを構築し、経営陣、マーケティング担当者、ライブオペレーション担当者などの主要関係者に分析情報を提供しました。以下の図は、私たちが使用したアーキテクチャを示したものです。

私たちは、いくつかの重要な基準に従って新しい技術スタックを構築しました。その基準とは、統合のしやすさ、多様なユースケースへの対応、総所有コスト（TCO）の最適化です。

このデータプラットフォームの構築は、パズルのピースを組み合わせるようなものでした。データレイクやクエリエンジンとして機能する Cloud Storage や BigQuery などの主要プロダクトを使用して以前のデータインフラストラクチャを置き換えました。その結果、2 か月足らずで堅牢なデータパイプラインと安定したデータプラットフォーム基盤を構築することができ、ゲーム内プレーヤーのアクティビティプレイテストなど、以前は観測されなかった多数の新しいゲームデータを利用できるようになりました。これには、ソーシャルリスニングやコミュニティの反応といったマーケティングデータ、CPU、グラフィック、メモリ使用量に関するパフォーマンスデータ、さらにはクラッシュモニタリングデータも含まれます。

ゲームとマーケティングデータセットを結び付ける新たな基盤

新しいアーキテクチャを設定した私たちは、コストパフォーマンスを最適化し、データスタックの制御を改善して、マーケティングデータセットとセールスデータセットを結び付ける、データの新たな活用方法を模索することにしました。たとえば、ゲームリードは、データがゲーム内開発をどのように支えているかを理解する必要があります。一方、マーケティングチームは、ゲーム内データに簡単にアクセスしてマーケティング活動を支援する必要があります。

そのために、常に最新の KPI レポートを使ってパイプライン全体を自動化し、Google Cloud 内でマーケティングパフォーマンスをモニタリングできるようにしました。さらに、データチームはプレーヤーの行動、コミュニティ、マーケティング全体のデータを結び付けることで、詳細な分析情報に基づいた推奨事項を提供できます。

収益を生み出す技術スタックで前進する

Google Cloud を使用することで、ゲームデータパイプラインや日々の意思決定システムに影響を与えることも、追加のエンジニアリングのオーバーヘッドを必要とすることもなく、元データパイプラインとデータレイクアーキテクチャを再設計できるようになりました。その結果、以前のアーキテクチャと比較して、1 日あたり 2 倍のゲームデータを処理できるようになりました。そのうえ、BigQuery と Cloud Composer を使用することで、1 か月あたりの費用が全体で 70% 削減されました。

今後は、Pub/Sub で構築した準リアルタイムのパイプラインで、このアーキテクチャをさらに発展させたいと考えています。また、データ品質のモニタリングとアラートを改善し、データ構造を標準化することで、新たに開発した機能をベータ版に直接デプロイできるようにして、製品化までの時間を短縮することも計画しています。

-Funcom、ゲームデータリードアナリスト Mathieu Ruiz 氏
-Tencent、データプラットフォーム担当マネージャー Hao Liang 氏

ゲームプレイの進化: ライブゲームから生きたゲームへ

Fri, 22 Mar 2024 01:00:00 +0000

※この投稿は米国時間 2024 年 3 月 19 日に、Google Cloud blog に投稿されたものの抄訳です。

この 1 年間で、ライブゲームモデルの人気が爆発し、リリースされるほぼすべての人気ゲームでライブサービス方式が採用されるようになりました。プレーヤーのエンゲージメントはこれまでにないほど高まっており、その大部分はライブゲームがきっかけとなっています。このことは、95% ものゲームスタジオがなんらかの形のライブゲームエクスペリエンスを開発しているという最新の調査結果にはっきりと表れています。実際、Electronic Arts（EA）は、小売店で販売される従来のゲームのリリースを継続する一方で、ライブサービスが 2023 年の同社のビジネスの 73% 以上を占めたと報告しています。このことは、進化するモデルがもたらす影響力の証であり、重大な変化を表しています。また、デベロッパーは熱心なプレーヤーたちとともに進化するゲームの必要性を理解しているということです。

今はデベロッパーにとって、生成 AI を利用してライブゲームを次のレベル、すなわち「生きたゲーム」に引き上げるチャンスです。ゲーム要素をリアルタイムに生成する「生きたゲーム」は、ゲーム環境を一変させ、デザイナー、開発者、アーティスト、マーケティング担当者を含むゲームクリエイターが、以前は想像できなかったような方法で、ワークフローの刷新や新たなエクスペリエンスの創出を実現できるようになります。

ライブゲーム: 新しい時代、新しいニーズ

ライブゲームには、継続的なアップデート、新しいコンテンツ、長期サポートなど、プレーヤーにとってワクワクするような特長があります。デベロッパーは、後れを取らないために、Google Cloud を利用して、このようなシームレスなバーチャルエクスペリエンスの構築に必要なインフラストラクチャにアクセスしています。しかし、重要なのはゲームサーバーだけではありません。データベースも同様に重要です。ゲームはプレーヤーのデータを糧にして成長しています。Google Cloud では、プレーヤーがゲーム内で獲得した「名声」や「プラチナ」などがすべて細かく記録されます。また、デベロッパーには、プレーヤーエンゲージメント戦略を改善できる分析情報も提供されます。ライブゲームによって、デベロッパーは以下を行えます。

地球規模のゲームをリリースし、運営する: もちろん、何よりもまず、プレーヤーがゲームをプレイしたいときにゲームが問題なく動作することが肝心です。Google Kubernetes Engine（GKE）はゲームサーバーを管理するためのスケーラブルな基盤を提供するため、プレーヤー数の変動に容易に対応できます。Cloud Spanner は、ライブゲームで絶えず発生する要求に対処するのに最適な、グローバルに分散された高パフォーマンスのデータベースを提供します。プレーヤーのプロフィールやゲーム内の経済要素などを保存し、全世界の膨大な数のプレーヤーのスムーズなゲームプレイを実現できます。
データドリブンな意思決定を行う: 分析はきわめて重要です。デベロッパーは、BigQuery と Looker を使用した堅牢なデータ分析を通じてプレーヤーの行動を把握し、それに応じてコンテンツや機能を調整することで、エンゲージメントを最大限に高めることができます。BigQuery でトラッキングされ、Looker で可視化されたプレーヤーのパフォーマンスに基づいて動的に難易度が調整されるゲームを想像してみてください。

ライブゲーム向けの、強力で、適応性が高く、安全なプラットフォームがあれば、デベロッパーは、優れたゲームの作成や、活発なプレーヤーコミュニティの構築といった、本来の作業に専念できるようになります。

生成 AI によってライブゲームが生きたゲームに生まれ変わる

今後に目を向けると、生きたゲームはライブゲームモデルに革新をもたらすでしょう。ゲーム自体がゲームのアクティブな参加者となります。静的なエクスペリエンスはもはや過去のものです。デベロッパーは、GKE や Vertex AI などの Google Cloud プロダクトを使用することで、プレーヤーの選択に動的に適応する、パーソナライズされたゲームを作成し、ユニークなクエストやチャレンジを作り出して、ストーリーを継続的に進化させることができます。これにより、プレーヤーの没入感とエンゲージメントはより深いレベルに達し、関わるすべての人に充実したエクスペリエンスがもたらされます。

『Guild Wars 2』や『Blade & Soul』などの人気ゲームタイトルの開発や販売を手掛けるグローバル企業、NCSOFT は、Google Cloud の AI Infrastructure を使用して、社内の大規模言語モデル（LLM）セット、VARCO LLM を活用しています。NCSOFT の VARCO LLM は、ゲーム開発に必要な高品質のコンテンツの生成に特化しています。NCSOFT は、VARCO LLM を使用して、テキスト作成から、「デジタル」の人間キャラクター、プレーヤーと仮想キャラクターの会話、プレーヤーの行動に応じた動的なストーリーライン生成の管理まで、一連の AI 搭載ツールを開発しました。それにより、プレーヤーはより魅力的で動的なゲームを体験できるようになりました。

コラボレーションエコシステムでゲームプレイの未来を形作る

コラボレーションも、ゲームの未来を形成する要素になります。ゲームデベロッパー、テクノロジープロバイダ、プレーヤーの活発なエコシステムを発展させることで、ストーリーテリングとエンゲージメントの境界を押し広げる、真に生きている世界を構築できます。

Google Cloud は、テクノロジーとインフラストラクチャを提供するだけにとどまらず、業界のリーダーが提供する強力で革新的なゲーム開発ツールとデベロッパーをつなぐ架け橋にもなります。

たとえば、AI 音声テクノロジー企業の Replica Studios は、ゲーム制作、ゲームプレイ、配信を強化するために、Google Cloud および GlobalLogic と提携しています。Replica Studio の Voice Lab テクノロジーは、高度で費用対効果の高い生成 AI により、ノンプレイヤーキャラクター（NPC）とストーリーに新たな命を吹き込みます。Replica Studio の Voice Lab は、プロンプトからヒントを得てユニークな音声を生成します。この音声を Google の Gemini 言語モデルと組み合わせると、ゲームのアセット、環境、情報を利用して、声、性格、動機、行動がそれぞれ異なる、数千もの多様なキャラクターを作成できます。Replica Studios、Globallogic、Google Cloud は、インタラクティブエンターテイメントの次世代を定義する、生きたゲームの新しい時代を切り開いています。

Google Cloud のパートナーエコシステムは、最新のエンジン、オンラインバックエンドソリューション、Web3 プラットフォーム、生成 AI ツールへのアクセスを提供し、それによって、ゲームデベロッパーは、プレーヤーがより深いレベルで共感するエクスペリエンスの創出、長く続くつながりの構築、生きたゲーム内でコミュニティを共有しているという感覚の形成といった、最も重要な作業に専念できるようになります。

Google Cloud は、次世代のゲームエクスペリエンスを推進する準備ができています。生成 AI のような革新的なテクノロジーにより、デベロッパーは、創造性を発揮し、かつてないほど没入感があり、動的で、魅力にあふれたゲームを生み出すことができます。ゲームプレイの未来は明るく、デベロッパーは、Google Cloud をパートナーとして利用することで、最も野心的なビジョンを実現するためのツールとサポートを得ることができます。

Google Cloud for Games について詳しくは、goo.gle/cloudforgames をご覧ください。

-Google Cloud、ゲーム業界ソリューション担当ディレクター Jack Buser

ライブサービスゲーム向けにクラウドで ML を実行

Thu, 07 Mar 2024 03:30:00 +0000

※この投稿は米国時間 2024 年 2 月 23 日に、Google Cloud blog に投稿されたものの抄訳です。

生成 AI は、この 1 年で多くの業界で最も注目を集めるテクノロジーとなりました。Google Cloud for Games では、オンラインゲームのユースケースに生成 AI の可能性を最も高く見出しており、クリエイターに対してより動的なゲームの構築、より適切な収益化、より迅速な市場投入を実現できると考えています。その一環として、Google はゲーム会社が Google Cloud を利用して生成 AI をトレーニング、デプロイ、メンテナンスできる方法を検討してきました。Google がこれまで取り組んできたことと、それを今日からゲームでどのように活用できるのかについて説明していきたいと思います。本投稿では生成 AI アプリケーションに焦点を当てますが、これから説明するフレームワークは、生成型だけでなくすべての ML を念頭に置いて開発されています。

長期的に見れば、ゲームにおける生成 AI の可能性は無限大ですが、短期的に見て今後 1～2 年で業界にとって最も現実的で価値があるのは、次のようなものであると考えています。

ゲーム制作
適応型のゲームプレイ
ゲーム内広告

これらはそれぞれ、ゲーム開発と公開プロセスの中核部分を支えています。ゲーム制作における生成 AI（主に 2D テクスチャ、3D アセット、コードの開発）は、新しいゲームを作成する労力を軽減し、製品化までの時間の短縮とゲーム開発者の全体的な効率の向上に効果を発揮します。プレーヤーのエンゲージメントの維持や、既存のタイトルの収益化について考えると、適応型の対話やゲームプレイといったアイデアによりプレーヤーを飽きさせず、カスタムのゲーム内オブジェクトで魅了し続けることが可能です。ゲーム内広告は収益化の新たな領域を切り開き、閲覧回数に合わせて広告を高度にパーソナライズする機能だけでなく、広告の配置やゲームへの統合をパーソナライズして、閲覧回数とエンゲージメントを最適化するシームレスな広告エクスペリエンスを生み出します。AAA 級の超大作はともかく、小さなゲームの制作時間を考えてみると、個々のゲームアセットの開発には膨大な時間がかかっています。生成モデルが開発者のトイルを軽減し、スタジオ開発チームの生産性をほんのわずかでも向上させることができれば、製品化までの時間が短縮され、私たち全員にとってより良いゲームが生まれるでしょう。

今回の投稿の一部として、ゲーム向けの生成 AI フレームワークを紹介します。このフレームワークでは、Google Cloud 上でゲーム向け生成 AI を実行するためのテンプレートと、これらのライブモデルをサポートするためのデータ取り込みとストレージのフレームワークを提供します。以下でこのフレームワークのデモを説明します。具体的には、サンプルゲーム環境での画像生成とコード生成に関する 2 つのケースを紹介します。

ただ、ここで Google Cloud での取り組みに入る前に、まずはゲームにおける ML についての一般的な誤解と向き合ってみましょう。

クラウドベースの ML とライブサービスゲームの進展

ライブゲームサービス用にクラウドで ML を実行すると、高額な費用がかかったり、レイテンシが高くなりエンドユーザーエクスペリエンスが損なわれたりするという意見が一般的です。ライブゲームは常にクライアント / サーバーパラダイムで実行されており、多くの場合、権限を必要としない高コンピューティング負荷のプロセスはクライアントで実行することが望ましいとされています。これは一部のモデルやプロセスにとっては最適なデプロイパターンですが、唯一の方法ではありません。クラウドベースの生成 AI、あるいは実にあらゆる形式の AI / ML が、単に実現可能なだけではなく、今日のライブゲームに必要なレイテンシをサポートしながら開発者のトイルを大幅に削減し、パブリッシャーのメンテナンスコストを削減してくれます。また、安全性も向上しています。クラウドベースの AI は攻撃、操作、不正行為からモデルを保護します。

スタジオの設定に応じて、Google Cloud は適応型ゲームのワールド向け生成モデルの完全なクラウド内デプロイまたはハイブリッド環境デプロイをサポートできます。一般的に、技術スタックとニーズに応じて 2 つのアプローチを推奨しています。

ゼロから始める場合は、低レイテンシのサービス提供のために Vertex AI のプライベートエンドポイントを利用することをおすすめします。これは、低運用負荷のソリューションを探している場合や、ライブゲーム環境と相互作用しないサービスを実行している場合でも機能します。
Google Cloud 上でゲームサーバーを実行している場合、特に Google Kubernetes Engine（GKE）上で運用し、その環境を利用して超低レイテンシでの配信を行おうとしている場合は、ゲームサーバーと一緒にモデルを GKE にデプロイすることをおすすめします。

では、Vertex AI から始めましょう。Vertex AI はパブリックエンドポイントとプライベートエンドポイントの両方をサポートしますが、ゲームの場合は通常、適切なレイテンシを実現するためにプライベートエンドポイントの利用を推奨しています。Vertex AI モデルはアダプタレイヤというレイヤを利用します。これには 2 つの利点があります。予測を行う際にモデル全体を呼び出す必要がないことと、開発者が行ったファインチューニングがテナントに含まれることです。これにより、クラウドであろうとオンプレミスであろうと、モデルを自分で実行する場合と比較して、膨大なベースモデルと、それらをサポートするための関連するサービングやストレージインフラストラクチャを扱う必要がなくなります。前述したように、以下のデモではこの 2 つを紹介します。

すでに GKE 上でゲームサーバーを実行している場合は、GKE 上で独自の ML モデルとオープンソースの ML モデルの両方を実行し、GKE のネイティブネットワーキングを利用することで多くのメリットが得られます。GKE Autopilot を使用したテストでは、ゲームサーバーと並行してデプロイした場合、ミリ秒未満の範囲で予測パフォーマンスを達成できることが示されています。公共のインターネット上で、従来のクライアント側デプロイで見てきたものより優れているとは言わないまでも、それと同等のミリ秒単位の低レイテンシを達成しました。GKE で実行することで費用的に影響が出る可能性を心配している場合は、もう一度考えてみてください。大多数のゲーム業界のお客様は、GKE にデプロイすることによる費用削減を実現しており、開発者の生産性も約 30% 向上しています。ML のデプロイとゲームサーバーの両方を GKE Autopilot で管理すると、運用面の負担も大幅に軽減されます。Google のテストでは、モデルを Vertex にデプロイする場合と GKE にデプロイする場合では、費用はほぼ同等であることがわかりました。

統合データプラットフォームによりリアルタイム AI が実現

AI / ML によるパーソナライゼーションは、プレーヤーの好み、ゲームプレイ、ゲームの世界や知識に関する大量のデータに基づいて機能します。ゲームにおける生成 AI への取り組みの一環として、Google Cloud の利点を最大限に活用し、整合性と可用性を確保するデータパイプラインとデータベーステンプレートを開発しました。

ライブゲームには強整合性が必須であり、モデルは生成的であろうとなかろうと、プレーヤーとその習慣に関する最新の情報を必要とします。モデルを常に最新かつ安全に保つには、定期的な再トレーニングが必要であり、Spanner や BigQuery などのグローバルに利用可能なデータベースは、生成 AI か他の AI かにかかわらず、モデルに入力されるデータの鮮度と安全性を確保します。現在の多くのゲームでは、ユーザーはマップ / レルムによって細分化されており、それらの間には厳格な境界線が引かれ、エクスペリエンスは確固たる決定とアクションによって制限されています。ユーザーが単一のレルムに存在するモデルにゲームが移行していくにつれて、これらのゲームには単一のグローバルに利用可能なデータストアが必要になります。ゲーム内のパーソナライゼーションには、プレーヤーの活動状況をライブで把握する必要もあります。LiveOps 環境で ML モデルを実行するには、強力なデータパイプラインとデータフットプリントがモデル自体と同じくらい重要です。セルフマネージドのデータセンターフットプリントにおける頻繁なモデル更新の複雑さを考慮すると、クラウドでモデルのトレーニング、デプロイ、全体的なメンテナンスを管理する方が負担を軽減できると Google は考えています。

リアルタイムのデータパイプラインと生成モデルを組み合わせることで、プレーヤーの好みに関するプロンプトをモデルに通知したり、ゲームの状態をパーソナライズするために、場所、時期、理由を追跡する他のモデルと組み合わせたりすることもできます。現在利用可能なものとしては、ユーザーに関連する 3D メッシュを事前に生成する、プレーヤーの好みや気分に合わせてメッシュを異なる色、パターン、照明に変更する、あるいはプレーヤーが自然言語に基づいてゲーム環境を完全にカスタマイズできるようにすることなどが考えられます。これらのすべてが、プレーヤーを満足させ、ゲームに熱中させるために効果を発揮します。

デモ機能

フレームワークについて詳しく見ていきましょう。デモでは、Google Cloud のデータ、AI、コンピューティング技術をどのように連携させ、ゲームの状態をリアルタイムにパーソナライズしているのかに焦点を当てます。

フレームワークには次のものが含まれます。

クライアントとサーバーの Unity

オープンソース:

Terraform
Agones

Google Cloud:

GKE
Vertex AI
Pub/Sub
Dataflow
Spanner
BigQuery

このフレームワークの一環として、Unity ストアのアセットを使用するオープンワールドのデモゲームを Unity で作成しました。私たちはこのゲームをオープンワールドゲームとして設計しました。プレーヤーは NPC と対話する必要があり、ゲームの目的を達成するためにプレーヤーをアシストする動的なビルボードに導かれます。このゲームは Agones を使用して GKE 上で実行されており、複数のプレーヤーをサポートするように設計されています。わかりやすくするために、1 人のプレーヤーとそのアクションに注目します。

さて、フレームワークに戻りましょう。バックエンドの Spanner データベースには、プレーヤーとその過去のアクションに関する情報が含まれています。また、Google マーケティングプラットフォームとの接続により、この架空のゲーム世界全体にわたるユーザーの購買習慣に関するデータも取得しています。これにより、デモゲームでプラットフォーム間のユニバーサルなプレーヤーデータを収集できるようになります。Spanner はトランザクションデータベースであり、BigQuery は分析データベースです。データはそれらの間を自由に行き交います。

このフレームワークの一環として、Google がプレーヤーについて知っていることすべてを活用して Vertex AI でレコメンデーションモデルをトレーニングし、ゲーム内のオファーや広告をパーソナライズできるようにしました。このデモでは、これらのモデルのことはひとまず忘れて、画像生成、NPC チャットという 2 つの生成 AI ユースケースと、適応型ゲームプレイユースケースでのコード生成に焦点を当てます。ゲームに推奨するデプロイパターンとして、ゲームサーバーと並行して GKE にデプロイする方法、そして Vertex AI を利用する方法の両方を説明します。画像生成には、オープンソースの Stable Diffusion モデルを GKE でホストし、コード生成と NPC チャットには Vertex AI 内の gemini-pro モデルを使用しています。テクスチャを変更する必要がある場合、またはゲームオブジェクトを再配置する場合、Gemini LLM を使用して、ゲーム環境内でプレハブをレンダリング、配置、構成できるコードを生成します。

キャラクターがゲーム内を歩き回る際、プレーヤーに次の動きや経路を示唆する画像を適応的に表示します。実際には、これらはゲームをテーマにした画像や広告である場合もあります。今回のケースでは、プレーヤーがゲームプレイを進めるために何を探すべきかを示唆する画像を表示します。

上の例では、プレーヤーに向けて本に囲まれた男性を表示し、次の目的として図書館を探す必要があるかもしれないというヒントを与えています。そのヒントは、ゲームの序盤で NPC が話していた謎とも一致します。プレーヤーがビルボードに近づく、あるいはあらかじめ設定された時間ビルボードを眺めるなど、これらのビルボードを操作することで、ゲームのストーリーがそのコンテキストに適応します。

また、コード生成を使用して、その場でプレハブを読み込んで構成することもできます。以下では、現状の環境をそのまま表示し、NPC にバスの色を黄色に変更するように依頼します。これにより、バスの色とテクスチャが動的に更新されます。

テキストまたは音声でリクエストを行うと、Google Cloud 生成 AI モデルは環境内のプレハブを更新するために必要な正確なコードを生成し、それをゲーム内でライブでレンダリングします。

この例では、ゲーム内でコード生成を使用する方法を示していますが、ゲーム開発者は同様のプロセスを使用して、ゲーム環境内にゲームオブジェクトを配置、構成して、ゲーム開発をスピードアップすることもできます。

次のステップに進んでこのテクノロジーをチェックしたい場合は、以下の GitHub リンクとリソースをぜひご覧ください。

さらに、誰もがフレームワークのすべての側面に興味があるわけではないことも承知しています。だからこそ、柔軟に対応できるようにしています。プロジェクト全体を詳しく理解するか、特定の機能の実装方法を理解するためにコードの特定の部分だけに取り組むか、選択は自分次第です。

Google Cloud 生成 AI について理解を深めたい場合は、次の有用な厳選されたリソースをご覧ください。

最後に、このプロジェクトでの作業に興味がある、あるいはプロジェクトに貢献したいとお考えの場合は、このデモの一環で使用された生成 AI サービスに焦点を当てた GitHub のコードをぜひ探索してみてください。

ゲーム向け生成 AI クイックスタート

-Google Cloud for Games、スペシャリスト カスタマー エンジニア責任者、Patrick Smith

-Google Cloud for Games、AI / ML ソリューション アーキテクト、テクニカル リーダー、Dan Zaratsian

ゲームスタート: Aiven for Apache Kafka と BigQuery の究極の組み合わせ

Fri, 09 Feb 2024 02:10:00 +0000

※この投稿は米国時間 2024 年 1 月 31 日に、Google Cloud blog に投稿されたものの抄訳です。

ゲーム業界は、世界で最もデータドリブンな業界の一つです。ゲームでは、プレーヤーの行動や、ソーシャルメディアやカスタマーサポートチケットとのゲーム内でのトランザクションによって、秒単位で大量のデータが生成されます。このデータは、ゲームの改善、ビジネス上の決定の改善、新しく革新的なプレーヤー体験の開発に利用できます。

ただし、ゲーム業界は現在、このデータをリアルタイムまたはニアリアルタイムで分析するにはどうすればよいか、という独特な課題に直面しています。これは、ゲームが常に変化と進化を続けており、パーソナライズされたレスポンスの高いエクスペリエンスをプレーヤーが期待しているためです。次のような状況を想像してみてください。あなたはお気に入りのゲームの新バージョンのリリースを友人たちと楽しもうとしています。その日は休暇をとり、スナック菓子の準備もできたところです。すると突然、サーバーが応答しなくなりました。リロードしても何も変わりません。

たとえば MMORPG（マルチプレーヤー型オンラインロールプレイングゲーム）は、リアルタイムで仮想世界をシミュレーションしながら、多数の同時接続プレーヤーに対処できる必要があります。このことからゲームサーバーインフラストラクチャに負荷がかかり、増大するプレーヤーベースのニーズに対応するためにインフラストラクチャをスケーリングするのが困難になることがあります。こうした事態に対応してインフラストラクチャを自動スケーリングするのに役立つのが、リアルタイムアナリティクスです。

リアルタイムでインフラストラクチャスケーリングを自動化

Aiven for Apache Kafka は、プレーヤー数に基づくデータに時間的価値を提供して、トラフィックパターンと負荷に基づくインフラストラクチャスケーリングの自動化を可能にします。さらに、Aiven for InfluxDB と Aiven for Grafana を使用すれば、ゲームの進行中もデータインフラストラクチャチームがゲームサービスの正常性に関する分析情報を取得できます。特定のしきい値が検出されると、Kubernetes Operator または Terraform Provider を使用した自動化スクリプトで、需要に対応するために新たなゲームサービスをスピンアップできます。

ゲーム業界はコンピューティング能力を最も必要とする業界の一つであり、オンラインゲームやモバイルゲームは大量の同時接続プレーヤーに対処できる必要があります。このことからゲームサーバーインフラストラクチャに負荷がかかり、増大するプレーヤーベースのニーズに対応するためにインフラストラクチャをスケーリングするのが困難になることがあります。

Aiven Platform は、ゲームサービスの自動スケーリングに適したさまざまな機能を、あらゆるマネージドサービスに提供します。

スケーラビリティ: Aiven のサービスは、あらゆる量のデータを処理できるようにスケーリング可能であるため、待望のバージョンリリースのようなゲームプレーヤー数が膨大になる状況に最適です。
高い信頼性と可用性: 管理プレーン（Aiven Console）により、信頼の高いサービスが常に利用可能になります（通常、Aiven for Apache Kafka の小規模なプランでも、3 つの高可用性ノードが標準で提供されています）。
セキュリティ: Aiven Console は、お客様のデータを保護するため、暗号化や認証などの多数のセキュリティ機能とコンプライアンスをデフォルトで提供します。

リファレンスアーキテクチャに示すように、ゲームサーバーのスケーリングに Aiven スタックを使用すると、次のようなメリットを得られます。

パフォーマンスの改善: ゲームサーバーの数を必要に応じて自動的にスケールアップまたはスケールダウンすることで、ゲームサーバーが常に最適なキャパシティで運用されるようになります。
費用の最適化: 必要な数のゲームサーバーだけを実行することで、クラウドコンピューティングの運用費を削減できます。
スケーラビリティの改善: Aiven for Apache Kafka と Aiven オブザーバビリティサービス（Aiven for InfluxDB と Aiven for Grafana の組み合わせ）を使って、増大するプレーヤーベースのニーズに対応するようにゲームサーバーインフラストラクチャをスケーリングできます。

将来を見据えた自動スケーリング

BigQuery スイートの Google Pub/Sub 機能を使用して、ゲーム業界の長期的な分析を実行できます。Pub/Sub は、ニアリアルタイム / 長期向けのメッセージングサービスであり、ゲームサーバーからのデータの収集、つまりこのケースでは Aiven for Apache Kafka からのメッセージの収集に使用できます。

インフラストラクチャの自動スケーリング以外にも、プレーヤーテレメトリデータの長期分析に Pub/Sub と BigQuery を使用するときに活用できるさまざまなユースケースがあります。

プレーヤーの行動分析: ゲーム会社はプレーヤーの行動を経時的に追跡することで、プレーヤーのゲームプレイの傾向とパターンを特定できます。この情報は、プレーヤーエクスペリエンスの改善、新しいコンテンツの開発、ゲーム内経済のバランス調整に使用できます。
ゲーム パフォーマンス分析: ゲーム会社はゲームパフォーマンスを経時的に追跡することで、技術的なパフォーマンスが低迷しているエリアを特定できます。この情報は、バグ修正、パフォーマンスの最適化、ゲームエクスペリエンスの全体的な品質改善に使用できます。
ビジネス インテリジェンス: ゲーム会社はプレーヤーエンゲージメントデータやその他の指標を分析することで、ビジネス上の意思決定をより的確に下すことができます。たとえばゲーム会社はこのデータを使用して、人気と収益性が最も高いゲーム作品を特定できます。

ゲーム業界のお客様は、長期分析に Pub/Sub と BigQuery を使用することで、次のようなさまざまなメリットを得られます。

スケーラビリティと信頼性: Pub/Sub と BigQuery はいずれもスケーラビリティと可用性が高いサービスであり、処理できるデータの量に制限はありません。
セキュリティ: Pub/Sub と BigQuery は、暗号化や認証など、データの保護に役立つさまざまなセキュリティ機能を提供します。
費用の最適化: Pub/Sub と BigQuery を使用して長期データポイントを分析することで、今後のプレーヤーのワークロードを予測し、自動スケーリング動作を調整できるようになります。

Aiven と Google Cloud の連携のメリット

Google Cloud と Aiven on Google Cloud を連携させれば、ゲーム業界は、スムーズなリリースに向けて準備を進めながら、プレーヤーを理解し、プレーヤーがゲームに戻ってくるようにするために利用できるデータを確保できるようになります。重要となるのは、サービスの信頼性です。スムーズなエクスペリエンスはゲームの成功につながります。しかし、費用についても常に考慮する必要があります。運用の総費用を削減し、リアルタイムでサイズを適正化することで、ゲームプレイのユーザビリティを強化し、かつ不要なオーバースケーリングを最小限に抑えることができます。

BigQuery の予測分析では、過去のデータに基づいてスケーリングパラメータを調整できるため、パラメータ調整なしでは失われる可能性がある将来のボリュームをより詳細に制御できます。Aiven のマネージドサービスと Google Cloud の組み合わせによって、データに時間的価値が付加され、リリースが成功することで収益増となります。さあ、ゲームスタートです。

まとめと次のステップ

ゲーム業界が進化を続け、データドリブンな意思決定が採用されるのに伴い、Aiven for Kafka と BigQuery スイートの Pub/Sub を組み合わせて使用することが、成功を収めるためにますます不可欠になっています。ゲーム会社はリアルタイムデータの力を活用して、新たな機会を切り開き、プレーヤーエクスペリエンスを強化し、持続可能な成長を促進できます。詳細については、以下のリンクをご覧ください。

Aiven と Google ネイティブサービスの接続に関する詳しい資料: Aiven for Apache Kafka と Google BigQuery で分析情報をすばやく獲得
Google Cloud がゲーム業界の成功において果たした役割: ゲームの将来を見据えて: Google Cloud のライブサービスゲーム戦略
実際にお試しになりたい場合は、こちらをクリックして Google Cloud Marketplace に掲載された Aiven のリスティングを確認し、ご希望を Google にお知らせください。

-Google Cloud、ISV パートナー エンジニア Sebastian Senen-Gonzalez

-Aiven、パートナー ソリューション アーキテクトChris Butler 氏

ゲーム業界における生成 AI の革命: 無限の創造性への道

Fri, 20 Oct 2023 16:00:00 +0000

※この投稿は米国時間 2023 年 10 月 7 日に、Google Cloud blog に投稿されたものの抄訳です。

ゲーム業界は常にテクノロジーの限界を押し広げ、テクノロジーを活用して人間の想像力を解き放ってきました。ゲーム開発者は、コンピューティング、グラフィックス、ネットワーキング、ソーシャルメディア、データの最先端の進歩を活用して、現在世界中で 30 億人以上のプレーヤーを魅了するエクスペリエンスを作り上げています。

ゲーム業界はテクノロジーの最前線に立つことで、他のビジネスにとって革新の道標としての役割を果たし、情報の提供、参加、大規模なつながりのための新しい方法を人々に示しています。たとえば、2000 年代半ばに消費者が一斉にモバイルデバイスを導入し始めましたが、ゲームはいち早くこのトレンドをビジネスモデルに取り入れたパイオニアでした。現在、地球上のほぼ半数の人がゲームをプレイしており、その大半がモバイルデバイスを通じて利用しています。

モバイルに関して業界が初期段階で学習した教訓は、今日ほぼすべてのゲームプラットフォームで業界の支配的なビジネスモデルとなっている「ライブサービスゲーム」へとつながりました。ライブサービスゲームは、開発者とプレーヤー間の作成、エンゲージメント、学習のサイクルに依存しており、常に変化し、進化します。

今日、私たちは新たな時代の最前線に立っています。ゲーム業界が生成 AI の変革の可能性をどのように活用し、ゲームエクスペリエンスの限界をこれまで以上に押し上げることはできるのか。それを探ることが最も重要です。デザイナー、開発者、アーティスト、マーケティング担当者など、ゲーム製作に関わる人々は、生成 AI により仕事のやり方に革命をもたらし、提供できるエクスペリエンスの幅を広げることが可能です。

ゲームにおける生成 AI の違いを理解する

では、生成 AI はこれまでの AI と何が違うのでしょう。あるレベルから言うと、それは進化的であるということです。思い返せば、ゲームでは長い間「AI」という用語が使われてきましたが、その定義は一連のぎごちないルール、ディシジョンツリー、行動のことでした。プレーヤーは「bot」と関わりますが、人間と比較すると、bot は多くの場合人を惹きつけるようなものではありませんでした。ただ、ごく最近では、ゲーム会社は（データと分析に基づいて構築された）真の AI と ML のフレームワークを使用して、プレーヤーの理解、解約の管理、収益の増加を実現しています。中には、大規模言語モデル（LLM）などの高度な AI アルゴリズムをフレームワークに統合し、生成 AI を実現している企業もあります。

しかし、生成 AI は一歩をはるかに超える進化を遂げています。これはまったく新しい次元のイノベーションであり、リアルタイム 3D グラフィックスの導入以来、ゲーム業界にとって最大の変化であると私は断言します。ここで、生成 AI がゲームを変革している 2 つの基本的な方法をご説明します。

生成 AI によるスケーラブルな開発: コンテンツの作成は、最大ではないにしても、ゲームにかかる費用の一つです。英国の CMA によると、大ヒットゲームの開発予算は 1 億ドルをゆうに超えることもあると言います。このような巨額の投資を行っても、特にオーディエンスが地球規模に成長するにつれて、ゲームチームは新しいコンテンツに対するプレーヤーの需要に追いつくのに苦労するでしょう。生成 AI を活用することで、コード、アート、ダイアログなど、全般的なゲーム制作を加速し、チームはプレーヤーに対して良質なサービスを大規模に提供できるようになります。これにより、コラボレーション、アイデアの検討、パーソナライズを改善し、既存チームがより良いコンテンツをより速いペースで作成できるようになります。さらに、エンタープライズグレードの生成 AI により、開発者は自社独自のデータを保護しながら、知的財産を尊重した方法でこの新しいテクノロジーを活用できます。
リアルタイム生成 AI: 生成 AI の制作プロセスへの統合が進むにつれて、生成 AI をゲーム自体に統合する開発チームも出てきました。そこでは、ゲームのプレイ中に生成 AI がリアルタイムで実行されるため、プレーヤーのエクスペリエンスに革命をもたらす可能性を秘めています。それは、巨大な LLM を抽出してプレイヤーに反応し、リアルタイムで対話する、応答性の高い動的な生成 AI です。ゲームそのものが、プレーヤーの明示的あるいは暗示的な行動に基づいてコンテンツを生成できるようになります。つまり、新しいアイテムやレベルを即座に生成できる、あるいはゲーム内のキャラクターにリアルなディスカッションを行わせる、といったことまで可能になります。プレーヤーの声に自然に反応できるゲームや、プレーヤーの行動に応じてまったく新しいコンテンツを生成できるゲームを想像してみてください。これらの例から、これまで世界が見たこともないような、プレーヤーに対するパーソナライズとゲームインタラクションの新しい枠組みを想像できます。

イノベーションへのスタートを切る

私が説明した未来は幻想のように聞こえるかもしれませんが、それは思っているよりも近いものなのです。実際、個人や企業がゲーム業界の変革を形作る基本的なモデルを模索しており、現在この未来に向けた基盤はすでに築かれつつあります。ゲーム業界が生成 AI を取り入れるにつれて、ビジネスは新たな地殻変動を経験すると確信しています。卓越したビジネスモデルが、パッケージソフトのゲームからライブサービスゲームへと進化したように、今度は「生きたゲーム」へと再び進化を遂げています。このようなモデルでは、プレーヤーと開発者の関係サイクルがゲームそのものにまで拡大され、3 者すべてが相互作用しながら、ビジネスの成果とともにプレーヤーのエクスペリエンスを豊かにしていきます。

生成 AI をゲームにうまく組み込むには、志や意欲以上のものが必要です。開発者はデータを活用し、まったく新しい方法で使用する必要があります。一貫性と説得力のある結果を生成できる信頼性の高いデータセットに基づいてモデルをトレーニングします。また、ゲーム開発者はプレーヤーを注意深く尊重しながら知的財産を保護し、責任を持って安全に AI を実装する必要もあります。

Google Cloud では、強力なゲームサーバー、堅牢なデータアセット、高速ネットワーク、最も強力で責任ある AI の機能を網羅する、生きたゲームのための包括的なエコシステムの提供に尽力しています。今日、ゲーム開発者が特に注目すべきなのは、安全かつ強力な環境で独自データによる生成 AI を実現する Vertex AI です。Vertex AI の Model Garden は、ゲーム開発に最適な安全で堅牢なエンタープライズ環境において、チームが学び、創作できる多様な独自のオープン基盤モデルを提供します。過去数か月にわたり、私たちは貴重なフィードバックを収集し、ゲーム会社が次に Google の生成 AI で何を期待しているのかに基づいてロードマップを作成しました。

先ほども述べたように、ゲーム業界は常に人間の発明、創造性、最先端のテクノロジーを導入しようとする意欲によって繁栄してきました。生成 AI はワークフローを加速させ、斬新なプレーヤーエクスペリエンスを生み出し、オーディエンスのエンゲージメントと収益化のための新たな道を切り開くかもしれませんが、この根本的な真実は変わりません。これまでの革新的なテクノロジーと同様に、ゲーム開発者は、その才能と置き換えるのではなく、その才能を増幅させるために生成 AI を使用するでしょう。この業界をエキサイティングなものにしているのは彼らの創造性なのですから。

生成 AI への取り組みを開始する方法の詳細については、電子書籍「生成 AI に関するエグゼクティブガイド」をダウンロードしてください。

-Google Cloud、ゲーム業界ソリューション担当ディレクター、Jack Buser

aside_block: <ListValue: [StructValue([('title', 'どのようなプロンプトを作成しますか？「エグゼクティブのための生成 AI ガイド」で早わかり 10 ステップ'), ('body', <wagtail.rich_text.RichText object at 0x7fa3a9c9bee0>), ('btn_text', '記事を読む'), ('href', 'https://cloud.google.com/blog/transform/ja/introducing-executives-guide-to-generative-ai?hl=ja'), ('image', <GAEImage: introducing-executives-guide-to-generative-ai-midjourney-hero.png>)])]>

Google Cloud、カプコンとの新たなパートナーシップを発表

Tue, 29 Aug 2023 01:00:00 +0000

※この投稿は米国時間 2023年 8 月 28 日に、Google Cloud より発表された Google Cloud Press Release の抄訳です。

【サニーベール発- 2023 年 8 月 28 日】 - Google Cloud は本日、家庭用ゲームの企画、開発、製造、販売、配信会社である株式会社カプコン（以下、カプコン）との新たなパートナーシップについて発表しました。すでにカプコンは、拡張性と安全性を備えた Google Cloud を活用して開発した新たなゲーム「ストリートファイター6」を世界中で配信しています。

ライブゲームが成功するかどうかは、ゲームの発表当日にスムーズに運用できたかどうかで決まるといわれています。ゲーム会社にとって、プレイヤーが急に増えてもネットワークやゲームへのアクセス環境を気にすることなく、どんな時でもプレイヤーが安心して遊べるゲーム体験を提供できることは非常に重要です。カプコンの開発チームは、これまでも様々な最新技術を活用してゲーム環境を最適化してきましたが、今回、Google Cloud を使用することで、世界中でプレイされている非常に大規模なライブゲームのワークロードを処理しながら、常に安定性の高いゲームを提供することを実現しています。

カプコンの「ストリートファイター」シリーズの最新作「ストリートファイター6」は、今年 6 月の発売開始以来、全世界で 200 万本以上を売り上げています。本ゲームでは、Google Kubernetes Engine（GKE）と Cloud Spanner の特長である安定したネットワークと自動スケーリング機能を活用しているため、プレイヤーはゲームのバトルハブやカスタムルームなど、ストリートファイターのオンラインやマルチプレイヤーエリアにスムーズにアクセスすることができます。GKE は、プレイヤーがどこに住んでいても、近くのサーバに迅速かつ容易に接続するため、大規模なライブゲームに最適だとゲーム業界において高く評価されています。

株式会社カプコンの GM/VP of Engineering 井上真一氏は以下のように述べています。

「カプコンは『ストリートファイター6』において、新規プレイヤーにもリピーターにも楽しんでもらえるような対戦格闘ゲームを提供しています。高い評価を得ている『ストリートファイター』シリーズの最新作の販売開始時に、何も問題を起こすことなく最良のゲーム体験を提供することは最重要課題でした。Google Cloud を利用することで、一度に 10 万人以上のプレイヤーが問題なく遊ぶことができました。」

Google Cloud ゲーム担当ディレクター Jack Buser は、次のように述べています。

「ゲームは、どれだけ楽しく遊べるかによってその価値が決まります。Google Cloud の最高の製品や機能を世界中のゲーム開発者に提供してきましたが、今回、『何世代にもわたってプレイヤーの心に残る忘れられないゲーム体験を創造する』というカプコンの使命をサポートできたことを嬉しく思います。」

Improbable、DevOps Awards で「クラウドの機能を最大限に活用」賞を受賞

Wed, 02 Aug 2023 01:40:00 +0000

※この投稿は米国時間 2023 年 7 月 22 日に、Google Cloud blog に投稿されたものの抄訳です。

Improbable Worlds Limited（通称 Improbable）は、2012 年以降、仮想世界構築の最前線に立ち続けているメタバーステクノロジー企業です。世界トップクラスのチームを擁する Improbable は、Morpheus Technology を使って没入感の高いゲーム体験やイベント体験を創出し、15,000 人を超えるユーザーが同時に同じ場所にいるかのような交流を実現しています。このブログ投稿では、2022 年の DevOps Awards で「クラウドの機能を最大限に活用」賞を獲得した Improbable による DevOps の成功事例をご紹介します。DevOps Awards の受賞者と、各受賞者が DevOps Research and Assessment（DORA）の指標と手法を活用して企業を成長させた事例の詳細については、まずこちらをご覧ください。

ビデオゲームのビルドは従来、高額なインフラストラクチャ費用を払うか、開発やその他の下流工程で長時間待つ必要がありましたが、単一の仮想環境に何万人ものユーザーを集めようとする場合、そのどちらも許されません。ゲーム業界や仮想世界を構築する企業にとって、迅速なプロトタイピングと QA は不可欠です。開発者はできるだけ早くビルドを機能させ、デプロイを実施することで、検証、フィードバック収集、イテレーション、再試行ができるようにしなければなりません。たった一度のビルドの失敗で、何百人もの開発者の作業やテストが中断する可能性があります。修正されるまで何時間も待つという選択肢はありません。そのため、当社は高速で信頼できるシステムを提供する必要があります。

スピードだけでなく、スケーラビリティと安定性も大きな問題になりつつありました。なぜなら、納期のさらなる短縮と日々のビルド要件の急増が伴う急速な拡張に、Improbable の静的で柔軟性に欠ける当初のシステムを適応させる必要があったからです。緊密に統合されたシステムに依存する古いインフラストラクチャでは、アップグレードや新機能の追加によっても 1 つの小さなシステムに障害が生じることがあり、その障害が会社のサービス全体の停止につながる可能性がありました。

お客様のニーズに応える

当社の組織では、増大する需要に対応するには、技術面の課題とプロセス面の課題の両方に取り組む必要があると考えました。また、お客様のニーズに応えるには、Windows Metaverse（ゲーム）開発のための、高速かつ安価で、信頼性とスケーラビリティが高い専用インフラストラクチャが必要でした。なお、このインフラストラクチャでは、開発者の作業を中断させないトップクラスのサポートを提供する必要もありました。

このプロジェクトの成功の鍵は、サービスとして CI / CD を導入したことです。つまり、CI / CD 開発に関するガイダンスだけでなく、以下も開発者に提供しました。

インフラストラクチャ
スクリプト
ソース管理
自動マージツール
自動リリースツール

ソリューション

このような複雑な問題には、ただコンピューティングを投入するのではなく、ビルド時間を最適化できる、より技術的に優れた複合的なソリューションが必要でした。さらに、Windows VM は、コンテナ化しないと管理が難しくなる可能性があります。また、費用が急速に増え、投資収益率が減少する可能性もあります。当社のチームは、必要な技術的ソリューションをすべてクラウドで見つけました。

Google Cloud を使用することで、安定性、スケーラビリティ、サステナビリティがより高い開発手法を構築し、最初から Google Cloud の多数のツールやサービスを統合することができました。ジョブリクエストが届くと、Cloud Run のスケーラーが即座に応答し、可能な限り迅速にプロセスを開始します。スケーラーには、即時の応答と高速処理のための Webhook スケーラーに加え、Webhook や外部サービスに関連する問題が発生した場合のバックアップのためのポーリングスケーラーなどがあります。また、Cloud Run を構成するスケーラーは、需要に合わせて自動的にスケーリングし、高い信頼性を備えています。

単純に VM 上で直接ビルドするのではなく、Compute Engine の Windows Server for Containers イメージを利用し、ホスト VM 上でセカンダリ Windows インスタンスをコンテナとして起動しました。こうすることで、ソースコード、アセット、ビルド出力を、ホスト VM 上で動作する仮想ハードドライブ（VHD）に分離できます。ビルド中に行われた変更とビルド出力は、キャッシュに保存するか、実行終了時にコンテナを削除し、VHD を既知の状態に戻してリセットできます。これにより、ビルドの絶対的な分離と再現性がもたらされるだけでなく、次のジョブのためにビルドエージェントを素早くプールに戻すことができます。

当社の開発プロセスでは「ゴールデンイメージ」の使用も開始しています。ゴールデンイメージとは、特定のプロジェクトで実行可能なすべてのビルドの組み合わせを実行した直後の、VM の Google Cloud イメージのことです。Unreal を使用したゲームデザインの場合、デバッグ、開発、テスト、出荷用パッケージ化の各ビルド構成で使われるすべてのプラットフォーム用のビルドがこれに含まれます。また、ソース、アセット、ビルドのすべてのデータが、イメージ上の VHD においてキャッシュに保存されます。キャッシュに保存され、ゴールデンイメージ上にあるこのデータにより、リセットする既知の状態を保持したまま、次のジョブが反復的に実行されるため、処理が大幅に高速化します。

このような技術的なツールや改善により、当社の大きな課題の多くが縮小しました。とはいえ、これらの技術的なソリューションがあっても、DevOps ファーストなエンジニアリング文化も育まなければ、Improbable のデジタルトランスフォーメーションは半分しか実現しなかったでしょう。この文化的な変革で実現した注目すべき成果をいくつかご紹介します。

できるだけ早く指標を追跡し、時間を無駄にしている主な分野を特定して修正する
信頼性の高いバックアップシステム、明確なワークフロー、個別の問題に最適な対処方法に関するガイドラインにより、よりスムーズにサービス停止を軽減する
システムの冗長性を確保したヘルスチェックで、主要なシステムが期待どおりに稼働していることを確認する
チームを公正に保ち、協力的な問題解決を促進するために、ビルド時間、信頼性、費用に関する指標についてチーム間でデータを共有する
受け身の姿勢で問題が起きてから対応するのではなく、問題の発見、報告、対処に積極的に取り組む

開発者がベストを尽くせるよう、当社の組織はインフラストラクチャ費用よりも開発者の時間を優先するようになりました。リードタイムのばらつきを抑えることで、開発者のフラストレーションを軽減し、開発者が信頼性の高い平均納期に基づいて作業時間を計画できるようにしました。また、迅速な状況報告や、共有システムとコードベースの複雑さの軽減など、サービス停止を減らす手法も取り入れました。

クラウドの力

クラウドの力と集中的な DevOps の実践により、当社の組織では、費用削減と開発効率の両方において顕著な改善が見られました。毎日実行されるビルドジョブの件数は 500 件から 3,000 件以上に増え、以前は 2 回だけだったソース変更のプリフライト検証は現在 8 回になっています。費用は 1 ジョブあたり 1.7 ドルから 0.5 ドルに著しく減少しました。以前のシステムでは年間 90 万ドルかかっていたプロジェクトが、12 万ドルで同じビルド出力を実現できるようになりました。

クラウドコンピューティングの 5 つの機能すべてを導入したことで、ソフトウェアデリバリーと組織のパフォーマンスが向上しました。この 5 つの機能には次のものが含まれます。

リソースプール: 最大容量で動作する数千個の vCPU を含む何百もの VM 上でビルドリクエストを並行して実行することにより、リソースのワークロードを分散させ、処理能力を最適化します。つまり、プロジェクトやお客様が増えれば増えるほど、ビルドジョブあたりの料金は低くなります。
迅速な弾力性: VM プールを常に最適な容量に保つダブルスケーラー技術スタックにより、ビルドリクエストは 10～160 秒以内に処理されます。VM プールは、必要に応じて VM を追加したり、アイドル状態の VM を停止したりするなど、需要に合わせて動的にサイズ変更されます。
メジャードサービス: 当社は、Cloud Run で作られた bot を使用してパフォーマンスを追跡することで、SLO と機能予算の支出が予定どおりかどうかを可視化しています。この bot は、わかりやすいレポートと最新情報を投稿します。また、DataDog トレースと指標スタックを使用して、ビルド時間から成功 / 失敗率まですべてを追跡します。
オンデマンドセルフサービス: 開発者は本番環境から完全に隔離された環境で、特定のビルドリクエスト用の VM を自動的にスピンアップできるツールを使用して、阻害要因や官僚的な手続きなしに試験運用版を実行し、テストデータを収集できます。
広範なネットワークアクセス: ゼロトラストセキュリティモデルによるアクセス制御とリソース管理に Cloud Identity-Aware Proxy（IAP）を使用することで、開発者はオフィスの IP や広範なキャッチオールファイアウォールの制限を受けることなく、クラウドリソースをリモートで自由に使用できます。

このようにクラウドの力をフル活用することで、開発プロセスにおいて以下のような測定可能な改善が見られました。

デプロイの頻度: ビルドシステムのロールアウトが週に 1 回から各マージ後の実行に変わり、プロジェクト、プロダクト、そしてお客様は 1 日に何百回もメタバースをデプロイできるようになりました。
変更にかかるリードタイム: 特殊なクラウドスタックを使用することで、リードタイムは少なくとも 300% 短縮されました。プライマリ CI ビルドの平均時間は 60 分から 15 分に短縮され、メタバースデプロイのビルドは 90 分から 25 分に短縮されました。その結果、Improbable はより迅速に新機能を反復処理し、テストできるようになりました。
成功率の変化: サービスビルドジョブの全体的な成功率は 96% から 99.99% に、マスタービルドジョブの成功率は 80% から 99% になり、費用と時間の節約、特にサポートコールの減少につながりました。
サービス復旧時間: デュアルスケーラーシステム、コンテナのセットアップ、その他のクラウドベースのソリューションの間で、技術的な問題のために VM のプールを完全にワイプしてスケーラーを再起動しなければならなかったことは 3 回しかありません。また、これらのサービス停止では、わずか 10 分ですべてのビルドがオンラインに復帰し、サービス提供が再開されました。

DevOps Awards 受賞者を紹介するシリーズの今後のブログ投稿にも引き続きご注目ください。DORA リサーチについて詳しくは、2022 年の State of DevOps Report をお読みください。

‐ Improbable、リードソフトウェアエンジニア Joshua Huburn 氏

グローバルスケールのマルチプレーヤー型デモにより加速するマルチプレーヤーゲーム開発

Thu, 27 Jul 2023 01:10:00 +0000

※この投稿は米国時間 2023 年 7 月 15 日に、Google Cloud blog に投稿されたものの抄訳です。

変化と競争の激しいマルチプレーヤーゲームのバックエンドを構築する作業は複雑です。調整の必要な流動的要素が多くあり、プロダクトやソリューションの領域は、ほぼ無限大と言えるでしょう。オープンソースソリューションや、評価、テスト、実装が必要なその他のソリューションをサポートするマネージドプロダクトは無数にあります。しかし多くの場合、それらすべてを相互に組み合わせて使用につなげていく過程は定まっていません。

この問題を解決して独自のマルチプレーヤーゲーム構築の取り組みを開始するために、Google Cloud for Games の専門家からなる学際的なチームが団結し、変化の激しいマルチプレーヤーゲームにおいてグローバルスケールの統合デモを作成しました。このデモの目的は、マルチプレーヤーゲームのバックエンドをホスト、スケール、オーケストレートするために、Google Cloud が確認した本番環境で活用している以下のようなテクノロジーや手法を示すことです。その実例は、サービスやデータストレージから専用のゲームサーバーまで多岐にわたります。

デモで使われるテクノロジー例:

ゲームエンジン

ゲームクライアントおよび専用サーバーコード用の Unreal Engine 5
クライアントサイド認証用のカスタム Go ゲームランチャー

オープンソース

Iinfrastructure as Code 用の Terraform
専用のゲームサーバーをホストティング、スケーリングする Agones
グローバルプレーヤーベースをマッチメイキングする Open Match

Google Cloud

継続的インテグレーションとデプロイメントのための Cloud Build および Cloud Deploy
バックエンドマイクロサービスをホスティングする GKE Autopilot
Agones でオーケストレートされた Unreal 専用ゲームサーバーのホスティング用に実行する、グローバルに分散された GKE Autopilot および GKE Standard クラスタ
クラスタ間サービスディスカバリおよび通信のための Anthos Service Mesh
プレーヤーのゲーム内データを保存するための Cloud Spanner

また、開発をさらに促進できるように、チームがこのプロジェクトに取り組む過程で学んだヒントとアドバイスも共有します。

Droidshooter

グローバルスケールのマルチプレーヤー型ゲームデモ「Droidshooter」をプレイ中

このデモの開発中に利用したサーバーサイドのテクノロジーと手法を明示し、簡単に検索できるようにするために、「Droidshooter」と呼ばれる非常にシンプルなマルチプレーヤーゲームを計画的に構築しました。

このゲームは、小型宇宙船を操縦して他の 2 人のプレーヤーと対戦し、敵船にエネルギーバーストを発射して体力を奪おうというものです。敵船の破壊に成功するたびに、ポイントを獲得します。30 秒が経過した時点で最も多くのポイントを獲得しているプレーヤーが、そのラウンドの勝者となります。

アーキテクチャの概要

各コンポーネントの詳細に入る前に、アーキテクチャの概要を見てみましょう。

「Droid Shooter」のアーキテクチャの概要（クリックして拡大）

このゲームは世界中のオーディエンスを対象としているため、グローバルなインフラストラクチャフットプリントを用意しています。

ゲームの一般的なバックエンドサービスは us-central1 でホストされています。レイテンシの影響を受けにくく、単一のリージョンとクラスタに統合することで管理がずっと簡単になるからです。プレーヤーとマルチプレーヤー型の専用ゲームサーバーとを接続するとレイテンシの影響を受けやすいため、世界中の複数のリージョンにあるそれぞれの Kubernetes クラスタにサーバーを配置し、必ずプレーヤーのロケーションに近接するようにします。

ゲーム状態のフロー

ゲームクライアントの起動

上記のアーキテクチャにおいて、各プレーヤーは Game Launcher のインスタンスを開始します。これにより、Google ログインによる認証と、ゲームを起動するためのオプションが提供されます。

ゲーム状態のシーケンス図

データベースにプロファイルレコードが存在しない場合は、ログイン時に作成されます。その後、プロファイルサービスからプロファイル情報が取得され、（上記の名称の一つである）Launcher とゲームクライアントに表示されます。

「Open Droidshooter」をクリックすると、ゲームクライアントが起動し、フロントエンドサービスを通じてゲームをリクエストします。その後、ゲームクライアントと前述の Launcher 用にホストされているバックエンドサービスへのほぼすべての通信に対し、認証されたエンドポイントを提供します。

マッチメイキング

ここからは、クライアントはゲームサーバーがホストされる各リージョンで、グローバルな「ping ロケーション」一式をリクエストする必要があります。ゲームで最適なリアルタイムエクスペリエンスを得るために、低レイテンシであることが求められるためです。そのため、プレーヤーのロケーションから各リージョンの ping レイテンシを積極的に測定する必要があります。そうすることで、それぞれのロケーションからのレイテンシが似通ったプレーヤー同士をマッチングして、レイテンシが高すぎるリージョンを無視することができます。残念ながら、プレーヤーを最も近いリージョンだけに送信することはできません。プレーヤーベースが分割され、本来なら一緒にゲームできるはずのプレーヤーがマッチングできなくなるからです。

ゲームクライアントは各リージョンの各レイテンシ測定エンドポイントを利用して各リージョンへのプレーヤーのレイテンシを記録します。その後、このデータを（認証されたフロントエンドを介して）マッチメイキングシステムに送信し、他のプレーヤーがゲームできるようにグループ化をリクエストします。Droidshooter には非常にシンプルなマッチメイキングシステムがあり、マッチメーカーは、レイテンシが最も近い 3 人のプレーヤーをマッチングさせようとします。

ゲームサーバーの割り当て

ゲームをプレイするグループが形成されると、マッチメーカーは、プレーヤーに最適な場所を決定したリージョンにおいて、ゲームサーバーオーケストレーションシステムの専用のゲームサーバーをリクエストします。これらすべてのプレーヤーは同じエクスペリエンスを得る必要があるため、専用ゲームサーバーがゲーム世界の状態をシミュレートし、接続されているすべてのプレーヤーにリアルタイムでこの情報を伝達します。そうすることで、どのプレーヤーにとっても快適な Droidshooter エクスペリエンスが実現します。

したがって、ゲームの状態がメモリ内シミュレーションであることから、各クライアントが直接接続する必要のあるアドレスとポートは、マッチメーカーにより（フロントエンドを介して）ゲームクライアントに返され、その後、Droidshooter がプレイされます。

最終クリーンアップ

ゲームが完了するとゲームサーバーは自動的にシャットダウンされますが、Google Cloud のゲームサーバーフリート管理システムにより、すぐに新しいサーバーがスピンアップされ、新しいプレーヤーがプレイできます。

エコシステムの内訳

上記のフローを実装するために使用した各プロダクトとオープンソースプロジェクト、およびそれぞれを選択した理由を見てみましょう。

Terraform

このプロジェクトを開始するにあたり、ゲームのバックエンドを実行するインフラストラクチャの作成を自動化するため、Infrastructure as Code をセットアップすることをまず最初に決定しました。そこで、オープンソースの Infrastructure as Code ソフトウェアツールである Terraform を採用することにしました。これにより、宣言型の構成言語を通して、安全かつ予測可能なインフラストラクチャの作成や変更、改善ができるようになります。

このツールを選択した理由は、広く採用されていて、プロジェクトを開発中の各メンバーが互いに同じインフラストラクチャをセットアップできるうえ、最終エンドユーザーは、すでに使い慣れているツールを使用して同様のインフラストラクチャを自分で簡単にスピンアップできるからです。

ヒントとアドバイス

コード全体で Terraform 変数を十分に活用してください。一連の構成可能な変数により、エンドユーザーは、プロジェクトを完全なグローバル構成でスピンアップできます。また、開発目的としてより小規模で実行コストの低い構成を掲げることも可能です。

GKE Autopilot と GKE Standard

GKE Autopilot はフルマネージドの Kubernetes エクスペリエンスであり、実行する Pod に対してのみ料金を支払います。ホストの基盤となるインフラストラクチャについて心配する必要はありません。これは、プロファイルやフロントエンドサービスなどのカスタムサービス、Open Match プラットフォームサービス（詳細は後述）など、あらゆるサービスに最適です。Autopilot で開発するうえでチームにとって特に良かった点は、構築中の新サービスや、それらを実行する GKE クラスタの容量を心配する必要がなかったことです。Autopilot によってインフラストラクチャが管理されていることがわかっていたので、デプロイするだけで済みました。

このデモでは、実際に GKE Standard と GKE Autopilot の両方でゲームサーバーコンテナをホストしています。本番環境では単一のプラットフォームを選択することが望ましいかも知れません。ただし、Autopilot の利便性がゲームサーバーのワークロードの要件に適する場合は、スタック全体で問題なく動作しますが、ゲームサーバーで、基盤となる GKE Standard ノードに特定の調整が必要となる場合は、GKE Standard も適切なソリューションになります。

ヒントとアドバイス

まずは Autopilot から始めて、必要な場合にのみ GKE Standard に移行してください。GKE Standard に移行する理由がない場合は、利便性のよい Autopilot で時間を大幅に節約できます。基盤はすべて Kubernetes であるため、プラットフォーム間の移行は非常に簡単です。

Agones

Agones は、Ubisoft と Google Cloud が独自に共同作成したオープンソースのゲームサーバーオーケストレーションプラットフォームですが、現在ではさまざまなゲームスタジオから 200 名を超えるコントリビューターが参加しています。このプラットフォームは、Kubernetes にはゲーム固有の最適化が必要であるという認識のもとに構築されており、Kubernetes に対してゲームサーバーワークロードのライフサイクルを伝え、ゲーム中にプレーヤーエクスペリエンスが中断されないようにします。そのため、当チームでは、Agones の使用をすぐに決定しました。Agones がすべてを管理してくれるため、ゲームサーバーのライフサイクル管理やインフラストラクチャ使用の最適化を心配する必要がないからです。

Agones は API と SDK 一式も提供しているため、デモをプラットフォームに統合するのも簡単です。ゲーム状態の管理やプレーヤー管理などの機能が含まれているため、これらの機能をゼロから実装するのに必要な時間を大幅に短縮できます。

ヒントとアドバイス

Agones に付属の Terraform モジュールを活用して、GKE Standard クラスタと GKE Autopilot クラスタの両方を作成しましょう。クラスタの作成手順に沿って自分で作成することもできますが、Terraform モジュールならそこまで手間をかける必要もありません。

Open Match

Open Match はマルチプレーヤーゲームのもう一つのオープンソースツールで、Google Cloud と Unity Technologies が独自に共同開発しました。これは、ゲームデベロッパーがスケーラブルで拡張可能なマッチメイキングシステムを構築するのに有用なマッチメイキングフレームワークです。Open Match は、ゲームデベロッパーが独自のマッチメイキングロジックを作成するのに使用できるツールと API 一式を提供します。さらに、グローバルプレーヤーベースをサポートするための基盤となるインフラストラクチャの管理もしています。

このプラットフォームを選択した主な理由は、マッチメイキングロジックを完全にカスタマイズできるだけでなく、このマルチプレーヤー型ゲームデモで処理したいトラフィックに合わせてスケールできる機能も備えているからです。

ヒントとアドバイス

Open Match は、デプロイ先の同じ Kubernetes クラスタ内でホストされている Redis のバージョンをバンドルしますが、Google Cloud 上でマネージド Redis サービス（高可用性、フェイルオーバー、パッチ適用、モニタリングなど）を提供する MemoryStore for Redis もぜひご活用ください。
GKE Autopilot で Open Match をホスティングすることをおすすめします。実行している Pod に対してのみ支払いが発生し、ノードインフラストラクチャを気にする必要がないため、Open Match の管理と維持がはるかに簡単になるからです。

Unreal Engine 5

Unreal Engine は、業界内での使用歴が長く、素晴らしいネットワーキングツールを提供しています。また本番環境でも多くのデベロッパーが使用しているため、マルチプレーヤーゲームの構築に最適です。Google Cloud では、このサンプルを本番環境ワークロードに合わせようとの試みがあり、採用はスムーズに決まりました。

Unreal Engine 5 の数ある利点の一つは、C++ と Blueprints の両方を介して、Agones とのシームレスなインテグレーションを実現できることです。Agones SDK が Unreal Engine 5 に統合されていると、デベロッパーは、ゲームサーバーのライフサイクル、構成、メタデータ、プレーヤーの追跡を管理しやすくなります。以下からソースをダウンロードして、直接プラグインを構築できます。https://github.com/googleforgames/agones/tree/release-1.30.0/sdks/unreal/Agones

ヒントとアドバイス

ゲームサーバーをホストしている各リージョンへのレイテンシ時間をクエリするには、Unreal Engine 5 ベースのクライアントも、いくつかの UDP パケットを Agones のレイテンシテストサービスに送信する必要があります。これに関するドキュメントを見つけるのは少し難しいかもしれませんが、Unreal のFUDPPing API を使用して、次のように UDP を介して ICMP Ping パケットを送信することができます。FUDPPing::UDPEcho()
クラウドのエンジンとやり取りするための Unreal Engine コンテナエコシステム（特に専用ゲームサーバーのコンテナイメージの構築）は非常にうまく実装されており、スムーズなデベロッパーエクスペリエンスを実現します。ぜひ一度お試しください。

Cloud Build と Cloud Deploy

Cloud Build と Cloud Deploy は、いずれもマネージド Google Cloud Platform プロダクトであり、合わせて使用することで、アプリケーションの継続的インテグレーションと継続的デプロイを自動化し、GKE Standard および GKE Autopilot とも緊密に統合できます。今回のグローバルスケールのゲームデモでは、バックエンドサービス用と Unreal Engine 5 専用ゲームサーバー用にアーティファクトとイメージを作成（前述の Unreal Engine コンテナシステムを使用）するうえで Cloud Build と Cloud Deploy を使用しています。

Cloud Deploy には複数のクラスタをデプロイメントターゲットとして任意にグループ化する機能があり、それが特に選ばれた理由でもあります。これにより、クラスタをリージョンごとにグループ化し、リージョンごとにロールアウトすることが可能になります。

各リージョンターゲットには、それを担う複数の GKE クラスタが含まれています

つまり、オーストラリアなどの人口の少ない地域でデプロイをテストし、すべてが計画どおりに進むことが想定できれば、人口のより多い地域セットへと移行できるということです。

ヒントとアドバイス

生成された YAML が Cloud Deploy を通じてクラスタに適用され、それが 262144 バイトを超える場合は、-- server-side kubectl フラグを使用します。また、Kubernetes のServer Side Apply の所有権問題を処理するために -- force-conflicts フラグと組み合わせてもよいでしょう。
Deployment が正常な状態になるまでに何度か失敗する可能性がある場合は、Cloud Deploy の機能 tolerateFailuresUntilDeadline を利用します。これにより、指定された期限まではシステムにより障害が許容されるようになります。これは、後のセクションで説明する Istio や Anthos Service Mesh で特に有用です。

Artifact Registry

Cloud Build と Cloud Deploy によって構築およびデプロイされたアーティファクトは、Artifact Registry コンテナリポジトリに保存されます。Artifact Registry では、イメージストリーミングを通じてバックエンドサービスや専用ゲームサーバーイメージのスピンアップ時間が高速化されるだけでなく、脆弱性スキャンなどの利点も得られます。

Anthos Service Mesh

完全なグローバルスケールのゲームを構築するには、世界中に分散した一連の GKE クラスタ間で通信する方法が必要でした。これには、Google Cloud のバックエンドサービスクラスタや Agones クラスタも含まれます。これは、世界中の特定リージョンにある Agones 利用の GKE クラスタからゲームサーバーの割り当てリクエストをルートする必要があるため、Open Match ベースのマッチメーカーにとって特に重要です。

ありがたいことに、Google Cloud には Anthos Service Mesh が付属しています。これは、オープンソースプロジェクト Istio に基づいてマネージドサービスメッシュを提供するサービスです。これは、クラスタ内の DNS をベースとしたサービスディスカバリに加え、マルチクラスタ通信の促進機能も提供するため、当チームのニーズに最適でした。

Istio の VirtualService を使用する機能も重要でした。これにより、バックエンドサービスクラスタ内のすべての Agones Allocation REST エンドポイントに対して単一の DNS エントリを持ち、リクエスト内のカスタムリージョン HTTP ヘッダーを使用して特定のリージョンへのルーティングを提供できるようになります。同時に、Workload Identity によってアクセス制御とセキュリティを管理することも可能です。これで、多くの問題が一度に解決しました。

ヒントとアドバイス

Terraform ではまだサポートされていないオペレーションもあるため、gcloud を介して Anthos フリート管理を行うには、Cloud Build の使用を必要とする場合もあります。
予期したマルチクラスタ Service DNS エントリが、それを必要とするクラスタ内に見つからない場合は、名前空間および一致する Service も同じクラスタ内に作成されているか確認してください。実装する必要はありませんが、DNS エントリの作成には、一致する名前空間と Service の両方が必要です。

Cloud Spanner

ゲームのリリースに関して以前からある問題は、どれだけのトラフィックが得られるかわからないということです。一方でリリースは非常に重要です。うまくいかなかった場合、リリース時に得られるはずだった水準にまでプレーヤーベースを回復させるのは非常に困難だからです。

Spanner をデータストレージプラットフォームに選ぶのは、まさにこれらの問題を解決するためです。Spanner は、マルチリージョンインスタンスに対して稼働率 99.999% の SLA を備えた高可用性を実現します。また、リリース時に発生し得るあらゆる要求に合致する水平方向のスケーラビリティとグローバルな強整合性があるため、ゲーム内でプレーヤーに正確な情報が示されていることが常に確認できます。

ヒントとアドバイス

GKE クラスタは、インスタンス構成で定義されているように、地理的に Spanner の近くに配置して、書き込みと一貫した読み取りのリクエストのレイテンシを減らすことが重要です。この例では、バックエンドサービスが us-central1 にあるため、Spanner も us-central1 に配置しています。
Liquibase は、yami 構成ファイルを通じて Spanner スキーマの変更と更新を管理する優れたツールです。
アプリケーションを Spanner に接続できるように Workload Identity を構成するには複数の手順があり、正確に行うのは難しいかもしれません。これを解決するために、Terraform で作成された IAM 構成から Cloud Deploy yaml ファイルを生成し、インフラストラクチャのセットアップと継続的デプロイ構成の両方が手動での作業なしで調整されるようにしました。

まとめ

無数のオープンソースツールやプロダクトの中からマルチプレーヤーゲームを構築するためのプロダクト一式を選択するのは難しく、膨大な時間を要することもあります。グローバルスケールのマルチプレーヤー型ゲームデモの目的は、次にグローバルスケールのマルチプレーヤーゲームを構築する際に使用できるガイドラインやアーキテクチャパターン、構成要素を提供することです。

グローバルスケールのマルチプレーヤー型ゲームデモがこれからどのように成長していくか、とても楽しみです。今後の大きな計画として、このプロジェクトを成長拡大させながら、Google Cloud を使用してゲームをホスト、スケールするあらゆる方法を紹介します。

参加をご希望の場合、プロジェクトをご覧になりたい場合は、以下を参照してください。

- カスタマーエンジニア Nikolai Danylchyk
- デベロッパーアドボケイト Mark Mandel

Glance が Google と協力してワンランク上のゲームレコメンデーションエンジンを構築

Mon, 10 Jul 2023 00:00:00 +0000

※この投稿は米国時間 2023 年 5 月 16 日に、Google Cloud blog に投稿されたものの抄訳です。

モバイルゲームは近年人気が沸騰しており、世界中の数十億の人々がスマートフォンやタブレットでゲームを楽しんでいます。InMobi の子会社の Glance は、ロック画面をベースとしたコンテンツ発見プラットフォームとして世界最大級の規模を誇り、アクティブユーザー数は 2 億 2,000 万人を超えます。今や、Glance がもたらす次世代のインターネット体験は、4 億台を超えるスマートフォンでロック画面の使い方を変革しようとしています。Glance は、パーソナライズされたおすすめゲームをユーザーに提案することで、自社のゲームセンターアプリの導入数を伸ばそうと狙っています。現在数百種類のゲームが収録されているこのゲームセンターアプリは、1 か月のアクティブユーザー数が 7,500 万人以上で、ユーザーベースが急速に成長しています。

Glance は当初、全体的なユーザーエクスペリエンスを向上させるため、ユーザーのホーム画面に表示されるゲームを個々のユーザーの好みに合ったおすすめのゲームにすることを喫緊の課題としていました。Glance は Google Cloud に着目し、ユーザーの好みに従ってゲームコンテンツをパーソナライズするレコメンデーションシステムを構築することに決めました。

この投稿では、Glance のゲームレコメンデーションシステムがどのようなもので、このソリューションを構築するために Google のさまざまな AI テクノロジーがどのように実装されたかを詳しく見ていきます。

履歴に基づくデータセット

プライバシーガイドラインに従ってユーザーが任意で Glance に提供した Glance アプリ内の過去のインタラクションから、以下のデータセットを作成しました。

ユーザーメタデータ: ユーザーに関する情報。ユニークユーザー ID、ハンドセットの詳細、メーカーの詳細など。
ゲームメタデータ: ゲームに関する情報。ゲームの名前、バージョン、説明、ユニークゲーム ID など。このデータセットには、ゲームがリリースされている地域、ゲームのカテゴリとサブカテゴリなどの二次情報も含まれます。
ユーザーとゲームのインタラクションデータ: ユニークユーザー ID、ユニークゲーム ID、インタラクションの開始時間と継続時間、ゲームバージョンを捕捉するデータ。

これらの一次データソースは分析と実験にも使用し、最終的にはモデリングにも使用しました。各データセットを時間によってパーティション分割し、実験の精神で 30 日分のデータからソリューションを導き出すこととしました。

データの傾向の特定

セッション継続時間とイベントの回数を対応付けたグラフを観測した結果、2 秒未満のユーザーインタラクションイベントは除外することに決めました。そのようなイベントは意図的でなく偶発的に起こったものである可能性が高かったからです。

もうひとつの興味深い傾向は、セッションの大半が夜に発生していて、その次に多かったのが深夜以降の時間帯だったことでした。

また、予想したとおり、他のゲームよりもセッションインタラクション継続時間の中央値がかなり高いゲームがいくつかありました。

外れ値の取り扱い

作成したインタラクションデータセットで観測されたセッション継続時間の値は、全体的に一様ではありませんでした。そのため、セッション継続時間の分布の両端に外れ値がありました。

前述したように、検討対象とするセッション継続時間は最低 2 秒とし、それより短いセッションは破棄しました。さらに、数理解析により、ある特定の最大セッション継続時間を単一のセッションインタラクションの代表値としました。つまり、これより高い値はすべて誤りとみなしました。

データの分割

使用するデータは 30 日分と決めましたが、レコメンデーションシステムに公平かつ正確にアクセスするため、データの分割方法を決定する必要がありました。

次のようないくつかのアプローチを検討しました。

80/10/10 の比率でランダムに分割する。この方法を採用すると、モデルが未来から傾向を先走って学習し、最終的にデータ漏洩を引き起こす可能性があります。
ユニークゲーム / ユーザーに基づいて層化分割する。これは、協調フィルタリングアプローチのコールドスタート問題につながります。
「最後のワンアウト」戦略に基づいて分割する。つまり、ユーザーがやり取りした（N-1）個のゲームのみを対象とし、最後のゲームはテストデータセット用に確保します。これは時間次元全体にわたるデータ漏洩を引き起こします。
N 週間でデータを層化分割する。実際、私たちは週単位の傾向をいくつか探りました。そのため、最初の N 週間分のデータをトレーニングデータセットとし、その後のデータをテストと検証に使用できます。この分割タイプは「グローバル時間分割」とも呼ばれます。

ゲームの数の方がユーザーの数より少なかったため、すべてのゲームがすべてのデータセットに存在すると考えました。つまり、N 個のすべてのゲームについて、トレーニング / テスト / 検証の各データセットに少なくとも 1 回のユーザーインタラクションがある（つまり、少なくとも計 3 回のユーザーインタラクションがある）とみなしました。

最終的に選択したのは、4 番目のグローバル時間分割アプローチでした。そこで、まずデータを時系列順に並べ、分割間隔を定義して、トレーニング、テスト、評価の分割データセットを作成しました。このようにして時間的データ漏洩を回避し、全ユーザーにわたる傾向が適切に捕捉されるようにしました。

データの前処理

次の論理的ステップは、値をスケールすることでした。ただし、分布の非正規性からどのような形の正規化も行えなかったため、継続時間総計の中央値センタリングをとるアプローチを採用しました。

継続時間総計は、ユニークユーザーとユニークゲームのペアのすべてのセッションにわたる総インタラクション時間を、トレーニング、テスト、評価の分割データセットごとに合計することによって算出しました。

このアプローチでは、トレーニング分布の継続時間の中央値合計を選択し、値をスケールダウンする式でその合計を使用しました。値をスケールすることで、トレーニングするモデルを迅速に収束させることができます。また、中央値より小さい値はすべて負数として変換され、中央値より大きい値はすべて正数として変換されます。

実験およびモデリングアプローチ

このユースケースに最適なソリューションを見つけるため、深く幅広い実験を行いました。実験には、行列分解、Vertex AI による Two-Tower モデリング、TFRS の実装、強化学習などの手法を用いました。

BQML による行列分解 - 行列分解は、レコメンデーションシステムで使用される協調フィルタリングアルゴリズムの一種です。行列分解アルゴリズムは、ユーザーとアイテムの相互作用行列を 2 つの低次元の矩形行列の積に分解することによって機能します。BQML には行列分解機能が最初から組み込まれています。このモデルで必要なことは、モデルを作成してトレーニングを開始する SQL スクリプトを記述することだけです。ユーザーとアイテムの相互作用行列を分解する WALS アルゴリズムは、BQML に実装されています。

これをベースラインモデルとして作成し、ユーザーとゲームの相互作用（インタラクション）ごとのセッション継続時間総計を特徴量としてトレーニングを行いました。

このモデルはかなりうまく機能し、ハイパーパラメータの調整後、テストデータセットと評価データセットについて最高のスコアを記録しました。BigQuery パイプラインにおけるデータの流れを次の図に示します。

Vertex AI Matching Engine を使用した Two-Tower エンベディングアルゴリズム - これは、エンベディングに基づいてレコメンデーションシステムを構築するアプローチです。Two-Tower アプローチは、クエリタワーと候補タワーを使用してそれぞれのタワーに渡すクエリとその関連する候補のエンベディングを生成するランキングモデルです。生成されたエンベディングはベクトルエンベディング空間で表現されます。

エンベディングベースのモデルは、ユーザーとアイテムコンテキストを使用して、豊富な情報を持つエンベディングを共通のベクトル空間に作成します。今回の実験的アプローチでは、ユーザー特徴量とゲーム特徴量をさまざまに組み合わせてエンベディングを構築しました。最も良い結果が得られたのは、ゲームエンベディングにカテゴリが含まれ、ユーザーエンベディングに曜日や時間帯のような時間特徴量が含まれていた場合でした。

これらのエンベディングを作成した後、Vertex AI Matching Engine のインデックスを作成しました。Vertex AI Matching Engine は、業界をリードする大規模で低レイテンシのベクトルデータベース（ベクトル類似度マッチングまたは近似最近傍探索サービスとも呼ばれます）を提供します。たとえば、クエリアイテムを与えると、Matching Engine は大規模な候補アイテムのコーパスから意味的に最も似ているアイテムを探します。

今回はこれを利用して、ブルートフォース検索用のインデックスと近似最近傍探索用のインデックスを作成しました。次に、ドット積やコサイン類似度などのさまざまな距離指標を使用して一連の実験を行いました。その結果、エンベディングモデルをうまく機能させるには追加のモデリングと追加のコンテキストデータが必要という結論に達しました。

TFRS によるカスタムモデリング - TensorFlow Recommenders（TFRS）は、レコメンダーシステムのモデルを構築するためのライブラリです。TensorFlow を基盤としており、レコメンダーシステムの構築、トレーニング、デプロイのプロセスを効率化します。

このアプローチのために構築した TFRS リトリーブモデルは、クエリモデル（UserModel）と候補モデル（GameModel）の 2 つのサブモデルで構成されていました。前者はクエリ特徴量を使用してクエリ表現を計算し、後者は候補特徴量を使用して候補表現を計算します。これら 2 つのモデルの出力を使用して、クエリと候補のアフィニティスコアを算出しました。スコアが高いほど、候補とクエリの一致度が高いことを示します。Vertex AI による Two-Tower アプローチと同様に、さまざまなユーザー特徴量とゲーム特徴量を定義してエンベディングを作成する実験を繰り返し、Vertex AI Matching Engine のインデックスを作成しました。

最良の結果と一般化が認められたのは、ユーザー特徴量のみを考慮し、ゲーム特徴量は考慮しなかった場合でした。ゲームについてはユニークゲーム ID のみを使用し、この ID をある特定のゲームをベクトル空間に埋め込むための参照としました。分析には、上位 K 個のおすすめゲームを提示するブルートフォースのインデックスを使用しました。ブルートフォースを使用したのは、探索空間が限られていたためです。

コンテキストバンディットによる強化学習 - TF-Agents によって実装した多腕コンテキストバンディットアルゴリズムを実装しました。多腕バンディット（MAB）は、エージェントが長期的に見て累積的報酬が最大になるアクション（アーム）を選ぶことを要求される ML フレームワークです。各ラウンドで、エージェントは現在の状態に関する情報（コンテキスト）を受け取り、この情報とそれまでのラウンドで得た経験を基にアクションを選択します。各ラウンドの最後に、選択したアクションに対応する報酬がエージェントに与えられます。

このアプローチでは、アームあたりの特徴量を含む多腕コンテキストバンディット（MACB）モデリングを利用しました。つまり、学習エージェントは、それぞれ固有の特徴量を持つ「アーム」のひとつからゲームを選択できます。これにより、ユーザーとゲームコンテキストがニューラルネットワークを通じて埋め込まれるため、一般化に役立ちます。

この方法では、コンテキストは BQML 行列分解モデルから取得しました。エージェントのアルゴリズムには、探索係数を事前に指定した Epsilon Greedy アルゴリズムを採用し、モデルが他のアームを探索しながら確実に傾向を学習できるようにしました。

このモデルは、100 万のユニークユーザーのサブセットでしかトレーニングされなかったことを考えると、驚くほど良好な結果をもたらしました。限られたトレーニングサンプルから卓越した一般化可能性を獲得し、計 1,900 万のユニークユーザーのコンテキスト空間を理解してマッピングすることができました。

このモデルは今回のプロジェクトにおいて比較的優秀な成績を上げたもののひとつで、準最適アーム指標やリグレット指標のようなモデル指標を最適化することを狙いとしていました。MACB の実験では、次のアプローチに従いました。

実験の指標

上記のすべての実験において、以下の 4 つの指標を計算しました。

K での平均適合率の平均（MAP）
K での正規化減価累積利得（NDCG）
平均ランク
平均二乗誤差

上記の「K」は、おすすめとして提案される結果の数を表します。実験の際、K の値は 5、10、およびすべてとしました。

これらの指標に基づき、異なるモデリング手法の間でモデルをランク付けしました。ただし、これら 4 つの指標の中で特に注目したのは、MAP と NDCG の値を比較することでした。その理由は、これらの指標が目下の課題をより的確に表しているためです。

結果と観察

最良のモデルでは、以前に使用していたベースラインモデルよりも成績が大幅に向上しました。最も成績が良かったモデルは BQML 行列分解モデルで、2 位はコンテキストバンディットモデル、3 位は Vertex AI Two-Tower、最後は TFRS アプローチでした。エンベディングベースのモデルの成績が芳しくなかったのは、与えられたデータセットに、特定のユーザー属性の特徴量が含まれていなかったためです。また、K の値を増やすとモデルの成績も向上しましたが、これは予想された挙動でした。

これらのモデルの運用化とスケーリングのアプローチを検討した Glance のチームは、まず新しいモデルをごく一部のトラフィックに対してデプロイし、A/B テストの要領でエンゲージメント指標を対照トラフィックと比較しました。このデプロイメントは、出力のレイテンシを低く抑え、ユーザーエンゲージメントの背後にある主な要因をより深く理解するために、調整が加えられました。モデルが良好な成績を示した後、Glance は、必要に応じてモデルをデプロイするトラフィックの割合を広げるため、さらなる費用最適化が図れるような体制を整えました。

このプロジェクトの後、Glance のチームは BQML 行列分解モデルを本番環境に実装することを決定し、その結果、暫定的ながら、ユーザーが Glance のプラットフォーム上にあるゲームとのやり取りに費やす時間は増加しました。

Google Cloud AI サービス（AIS）によるエンドツーエンドの迅速な導入

Google Cloud と Glance のパートナーシップは、お客様が望ましい成果を上げられるよう支援するために、Google が複雑な問題を解決する AI 搭載ソリューションをどのように提供しているかを示す最新の例のひとつです。Google Cloud の AI サービスについて詳しくは、AI と ML のプロダクトページをご覧ください。

Glance のゲーム部門でデータサイエンスのコンサルタントを務める Paul Duff 氏は、ほんの数週間で本番稼働可能なモデルを作り上げた Cloud AIS と BQML のようなすぐに使えるプロダクトにいかに満足しているかを強調し、次のように述べています。「Google のチームは、Glance のゲームセンターアプリのオフラインのレコメンデーションシステムを開発するという合意された目標をはるかに超え、すべてのマイルストーンを納期どおりに、あるいは納期より前に達成し、4 種類の詳細に文書化されたワーキングモデルを提供してくれました。私たちは（合意されたプロジェクト範囲を超えて）その中で最も優秀なモデルを本番環境に導入し、プロジェクト終了日の前に主要な指標が上昇したことを確認できました。チームの体制は、プロジェクト全体を通して優れたコミュニケーションの模範となるものでした。」

^{プロジェクト全体にわたって支援・指導していただいた Naveen Poosarla 氏と Charu Shelar 氏に深く感謝いたします。このプロジェクトを成功に導くために共に尽力してくれた Glance のチーム（Gaurav Konar 氏、Rohit Anand 氏、Rohit Kalyan 氏）と Wipro および Capgemini のパートナーチーム（Tulluru Durga Pravallika 氏、Viral Gorecha 氏）の皆様に感謝します。そして、我らが偉大なるリーダー Nitin Aggarwal に大きな感謝を捧げます。}

^{免責条項: このブログで発信する情報は、プロダクト使用状況指標に関連するデータの特定のサブセットに関する有益な情報を提供することを目的としています。ここで提示した結果は必ずしも全体的なプロダクト使用状況指標を反映しているとは限りませんのでご注意ください。}

- Glance、InMobi、コンサルタント、データサイエンス Paul Duff 氏
- Google Cloud、AI エンジニア Gopala Dhar

GKE や Open Match、Agones を使用したマルチプレーヤー型 Google Doodle ゲームの構築

Thu, 20 Apr 2023 00:00:00 +0000

※この投稿は米国時間 2023 年 4 月 4 日に、Google Cloud blog に投稿されたものの抄訳です。

はじめに

Google 検索ホームページを訪問した人は誰でも、検索バーの上に表示されるロゴが、独創的で楽しくて目を引くようなものに変わることがあると気づいたはずです。それは「Google Doodle」と呼ばれています。

近年は、対話型だけでなく、マルチプレーヤー型も見かけるようになりました。Google ホームページを閲覧した人は誰でも、同じページを閲覧している他の 1 人以上のユーザーとゲームを楽しむことができます。しかし、こんな疑問が湧いてきます。「世界中にいる Google ユーザーに楽しまれているこれらのゲームを動かすために、どんな技術が背後では使われているのだろう？」「同様のエクスペリエンスを作りたいと考えている読者も、これらの技術を使用できるのだろうか？」

今回は Jacob Howcroft にインタビューしたいと思います。Jacob は、7 年前から Google Doodle チームでソフトウェアエンジニアを務めており、Google Doodle チームがマルチプレーヤー型 Google Doodle エクスペリエンスに挑戦する取り組みをリードしてきました。

Google Doodle とは何ですか？

Jacob: Google「Doodle」は、地域の文化や世界の文化に影響を与えたりそれらを形成したりした、さまざまな祝日、個人、場所、モノなどをお祝いするために変更された Google のロゴです。当初の Doodle は静止画イラストでしたが、今ではゲームやその他の対話型エクスペリエンスも制作するようになりました。

マルチプレーヤー型 Google Doodle とは何ですか？

Jacob: プレーヤー同士をつなげる対話型エクスペリエンスです。これによって、友人やオンライン上の無作為のユーザーとつながることにより、一緒にプレイすることができます。ブラウザやモバイルデバイスで google.com にアクセスして、Google ロゴが「再生」ボタン付きのものに変わっているのを見つけた場合、それをクリックするとマルチプレーヤー型ゲームに移動します。

2022 年のハロウィンにリリースされたマルチプレーヤー型 Google Doodle

最近リリースされたマルチプレーヤー型 Google Doodle とはどのようなものですか？また、その後どうなりましたか？

Jacob: 最初のマルチプレーヤー型 Doodle は、2018 年のハロウィンにリリースされた The Great Ghoul Duel でした。これまでで最も人気のある Doodle の一つになったので、2022 年のハロウィンに The Great Ghoul Duel 2 をリリースしました。また、2022 年 7 月に Celebrating Pétanque もリリースしました。ペタンクというフランスのスポーツを祝うマルチプレーヤー型ゲームです。

The Great Ghoul Duel 2（2022 年）

Celebrating Pétanque

大勢の人がペタンク Doodle とハロウィン Doodle をプレイしました。特にハロウィンは、プレーヤーの多くが何ラウンドもプレイしてくれました。「The Great Ghoul Duel」は、Twitter 上と Discord 上にファンコミュニティがあり、2018 年から活動を続けています。もちろん、彼らは続編を見てとても喜んでいました。

Google ホームページ用のマルチプレーヤー型ゲームをリリースするうえでの課題は何ですか？

Jacob: 最大の課題はスケーリングに備えることです。Google 上ではユーザーによって毎日何十億件もの検索が行われています。そのようなユーザーにゲームを提供しているため、リリース直後に膨大な数のプレーヤーを処理する必要があります。おまけに、これらのゲームは数時間のうちに世界中にリリースされるため、大急ぎでスケールアップする必要があります。Doodle はサプライズですから、ベータリリースでテストすることはできません。つまり、QA、負荷テスト、内部テストプレイを非常に厳密に行う必要があるということです。

マルチプレーヤー型 Google Doodle にはどれくらいの数のプレーヤーが参加しますか？

Jacob: Doodle がホームページ上にある間に、ユーザーは何百万回もプレイします。ホームページ上で Doodle が動作した後で google.com/doodles アーカイブを見ると、毎日何千ものゲームがプレイされています。

ブラウザベースのゲームと他の種類のマルチプレーヤー型ゲームにはどんな違いがありますか？

Jacob: モバイルゲーム、コンソールゲーム、PC ゲームは通常 UDP を使用するのに対して、JavaScript や TypeScript で作成されたブラウザベースのゲームでは WebSocket プロトコルを使用することが主な違いです。WebSocket プロトコルを使用すると、GameServer ごとに HTTPS / Web Socket Secure（WSS）用の証明書が必要になるのですが、これが課題になります。ゲームは HTTPS ページ上で動作します。ということは、すべての WebSocket 接続もセキュリティで保護されている必要があるのです。これを行うには、従来の UDP マルチプレーヤー型ゲームの接続のときのように IP やポートに直接接続するのではなく、ゲームサーバー用の DNS アドレスも必要です。

これらのマルチプレーヤー型 Doodle ゲームをどのように作ったのかを教えてもらえますか？

さまざまな Google Cloud プロダクトを使用したり、無料で入手可能なゲームインフラストラクチャや分散システムのオープンソースプロジェクトを利用したりしています。ゲーム自体には、何年にもわたって Doodle 用に作成してきた数多くの TypeScript ツールやライブラリだけでなく、PIXI などの一部のオープンソースエンジンも使用しています。

どんな Google Cloud プロダクトを使用しましたか？

Jacob: Google Kubernetes Engine（GKE）がほとんどすべてを実行しています。

マッチメーカーとゲームサーバークラスタのグローバルなロードバランシングを処理するために外部 HTTP(S) 負荷分散の Ingress を利用しています。

Redis Memorystore は、ゲームサーバーのルーティングを構成し、マッチメーカーのマッチメイキングチケットを保存するために使用されています。

Google マネージド証明書を使用することで、マッチメーカーとゲームサーバーの SSL 証明書の自動作成とローテーションが可能になっています。これは手動での証明書の処理をなくしてくれたため、非常に助かりました。

Cloud Logging、Cloud Monitoring、ログベースの指標を使用することによって、ゲームサーバーのステータスやマッチメイキングチケットの数などの指標を調査して本番環境を監視するダッシュボード一式が手に入りました。

Cloud Run と Cloud Endpoints がマルチクラスタゲームサーバー選択システムを動かしています。このシステムは、GKE クラスタのセットの中からプレーヤーに適切なゲームサーバーインスタンスを選択し、それらのゲームサーバーを「割り当て済み」としてマークします。基本的に、これらのゲームサーバー上でプレーヤーがプレイするため、中断は許されません。詳細については後述しますが、マルチクラスタアロケータシステムがスケーリングの大部分を支援してくれました。

バックエンドにオープンソースプロジェクトを使用することにした理由は何ですか？

Jacob: 私たちは主にフロントエンドチームで、ウェブ用のコンテンツやフロントエンドサーバーを構築しています。Google Cloud や Kubernetes などのより深いバックエンドテクノロジーのこととなると、専門外です。ただし、入手可能なオープンソースシステムがこのスキルギャップを埋めてくれるため、専門領域外の作業も可能になり、より複雑なエクスペリエンスを構築することができます。

どのオープンソースプロジェクトを利用しましたか？

Jacob: 2018 年の最初のマルチプレーヤー型 Doodle ではゲームのプレーヤーを仲介するために Open Match を利用しました。これが非常にうまく機能したため、新しいマルチプレーヤー型ゲームスタックでもその使用が継続されました。

Agones は、GKE クラスタ上にインストールされ、ゲームサーバーをホストしてスケールし、プレーヤーのプレイ中に中断が起きないようにしています。Agones は、GKE クラスタ内で実行中のゲームサーバープロセスのタイプと数を宣言するのに使用できる、GameServer と Fleet のカスタムリソース定義を提供してくれます。また先ほど述べたように、ゲームサーバーを選択して割り当て、それらのプレーヤー接続の準備が整ったことについてマークできるのも、Agones のおかげです。私たちは、世界中で複数の GKE クラスタと Agones クラスタを実行することによって、ほぼすべての潜在的プレーヤー（Google.com のユーザー全員）のためのゲームサーバーを確保しています。

また、これらがすばらしいソリューションであるだけでなく、Google Cloud が Open Match と Agones の両方を設立し、それぞれのコミュニティの支援を得てこれらのプロジェクトを維持し続けているということから、自分たちは恵まれた環境にいて、助けを求めることができる相手が身近にいることがわかりましたし、実際に助けてもらいました。

また、マッチメイクされたプレーヤーによる、GKE クラスタにホストされた特定の Agones GameServer Pod への WebSocket 接続を調整するために Traefik Proxy を使用して、プレーヤーたちが一緒にゲームをプレイできるようにしています。

開発ツールと運用ツールについて言えば、インフラストラクチャのプロビジョニングに Terraform を使用し、すべての GKE クラスタへのオープンソースツールとカスタムコンポーネントのデプロイの調整に Helm と Helmfile を使用しています。

最終的に作成したカスタムコードの量はどれくらいですか？

Jacob: 皆さんが思うほど多くはありません。

Open Match では、マッチ関数用のいくつかのカスタムコンポーネントを作成し、Agones などの外部システムと統合する必要がありますが、gRPC の相互運用性のおかげで、Open Match が Go で作成されていても、そのすべてを Node.js で作成することができました。WebSocket ベースのゲームサーバーも Node.js で作成しました。これには、クライアントとサーバー間でコードを共有し、開発時間を短縮できるというメリットがあります。

Traefik ルートを構成するためのカスタム Kubernetes コントローラも作成しました。Traefik は、特定のキー形式に作成することによって、Redis からの構成を検出するようにセットアップできます。作成されたコントローラは、Agones GameServer イベントを監視し、イベントが発生したときにそのイベントの名前、Pod IP、ポートを Memorystore に書き込みました。Traefik はそのルーティングを動的に更新するので、wss://<project subdomain>.cloud.doodles.goog/<ゲームサーバー名> を使用して GameServer にアクセスできます。

マッチメイキングと、プレーヤーのグループに対するゲームサーバーの割り当てに関するアーキテクチャを順を追って説明してもらえますか？

マルチプレーヤー型 Google Doodle のアーキテクチャの概要

Jacob: まず、プレーヤーがグローバルマルチクラスタ Ingress HTTP(S) ロードバランサに接続します。そこでプレーヤーは、世界中に分散した GKE クラスタにホストされているマッチメーカーフロントエンドのうち、最も距離が近いものにルーティングされます。通常は、このようなクラスタを 1 つの大陸に 1 つか 2 つ置いています。

マッチメーカーフロントエンドを通して、チケットが Open Match 内で作成され、他のプレーヤーとマッチされます。

Agones Fleet が新しい GameServer を開始すると、カスタム Agones-Traefik コントローラがその Pod IP を Memorystore Redis インスタンスに書き込みます。Traefik Proxy がそのインスタンスから読み取って、先ほど述べたとおり、クラスタ内でルートをセットアップします。こうして、プレーヤーは “wss://cluster.game.cloud.doodles.goog/foo” などの URL で GameServer “foo” に接続します。

Node.js で作成された Open Match Director コンポーネントは、マッチを受け取り、Cloud Run を活用した Agones マルチクラスタ割り当てサービスを使用して GameServer を割り当てます。各マッチメーカークラスタは 1 つ以上の GameServer クラスタから割り当てられます。

私たちは負荷テストの実施中に、最適な GameServer Fleet（GameServer のグループ分け）サイズは主に Kubernetes のコントロールプレーンによって制限されるということに気づきました。そのため、処理可能なサイズは、配分率、ゲームサーバーアクティビティの量、およびコントロールプレーンサイズによって決まります。通常、Google のゲームセッションは非常に短いため、そのターンオーバーごとに Kubernetes API に大きな負荷がかかります。

もともとは、クラスタごとに Open Match マッチメーカーのインスタンスと Agones GameServer Fleet が存在していました。ところが、GameServer クラスタの最適なサイズが約 6,000 台の Agones GameServer であることがわかったため、マッチメーカークラスタと GameServer クラスタ用の 1 対多のアーキテクチャによってスケールアップが可能になりました。これは、クラスタの数が多いほど、全体のスループットが上がるためです。

GameServer の割り当てに成功したら、マッチメーカーが GameServer の URL を使用してプレーヤーに返信します。プレーヤーは別の Ingress を介してそれに接続し、Traefik Proxy がその要求を適切な GameServer に転送します。

ゲームセッションの終了時点でゲームサーバーをシャットダウンせずに、Agones SDK を介してゲームサーバーをリセットして「準備完了」状態に戻すことによって、新しいゲームに割り当てることができます。これにより、GameServer のターンオーバーが減少し、Kubernetes API と Traefik Proxy の負荷が軽減されます。

通常は、グローバルプレーヤーベースをサポートするのに、1 つの Open Match インスタンスが推奨されています。リージョンごとにインスタンスを用意した理由は何ですか？

Jacob: Open Match がグローバルプレーヤーベースを処理できることは知っていましたが、リージョンごとに別々の Open Match インスタンスを使用しました。これは、トラフィックを最も近いマッチメーカーに転送するのにロードバランシングを利用できるようにするためです。本当に大きなプレーヤーのプールがあったために、プレーヤーベースのシャーディングを気にする必要がありませんでした。マッチメーカーごとに十分な量が確保されていたのです。

リリース前にベータ版をテストするという選択肢はなかったので、世界中で Open Match のインスタンスを増やすことで、リリース日のリスクを軽減し、必要に応じて Open Match インスタンスとその背後の Agones クラスタを水平方向にスケールすることができました。

WebSocket ベースの通信について詳しく説明してもらえますか？なかなか扱いづらそうですよね。

Agones GameServer Pod への WebSocket 接続

Jacob: WebSocket ゲームには、Web Socket Secure（WSS）が必要です。これは、すべての GameServer を URL でアドレス指定し、すべての GameServer に SSL 証明書を設定する必要があることを意味します。何千台もの GameServer の動的 Fleet に対してこれを実現するには、これまでにない解決策が必要でした。

Halloween 2018 Doodle では、サブドメインごとに GameServer にルーティングして何千もの DNS エントリを静的に生成していました。ただしこのアプローチでは、Agones と GKE の動的でスケーラブルな機能のすべてを利用することはできませんでした。

そのため、新しいセットアップでは、Traefik Proxy を導入しました。これを選択した理由は、さまざまなプロバイダを使用してルートを動的に構成できるからです。そのうちの一つが Redis です。そして、GameServer の監視や、Redis への構成の書き込みを行う Kubernetes コントローラを作成しました。プロキシがプレーヤーの ping にどう影響するかが懸念されましたが、負荷テストを重ねた結果、目立った影響がないことがわかりました。このセットアップによって Fleet を動的にスケールできるようになりました。新しい GameServer のスピンアップができ次第、DNS エントリを操作しなくても、すぐに接続で使用できるようにもなりました。

また、クライアント上の Google Closure WebSockets とサーバー上の ws を使用して、WebSocket ライブラリを作成しました。ゲームごとに、プロトコルバッファ（クライアントからサーバーへのメッセージとサーバーからクライアントへのメッセージ）を使用して API を定義します。通常はこのメッセージに、ゲーム内のさまざまなアクションごとに異なるサブメッセージタイプのための oneof フィールドが含まれています。ライブラリは TypeScript ジェネリスクを使用して、ゲームコードが必ずこの API を通してメッセージを送受信するようにします。

ゲームを間違いなく面白いものにすることはすべてのゲームにとって欠かせないことですが、これをどのようにテストしましたか？

Jacob: 面白いかどうかをテストする方法はいくつかあります。1 つ目の方法は、週 1 回のチームテストプレイです。Doodle チーム全員が一堂に会して最新のデモをプレイし、フィードバックやアイデアを共有します。2 つ目の方法は、内部ユーザーテスト、いわゆる、「カフェテスト」です。数人の Google 社員をランダムに選んだり、ミニキッチンにスタンドを設置したりして、リアルタイムでフィードバックを収集します。Google 社員の多くがとても率直に意見をくれるため、この方法で良好な結果が得られます。最後に、バックグラウンドやゲームに対する馴染み方が異なる外部ユーザーによるロケーションテストをセットアップします。このロケーションテストによって、最終製品に向けて非常に貴重で多様な視点が得られます。

Google のフロントページでは、その種のトラフィックの負荷テストをどのように行いますか？

Jacob: 初期段階で最初にやることは、ヘッドレスゲームクライアントを作成することです。これは UI を操作することなく、スクリプトによってゲームをプレイできることを意味します。次に、ユーザーをシミュレートする、ノードベースの負荷テスト用クライアントを作成します。

Kubernetes Job を使用して、何千ものこれらの偽ユーザーを GKE にデプロイし、クラスタに指定します。少人数のユーザーから始め、クラスタがそれを適切に処理したら人数を増やします。なんらかの問題が発生するまでこのプロセスを繰り返します。

その後、問題をデバッグして修正し、もう一度やり直します。このプロセスを通して、Agones クラスタに最適な Fleet サイズを見つけることができました。それが、約 6,000 台の GameServer でした。この数値は Kubernetes プロバイダ、マッチのサイズ、ゲームの持続時間、その他の要因によって異なります。すべてのケースに当てはまるわけではないのでご注意ください。

負荷テストのトラフィック量はどのように見積もりましたか？

Jacob: 過去のゲームの指標を調査し、それを使用してこのゲームのトラフィックを推定しました。ただし、さまざまな要因で大きく変化する可能性があるため、目標をできるだけ高くする必要があります。それでも、ピーク時のトラフィックが非常に高かったため、リリース中に追加のクラスタをデプロイすることになりました。

本番環境にデプロイする準備が整ったのはいつでしたか？それはどのように実現しましたか？

負荷テストおよび過去の Doodle パフォーマンスの分析を通して、おおよそのスケールを把握してから、Fleet 全体を Terraform と Helmfile で定義し、デプロイしました。Doodle は世界各地の現地時間に従ってロールアウトしていくため、トラフィックは約 24 時間で急速に増えると予想し、計画を立てました。

すべてのリソースを自動スケールしたのですか、それとも、静的なインフラストラクチャを維持しただけですか？

Jacob: 運用保守を簡単にするため、スケールダウンを避けたい場合は別にして、GKE ノードプール上でノードの自動スケーリングを有効にしました。WebSocket の接続時間が長かったため、ノードのターンオーバー時に移動する Pod の量を減らす必要がありました。Kubernetes デプロイに自動スケーリングを使用することはあまりありませんでした。短時間に大量のトラフィックを受信することがわかっていたため、事前に高レベルまでスケールしておいて、短いリリース期間に手動で調整することにしました。全体のゲームリリースに対して 100% の容量で稼働したため、Agones Fleet 自動スケーリングも使用しませんでしたが、kubectl scale fleet halloween --replicas=N を実行することによって、Agones Fleet のサイズを簡単に変更できるという機能は活用しました。ノードの自動スケーリングを使用すると、クラスタが自動的に Fleet に合わせてサイズを変更します。

用意した GKE クラスタは何個で、それらをどのように管理しましたか？

Jacob: 最新のゲーム（Halloween 2022）では、30 個のクラスタを用意しました。平均で、マッチメーカークラスタあたり 3～5 個の GameServer クラスタを用意しました。これらのクラスタのすべてを管理するには、Terraform と Helm を使用して、それらのループコンストラクトを利用する必要がありました。これにより、何百にも及ぶはずだった構成ファイルの行を、数十行にまで減らすことができました。

Cloud Monitoring を使用したということでしたが、積極的にモニタリングしたものは何ですか？

Jacob: システム全体のさまざまな指標をモニタリングしましたが、その中でも特に重要なものを紹介します。

状態ごとの GameServer の数を示す Agones Fleet ステータス用のダッシュボードを用意しました。特に「準備完了」と「割り当て済み」の状態はチェックしていました。これにより、Fleet が最大容量に達する時期を知ることができました。リリース期間が約 48 時間しかなかったため、アラートをセットアップせずに、ずっと待機していることにしました。ただし、google.com/doodles アーカイブ上で動くゲームについては、エラー率に基づいたアラートをセットアップしました。

ゲームサーバーとマッチメーカーの接続もモニタリングしました。特にマッチメーカーに関してモニタリングしたのは、マッチの成功率です。マッチの成功率はユーザーエクスペリエンスにおける第一の指標だったので、モニタリングは欠かせませんでした。マッチの失敗は、ユーザーが一番がっかりする出来事です。もう一つの重要な指標は、マッチに参加するプレーヤーの数が十分になるまでユーザーが待機している時間です。幸い、トラフィックが非常に高かったため、この点を心配する必要はありませんでした。

独自のカスタム「ゲームオーバー」イベントを追跡しました。終了したゲームの累計の調査はとてもワクワクするものでした。この調査を行うにあたり、マッチメーカー接続数、作成した Open Match コンポーネントでの成功数と失敗数、ゲームサーバー接続数などの、カスタムのログベースの指標を合計するグラフを作成しました。

最後に、Agones と Open Match のすべての組み込み指標を利用して、プラットフォーム全体の健全性を概観しました。

8 Google Doodle games.jpg

Cloud Monitoring チャート: 総ゲームサーバー数
6 Google Doodle games.jpg

Cloud Monitoring チャート: マッチメーカー接続数
7 Google Doodle games.jpg

Cloud Monitoring チャート: ゲームサーバー接続数

やり直せるとしたら、別の方法で取り組みたい点はありますか？

Jacob: 教訓の一つは、想定したトラフィックを処理するために割り当てを倍以上用意する必要があったことです。システムの設計は、リリース中に新しいクラスタをオンラインにすることがとても簡単にできるようになっています。実際に使ってみて、厳しい時間の制限がある中でのスケールアップで大変重宝しました。ただし、一部のリージョンで割り当てが十分ではなかったため、Blue/Green デプロイ（古いバージョンから切り替える前に新しいバージョンのデプロイ全体を実行すること）を完了できませんでした。つまり、リリース中にインフラストラクチャを変更する場合はダウンタイムを設ける必要がありました。これは、割り当てに十分な空きを作ることによって回避できます。したがって、何かをリリースする際は、Google Cloud 顧客アカウント担当者と連携して、割り当て量の確認も含めたフルリリースレビューをリリース日より十分前もって行うことをおすすめします。

さらに、特定のリージョンで Agones GameServer を増やすことができない場合に、マッチメイキングおよびゲームサーバーオーケストレーションシステム全体を別のリージョンに適切にスピルオーバーさせることも簡単ではありませんでした。つまり、リリース中は、予想されるピーク時の負荷を考慮し、各 Open Match インスタンスに十分な数の GameServer のバックアップを用意する必要があったのです。リリース中のカスケード障害は回避しましたが、その代わり、最もビジーなクラスタを手動でスケールアップする必要がありました。

順を追って説明すると、ユーザーがマッチメイキングフロントエンドに接続して、マッチへの参加を要求します。ユーザーは十分な数のプレーヤーが揃うまで待機します。それから割り当て要求が Agones に送信されます。ただし、すべての Agones クラスタがいっぱいの場合は、エラーが返されます。この時点で、すでに、何千人ものプレーヤーがマッチへの参加を試みているかもしれません。しかしそれらの行き場がないため、すべてのマッチメイキング要求が失敗します（すでに 100% の容量で稼働しているのです）。さらにそこへ新しいユーザーもマッチメイキングシステムに接続してくると、そのすべての要求も失敗し、マッチメイキングクラスタのカスケード障害につながります。Fleet が割り当て量の一定のしきい値を超えたということがわかったら、早めにマッチメイキングシステムによる新しいマッチメイキング要求の受け付けが停止するのが理想です。

今後、このような状況により適切に対応するためには、各 Open Match インスタンスの背後にある Fleet に関する最新データを把握するためのフロントエンドが必要です。これにより、クライアントが過負荷になる前に別のインスタンスを使用するように指示することができます。Fleet が上限に達したことをアロケータサービスから報告された時点では、すでに問題が発生している可能性があります。

マルチクラスタゲートウェイへの切り替えも検討しています。これにより、レート制限を構成できるようになります。そうすれば、クラスタの最大容量に基づいて最大 QPS を計算し、それに応じてレート制限を設定して、GCP にスピルオーバーを処理させることができます。このソリューションはやや動的さに欠けますが、実装は非常にシンプルなものになります。

まとめ

Google Doodle チームがマルチプレーヤー型 Google Doodle ゲームの開発、ホスティング、スケーリング、オーケストレーションを行った方法について詳しく説明してくれた Jacob に感謝します。

Google Doodle チームは Google Cloud（特に、Google Kubernetes Engine）とオープンソース Google Cloud Gaming のソリューションを組み合わせることにより、歴代のマルチプレーヤー型 Doodle を Google 検索と同じ規模で運用することに成功してきました。これは本当にすばらしいことです。

また、Google Cloud のマルチプレーヤー型ゲーム向けのオープンソースソリューションを利用しながら、比較的わずかなカスタムコードでこれほどの包括的なマルチプレーヤー型ゲームプラットフォームを構築できたことは、まさに驚くべきことです。

上述のソリューションのいずれかにご興味をお持ちの場合は、以下にアクセスして詳細をご覧ください。

これまで Google が何十年にもわたって世界中でリリースしてきた 5,000 を超える Google Doodle を見てみたくありませんか？ぜひ google.com/doodles にアクセスしてお楽しみください。

- Google Doodle、シニアソフトウェアエンジニア Jacob Howcroft
- Google Cloud、デベロッパーアドボケイト Mark Mandel

GKE Autopilot でゲームインフラストラクチャを実行して、プレーヤーエクスペリエンスに集中する

Fri, 31 Mar 2023 03:20:00 +0000

※この投稿は米国時間 2023 年 3 月 22 日に、Google Cloud blog に投稿されたものの抄訳です。

Google は今月初めに、ライブサービスゲームに関する Google Cloud の戦略を発表しました。この戦略では、（1）場所を問わずプレーヤーにサービスを提供する、（2）ゲームデータを収集して整理する、（3）プレーヤーとゲームのインサイトを引き出す、という 3 つの重要な柱に重点が置かれています。このたび、Google Kubernetes Engine（GKE）Autopilot 上でゲームワークロードを実行できるようになりました。これは、グローバルマルチプレーヤーゲームサーバーの実行における真の意味で自動化されたエクスペリエンスです。このブログ投稿では、GKE Autopilot を使用して世界中のプレーヤーにサービスを提供する方法について説明します。

プレーヤーは、ゲームが確実に動作することを期待しています。ゲームデベロッパーは、運用が簡単で、プレーヤーのトラフィックに合わせてシームレスにスケールできる、基盤となるクラウドインフラストラクチャを備えなければなりません。これにより、ゲームデベロッパーは本当に重要なこと、すなわち優れたゲームの構築に集中できます。Google Cloud は、GKE Autopilot をゲームワークロードの実行に最適なプラットフォームにし、スケーラビリティ、信頼性、自動化を実現することで、ゲームを簡単にリリースできるようにすることに注力しています。

マルチプレーヤーゲームの最も重要なコンポーネントの一つは専用のゲームサーバーです。これは、ゲームの状態に関する信頼できる情報源であり、プレーヤーのクライアントがゲームの世界とやり取りするために接続するものです。この専用のゲームサーバーは、ゲームセッション中に稼働し続け、多くの接続を処理し、同時プレイヤー数などの指標に基づいてスケールされる必要があります。

グローバル規模のゲームアーキテクチャの例

このたび、Agones を使用して、GKE Autopilot 上で専用のゲームサーバーを実行できるようになりました。Agones は、ゲーム業界と共同で開発したオープンソースのゲームサーバーオーケストレーターです。GKE Autopilot でゲームサーバーを実行する場合、Google Cloud がクラスタを管理し、実行中にゲームサーバーが要求した CPU、メモリ、ストレージに対してのみ料金が発生します。ゲームサーバーのスケジュールがどのようなものであれ、未割り当てのノードやシステムのオーバーヘッドに対して料金を支払う必要はありません。

「私たちは Google Kubernetes Engine を使用して専用のゲームサーバーを実行しており、クラスタの運用費用に気を配っています。Agones を使用して GKE Autopilot 上でゲームサーバーを実行できることを嬉しく思っています。Kubernetes ノードプールを管理する必要がなくなり、支出を拡大することなくゲームサーバーとチームをスケールできるからです。」- DeNA、ソフトウェアエンジニア Hiroki Awata 氏

パワーアップ: GKE Autopilot 上のゲームサーバー

ゲーム向け GKE Autopilot の使用を開始するには、まず GKE Autopilot クラスタを作成します。次に、UDP プレーヤートラフィックを許可するファイアウォールルールを作成し、Helm を使用して Agones をインストールします。

code_block: <ListValue: [StructValue([('code', 'gcloud container clusters create-auto agones-autopilot \\\r\n --region=us-central1 \\\r\n --autoprovisioning-network-tags=game-server'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa3a8dc4af0>)])]>

GKE Autopilot は Kubernetes であるため、Kubernetes クラスタに適用するのと同じフリート構成 yaml を使用してゲームサーバーフリートを作成できます。

code_block: <ListValue: [StructValue([('code', 'apiVersion: "agones.dev/v1"\r\nkind: Fleet\r\nmetadata:\r\n name: simple-game-server\r\nspec:\r\n replicas: 5\r\n template:\r\n spec:\r\n ports:\r\n - name: default\r\n containerPort: 7777\r\n template:\r\n spec:\r\n containers:\r\n - name: simple-game-server\r\n image: us-docker.pkg.dev/agones-images/examples/simple-game-server:0.14'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa373f52520>)])]>

ゲームサーバーの実行に必要なノードとノードプールの数や、クラスタオートスケーラー構成について考える必要がないことに注目してください。実行するゲームサーバーの数を定義するだけで済むので、簡単です。

成功に向けて: 人による操作が不要なインフラストラクチャ

GKE Autopilot は、構成やモニタリングを必要とせずに、クラスタの基盤となるインフラストラクチャを管理できる、人による操作が不要なフルマネージド Kubernetes プラットフォームであるため、専用のゲームサーバーの実行に最適です。Google SRE に裏付けられたワークロードレベルの SLA を享受できます。GKE Autopilot で Agones FleetAutoscaler を使用することにより、プレーヤーがゲームに出入りするのに合わせて、グローバルゲームサーバーフリートが自動かつ動的にスケールされます。設定しておけば、何もする必要はありません。

code_block: <ListValue: [StructValue([('code', 'apiVersion: "autoscaling.agones.dev/v1"\r\nkind: FleetAutoscaler\r\nmetadata:\r\n name: simple-game-server-autoscaler\r\nspec:\r\n fleetName: simple-game-server\r\n policy:\r\n type: Buffer\r\n buffer:\r\n bufferSize: 2\r\n minReplicas: 5\r\n maxReplicas: 100'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa373f97b50>)])]>

従来の Kubernetes では、こうしたスケーリングを行うために、計画、適切なサイジング、ビンパッキングのためのリソースと時間が必要でした。スケールアップを見越してはるかに早い段階でノードプールをオーバープロビジョニングし、スケールダウンするまでそのノードプールを長く実行し続けることもできましたが、そのすべてに費用がかかっていました。

ゲームサーバーは Pod であり、Autopilot は Pod 単位で対話するため、GKE Autopilot を使用したゲームサーバーのスケーリングは理にかなっています。Autopilot では、実行中のゲームサーバー Pod に対してのみ料金が発生し、システムコンポーネント、オペレーティングシステムのオーバーヘッド、未割り当ての容量に料金を支払う必要はありません。Forrester の調査によると、GKE Autopilot を使用すると、インフラストラクチャ費用が最大 85% 削減され、開発者の効率が 45% 向上することがわかっています。

noclip On: 完全なコントロール、完全な自由

フルマネージドだからといって、ベンダーロックインがあるわけではありません。Google Cloud を利用するゲーム会社の中には、複数のリージョン、オンプレミス、または他のクラウドベンダーにまたがるクラスタフリートでゲームを実行している例もあります。Agones はオープンソースであり、GKE Autopilot はオープンソースの Kubernetes に基づいているため、GKE Autopilot を使用してゲームを提供するにあたり、移植性や柔軟性を犠牲にする必要はありません。さらに、Google Cloud は Agones と Kubernetes プロジェクト双方にとっての最大の貢献者であり続けているため、お客様は Google の専門知識を活用し、次世代のゲームを提供するためのロードマップの策定についてサポートを受けられます。

さらなる強化: Google Cloud の優れた機能との統合を活用

グローバルマルチプレーヤーゲームの正常な実行に必要なテクノロジーは、マッチメイキングサービス、カスタムネットワークプロキシ、データベース、分析など、専用のゲームサーバーを超えて拡張されています。GKE 上でゲームサーバーを実行する場合、こうしたテクノロジーを簡単に統合できます。たとえば、GKE Autopilot で Open Match を使用して、専用のゲームサーバーでマッチメーカーをスケールしたり、Cloud Spanner でプレーヤーのデータを管理したりすることができます。

シークレットミッション: Google Cloud Deploy のマルチターゲット並列デプロイによる継続的デリバリー

今後のグローバルゲームイベントに向けて、新しい機能を備えたゲームサーバーをリージョンごとに立ち上げたいと考えているとします。Cloud Deploy の新しいマルチターゲットデプロイ機能により、まさにそれが可能になります。プレイヤーに近いリージョンに GKE クラスタを作成し、それを（ターゲットとして）マルチターゲットにグループ化し、Agones ゲームサーバーを段階的にデプロイします。最初にステージング環境で検証を行う必要はありません。進行シーケンスの開始時にステージングターゲットを作成してください。本番環境にデプロイする前の承認確認ボタンが必要な場合、Cloud Deploy は、そちらもサポートしています。また、マルチターゲットロールバックもご利用いただけます。

マルチターゲットを使用した Cloud Deploy デリバリーパイプラインの進行シーケンス

ゲームスタート

今後も、インフラストラクチャの管理とスケーリングにリソースを費やすと優れたゲームの作成に費やすリソースが減ってしまうということを念頭に置きつつ、サービスの改善を続けてまいります。GKE Autopilot 上でゲームサーバーを実行するには、こちらの詳細をご覧ください。

- Google Kubernetes Engine、シニアプロダクトマネージャー Ishan Sharma

Cloud Spanner によるマルチプレーヤー型ゲームの構築

Mon, 27 Mar 2023 01:00:00 +0000

※この投稿は米国時間 2023 年 3 月 22 日に、Google Cloud blog に投稿されたものの抄訳です。

ファンタジースポーツゲームは、現実のデータに基づいて作られたライブサービスゲームです。データは、現実のスポーツリーグ、統計情報を公開するウェブサイト、報道機関などのさまざまなソースから収集されます。プレーヤーは、これらのデータをもとに作り上げられた仮想的な世界で選手を集めてチームを結成し、リアルタイムで世界中の対戦相手と勝負します。

このようなゲームは、低レイテンシが求められること、ワークロードが大きく変動すること、ゼロダウンタイムのアーキテクチャが必要となることが特徴です。また、快適なゲームプレイを実現するには、信頼性が高く、世界中から利用でき、変動するワークロードにも迅速に対応できる堅牢なデータベースが必要です。

Niveus は、ワークロードのデジタルトランスフォーメーションを通してカスタマーエクスペリエンスを高めると同時に、市場での差別化を図る企業のサポートを専門とする Google Cloud パートナーです。先日、Niveus のチームは、Cloud Spanner を評価するために、ファンタジースポーツゲームのデモを作成しました。ここでは、このワークロードで Spanner がどのように活用されたかをご紹介します。

リアルタイムのマルチプレーヤー型ゲームで Cloud Spanner を検討する理由

グローバルに分散されたスケーラブルなデータベース: Spanner はグローバルに分散されたデータベースであるため、複数のリージョンにわたってサービスを提供できます。Spanner のアーキテクチャでは、コンピューティングがストレージから分離されており、ストレージとは独立した形でコンピューティングリソースをスケールできます。そのため、柔軟性、パフォーマンス、信頼性の向上、そしてコスト削減を実現できます。分散型データベースなので、オンラインゲームのようにワークロードが全世界で発生し、しかも予測不可能な場合に最適なデータベースとなっています。Spanner は無限ともいえるスケーラビリティを備えているため、ゲームの人気が急に高まった場合でも、急増するワークロードに容易に対応できます。
トランザクションの整合性と強整合性: Spanner は ACID トランザクションをサポートしているため、数百万人ものプレーヤーのアクションの安全性と整合性を保つことができ、ゲームの状態に関する信頼できる唯一の情報源となります。Spanner はデフォルトで、「強整合性」を維持した読み取りを保証します。つまり、オペレーションの開始前にすべてのトランザクションの効果を観察します。データの分散状況や、ノードの障害の有無にかかわらず整合性が保たれます。このような整合性は、ゲームデータの保存やゲーム内のトランザクションにとって重要となります。
高可用性: Spanner では 99.999% の稼働時間とメンテナンスの時間枠ゼロが実現します。そのため、ゲーマーが求める応答性と稼働時間の高い基準を満たすことができます。

このように他のデータベースにはない機能を備えているため、Niantic、バンダイナムコ、Embark Studios など複数のゲーム制作会社のお客様が、バックエンドのゲームデータベースとして Spanner を利用しています。詳しくは、ゲーム向けデータベースのページをご覧ください。

ファンタジースポーツリーグ（FSL）ゲームの実装

スポーツリーグでの対戦は、ファンタジーチームの結成から始まります。各ゲーマーは、次に開催されるクリケットの試合に向けて、2 つのライバルチームから選手を選びます。さまざまなゲームアクティビティに応じてポイントが与えられます。ゲームが行われている間、スコアボードにリアルタイムの情報が掲示され、試合の最後に最も多くのポイントを獲得しているファンタジーチームが勝者となります。

マルチプレーヤー型ゲームでは、ゲーマーが行う各アクティビティについて読み取り / 書き込みオペレーションが必要になるほか、そのデータ（ID、ユーザー名、パスワード、ゲーマーのファンタジーチームのプレーヤー、プレーヤーのデータなど）を保存する必要があります。システムには、ゲーマーに関する基本的な詳細情報に加えて、バックエンドのゲームデータと、スコアボードのスナップショットなどの派生データも保存する必要があります。マルチプレーヤー型ゲームの人気が急に高まると、ユーザー数が一気に増加し、コンピューティングとストレージに非常に大きな負荷がかかります。MySQL などのデータベースでこのような状況に対処するには、デベロッパーがシャーディングされた環境を作成、デプロイ、保守する必要があります。しかしこのような作業は複雑で難しく、費用も膨らみます。一方、Spanner データベースなら、自動的にデータのシャーディングが行われ、コンピューティングの負荷に応じて処理が分散されます。レプリケーションの管理も行われるため、データベースがダウンすることがなく、ゲーマーが快適にプレイすることができます。

このゲームでは、アプリケーションレイヤに Node JS を、バックエンドのゲームデータベースとして Spanner を、スコアボードのデータを保存するキャッシュレイヤとして Cloud Memorystore を使用しています。

ゲームをデプロイする場合、分析も重要な要素となります。ここでは Spanner 上でゲームを実行することに主眼を置いてコードを記述しましたが、このアーキテクチャを拡張し、分析の要素を取り入れることもできます。収集されたゲームデータに対する分析では、Dataflow、BigQuery、Looker を利用することができます。このアーキテクチャでは、Spanner の変更ストリームを使用して、BigQuery にデータを pull しています。BigQuery は、大規模なデータセットを保存および分析するための、スケーラブルで信頼性が高く、セキュアなクラウドベースのデータウェアハウスです。Looker は、データを探索、共有、可視化できる強力なビジネスインテリジェンスプラットフォームです。

アーキテクチャの概要

Spanner 上で開発したゲームをデプロイし、性能をテストしました。ゲームのソースコードをご覧ください。

コードには、開発した以下のようなマイクロサービスが含まれています。

FSL-Backend-Common - 他のマイクロサービスが使用するメソッドやユーティリティがいくつか含まれています。
FSL-MS-Resource-Management - チーム、試合、プレーヤー、ファンタジーチームの詳細など、テーブル用の CRID オペレーションのエンドポイントを処理します。
FSL-MS-Simulator - 試合のシミュレーションを行います。
FSL-MS-Update-Leaderboard - 各ファンタジーチームのスコアを計算し、Memorystore 内のスコアボードを更新します。
FSL-MS-Display-Leaderboard - 試合のスコアボードデータを表示します。

試合のシミュレーション

FSL-MS-Simulator マイクロサービスには、個々のボールと試合をシミュレートする API が含まれています。ボールのシミュレーションには、/simulateBall API が使用されます。同様に、試合全体のシミュレーションは、/simulateMatch を呼び出し、試合シミュレーション API を使用して行われます。

SimulateBall は、Pub/Sub トピック simulatorListener および updateScore にメッセージを push します。UpdateScoreListener は Pub/Sub からデータパケットを受信し、/updateScore API を呼び出します。この API は、固定長のバッチを作成してupdateRedis Pub/Sub トピックに push し、大量のデータ処理を並列実行します。

スコアの更新

試合の進行とともに各チームのスコアが Memorystore に蓄積され、この情報に基づきスコアが計算されます。Memorystore でスコアが更新されると、Spanner でも更新が行われます。大量の書き込みを処理できるよう、数多くのサブスクライバーが用意されます。データはこれらすべてのサブスクライバーがリッスンする Pub/Sub に push され、イベントがパブリッシュされて、Spanner への書き込みが開始されます。

Spanner へのスコアボードデータの保存

最後のボールの処理が終わると、スコアボードのスナップショットを Spanner で更新します。これにより、試合終了後にサイトを訪問したユーザーは、試合の最終的なスコアボードを見られるようになります。将来的には、保存されたデータに基づいて ML モデルを構築し、ユーザーのスコアと勝者を予測することもできるようにする予定です。

スコアボード

ファンタジーチームはスコアボードに掲示され、スコアに基づいてランキングされます。各チームのスコアは Memorystore で計算されます。試合が行われている間、すべての書き込みがキャッシュに対して行われ、リアルタイムのスコアボード情報は Memorystore から取得されます。

シミュレーション後の結果

シミュレーションが終わったら、上位 10 のファンタジーチームを Spanner の contestDetails テーブルと MatchResults テーブルに保存します。

まとめ

高可用性と強整合性を備えた分散型データベース Spanner は、マルチプレーヤー型ゲーム開発に最適なデータベースとなっています。多くのゲーム制作会社やゲームデベロッパーが、堅牢なバックエンドを提供するデータベースとして Cloud Spanner に信頼を寄せています。Cloud Spanner を利用することで、魅力的なゲームの制作という本来の作業に集中して取り組むことができます。

ゲームの ER 図はこちらをご覧ください。Google Cloud の既存のお客様、および新規のお客様いずれも Spanner の無料トライアルインスタンスをご利用いただけます。費用は一切かかりません。

Spanner の利用方法、特にゲームでの活用方法について詳しくは、以下をご覧ください。

ゲームサーバーのバックエンドとしての Cloud Spanner
ゲームデータベースとして Cloud Spanner を使用する場合のベストプラクティス

^{このブログ投稿に協力してくれたデータベース（Google Cloud）担当グループプロダクトマネージャー Aalok Muley に感謝します。}

- Google Cloud、テクニカルアカウントマネージャー、Sarun Singla
- Nevius Solution、シニアソリューションアーキテクト、Sagar Vaidya 氏

ユビタスと Google Cloud、クラウド上のゲームストリーミングを強化する戦略的パートナーシップの締結を発表

Wed, 22 Mar 2023 02:00:00 +0000

※この投稿は米国時間 2023 年 3 月 20 日に、Google Cloud Press Release に投稿されたものの抄訳です。

Tokyo, Japan and Sunnyvale, Cali., Mar. 20, 2023 – クラウドストリーミング技術のリーディングプロバイダーである株式会社ユビタスと Google Cloud は本日、ゲーム業界におけるクラウドストリーミングの発展を目指し、新たなパートナーシップを締結したことを発表しました。本パートナーシップのもと、ユビタスは Google Cloud を主要クラウドプロバイダーとして選択し、大半のワークロードを Google Cloud 上で稼働させます。また、ユビタスの GameCloud ソリューションを Google Cloud Marketplace 上で提供開始し、開発者がより一層クラウドゲーム技術を活用できるようにします。ユビタスは、主要なゲーム機メーカーやパブリッシャーと協力し、ゲーム開発者が世界中のプレイヤーにコンテンツを提供できるよう支援します。

ゲーム会社にとって、費用対効果を大幅に向上させるストリーミング技術のプロバイダーは不可欠です。ハードウェアの需要をクラウドに移すことで、ゲーム会社は好きなゲームをあらゆるデバイス（テレビもしくは携帯電話）や設定でプレイし、フル 4K の解像度で映像をストリーミングできる環境をプレイヤーに提供できるようになります。これにより、ゲーム会社は新たなユーザーを獲得して、新たなビジネスチャンスを開拓し、顧客体験を向上させることができます。

両社は以下の取り組みを通じてゲーム向けクラウドストリーミングをデジタルに変革していきます。

イノベーションを加速: ユビタスは、Google Cloud のグローバルスケール、GPU および VM リソース、データ、人工知能（AI）、機械学習（ML）の専門知識を活用し、ゲーム業界にとどまらず、ファッション、不動産、自動車など他業界のストリーミングおよびオンデマンドサービスの品質とパワーも向上させます。
ストリーミングソリューションへのアクセス増加: ユビタスが特許を持つ GameCloud ソリューションが Google Cloud Marketplace 上で利用可能になることで、グローバル規模でのコンテンツ配信への対応力が強化されます。
クラウドゲーム配信をデジタルに変革: ユビタスは、Google Cloud のオープンなインフラストラクチャや強化されたサイバーセキュリティ保護、データ、AI、ML の専門知識を用いて、全世界でのクラウドゲーム配信をさらに効率化します。

ユビタスの創業者兼 CEO である Wesley Kuo 氏は、次のように述べています。「Google Cloud と協力し、お客様の市場参入戦略に対応した柔軟で強力なストリーミングサービスを提供します。本パートナーシップにより、PC、モバイル、タブレット、IPTV、VR / AR ヘッドセットなどあらゆるデバイスで、より簡単に高忠実度のインタラクティブなゲームコンテンツをグローバルに配信することが可能になります。」

Google Cloud のゲーム業界ソリューション担当ディレクターである Jack Buser は、次のように述べています。「Google のゲーム向けクラウドストリーミングの未来を見据えると、ユビタスの強固なソリューションがゲーム業界の新たな基準になることを実感しました。本パートナーシップは、あらゆるデバイスが接続されているライブサービスゲームの配信に対する Google Cloud のコミットメントをさらに明確にするものです。」

ユビタスについて

ユビタスは、世界最高の GPU 仮想化技術とクラウドストリーミングプラットフォームを運用し、その高度な技術を通じ、優れたユーザー体験の提供に専念しています。ユーザーがブロードバンドネットワークに接続している限り、スマートフォン、タブレット、ゲームコンソール、スマート TV、パソコンなどの様々なデバイスで、AAA タイトルのゲームを楽しむことができます。革新的な GameCloud® 技術により、ユビタスはプラットフォーム事業者やデジタルコンテンツ開発者向けに、マルチデバイス上で没入感のあるインタラクティブメディアコンテンツをストリーミング配信し、幅広い用途でメタバースの普及を加速させることができます。

Google Cloud について

Google Cloud は、あらゆる企業のデジタルトランスフォーメーション（DX）を推進します。Google の最先端技術を活用したエンタープライズグレードのソリューションを、業界で最もクリーンなクラウド上で提供しています。200 以上の国と地域のお客様が、成長を実現し、最も重要なビジネス上の課題を解決するための信頼できるパートナーとして、Google Cloud を利用しています。

ゲームの将来を見据えて: Google Cloud のライブサービスゲーム戦略

Mon, 20 Mar 2023 02:10:00 +0000

※この投稿は米国時間 2023 年 3 月 9 日に、Google Cloud blog に投稿されたものの抄訳です。

ライブサービスゲーム（ライブゲーム）こそがゲーム業界の未来である、いうことはもはや疑いようがありません。2022 年に最もプレイされたゲームの上位 10 件はすべてライブゲームで、いずれも新しいコンテンツや機能、ゲームプレイを次々と投入して、プレーヤーを楽しませ続けています。現在、このようなライブサービスモデルが、ゲーム機から、PC、モバイルまで、プラットフォームやジャンルを問わず主流となっています。2024 年までにプレーヤーの数は 36 億人に達すると見られており、ライブゲーム市場におけるチャンスはかつてなく大きくなると予想されます。

Google 検索や YouTube など、世界最大級のライブサービスを世界中の数十億のユーザーに提供している Google も、ライブサービスモデルにおいて新参者ではありません。また、Google の長所を詰め込んだ Google Cloud は、世界中のプレーヤーにライブゲームを届けるためのプラットフォームとして、ゲーム開発者に活用されています。

Google Cloud は、トップクラスの売上を誇る主要ゲーム会社と共同の取り組みを進めています。そのなかで、現在は特に以下の 3 点を重視しながら、ゲームのパフォーマンスおよび分析の一体化に取り組んでいます。

世界中のプレーヤーにサービスを提供する
ゲームデータを収集、整理する
プレーヤーとゲームに関する分析を促進する

この投稿では、その方法をご紹介します。

世界中のプレーヤーにサービスを提供する

ライブゲームは、確実に動作する必要があります。Google Cloud が提供する安全かつ世界最大級のネットワークは、プレーヤーが接続するゲームサーバーのプラットフォームとして活用されています。

ゲームのリリースにあたって、サービスの確実な提供は開発者にとって悩みの種です。人気がどれぐらい出そうか、リリース前に的確に予想しなければならないからです。「アクセスするプレーヤーは千人くらいだろうか？百万人くらい？それとも、もっと？アクセスが一気に集中するだろうか？」皮肉なことに、大成功は往々にして悪夢のようなシナリオを意味します。つまり、ゲームをプレイしたがっているユーザーにサービスを提供できない、という事態です。

ゲーム開発者が成功を恐れることがあってはなりません。そのような事態を回避するために、Google Cloud ができる最も重要なことは、スケールを提供することです。Kubernetes は、巨大スケールのコンピューティング処理に適した方法として広く認知されています。Kubernetes に関する知識については、Google の右に出るものはいません。なぜなら、Kubernetes はもともと Google が立ち上げたプロジェクトであり、現在でも Google はその発展に最も貢献しているからです。

Google が Kubernetes に関する深い知識に基づき開発した Google Kubernetes Engine（GKE）を使えば、ゲーム開発者は、膨大な数のプレーヤーに対応できる能力と自信を得られます。GKE は Kubernetes の自動マネージドサービスで、スケーラビリティに優れ、15,000 以上のノードクラスタを実行可能です。これは、他のクラウドプロバイダと比較して最大 10 倍に相当します。

GKE は幅広いコンピューティングタスクに対応していますが、ご存じのように、ライブゲームのワークロードは特殊です。そのため、Google は Ubisoft と連携し、Kubernetes 向けのオープンソースのゲームサーバーオーケストレーター、Agones を開発しました。Agones と GKE を組み合わせて使用すれば、インフラストラクチャについて心配することなく、プレーヤーのエクスペリエンスに集中して開発を行えます。

Ubisoft は、ゲームサーバー向けの一元化された標準ソリューションを必要としていました。そこで、私たちは Google Cloud と連携して Agones を開発しました。現在では、プレーヤーのエンゲージメントと信頼を広く獲得しています。 Ubisoft、エンジニアリングおよびプラットフォーム担当バイスプレジデント、Pierre Romagné 氏

ゲームデータを収集、整理する

ライブゲームでは、プレーヤーの進度を保存しておく必要があります。Google Cloud を使えば、ゲーム開発者はスケールやパフォーマンスについて心配することなく、プレーヤーのエクスペリエンスを保護できます。

ライブサービスゲームには連続性があります。プレーヤーは、レベルの獲得、友人の追加、スキンの購入などをしながら、プレイを続けます。プレーヤーにとっては、自分のショットひとつひとつの正確性など、ちょっとしたデータすべてが大きな意味をもちます。それに加えて、ライブゲームでは世界中から数百万人のプレーヤーが同時接続する可能性があることを考えると、これらすべてのデータを保存することは不可能のようにも思えます。

Google Cloud は、ライブサービスに関する豊富な経験に基づいて Cloud Spanner を開発し、データのスケーラビリティに対応しています。Spanner は、水平方向にスケールする単一の論理データベースを提供し、1 秒に 20 億件以上のリクエストを処理することが可能です。Spanner を使えば、パフォーマンス、管理性、スケーリングのどれも妥協せずに済みます（シャーディングはもう不要です）。ゲーム開発者は、単一のデータベースをスケールして、膨大な数のプレーヤーに対応できます。

私たちは、常時、約 5,000 の Spanner ノードがトラフィックを処理しています。これらのノードがすべて連係動作し、世界中で同時プレイする数百万人のプレーヤーに対応しています。 Niantic、Pokémon GO 担当シニアエンジニアリングマネージャー James Prompanya 氏

Spanner はスケーリングを提供するだけでなく、費用の節約（最大 50%）やレイテンシの短縮（最大 25%）にも役立っており、プレーヤーのエクスペリエンス向上に貢献しています。たとえば、新しいスキンのロックを解除し、直ちに身につけるという動作ひとつを取っても、背後に Spanner の存在があります。

プレーヤーとゲームについて分析、把握する

ライブゲームは、正しい方向に向かって進化し続ける必要があります。Google Cloud では、Google の分析機能および AI を使って、新規ユーザーを獲得したり、既存ユーザーをつなぎとめたりするために効果的な方法を把握できます。

世界には 30 億超のプレーヤーが存在しますが、これらのプレーヤーは千差万別です。すべての人に喜んでもらうには、何が受けているのかを把握し、プレーヤーのセグメントを適切に分ける必要があります。たとえば、世界的なゲームパブリッシャーであるスクウェア・エニックスはデータと分析を使って「ゲーマーを一元的に把握できるビュー」を作り出し、プレーヤーを理解して引きつけることに成功して、プレイ時間の増加につなげています。これはつまり、収益化の機会を増やしているということです。

BigQuery はインサイトを生み出す触媒であり、大手ゲーム開発会社の間で「キラーアプリ」として知られています。Google Cloud を利用する主なゲーム会社のほぼすべてが、BigQuery を活用しています。データ分析の観点からすると、BigQuery は「運用」の対象であり、プレーヤーやゲームに関する大量データの分析、結合に活用されています。たとえば、新機能が成功するかどうかを予測したり、プレーヤーの行動に応じて特典をパーソナライズしたりするなど、ゲーム会社が考えてもみなかったことにまで対応し、誰に聞いていいかわからなかったような問いにも答えを示してくれます。BigQuery は使いやすさを念頭に設計されているため、以前だったらサイロに閉じ込められていたようなデータを自由に使って、社内の誰もが分析を実行できます。BigQuery を内蔵の ML や Vertex AI と合わせて使用すれば、組織全体でさらに分析を進められます。

ゲームへの飽くなき情熱に応える

Google Cloud は、ライブゲームの成否を左右するのはゲームの楽しさであり、インフラストラクチャの強度によって成功が制限されるべきではないと考えています。こうした考えに基づき、ゲームの分析とパフォーマンスを一体化するライブゲームエコシステムを構築しています。

Google Cloud for Games は、Google Cloud を中心に、Ubitus、Incredibuild、HeroicCloud、Unity により実現されたソリューションを包含するエコシステムです。

Unity Gaming Services スイートは、グローバルなスケールでゲームをシームレスに開発、リリース、成長させるための、きわめて堅牢なツール兼インフラストラクチャです。Google と連携し、このスイートを開発者の皆様に提供できることを非常に嬉しく思っています Unity、Unity Gaming Services SVP & GM、Jeff Collins 氏

このエコシステムに含まれるソリューションはすべて、密接に連携することで最大の効果を発揮します。特に目立つ MVP のようなソリューションがあったとしても、その活躍は、小規模チーム同士の歯車が噛み合った連携プレイによって支えられているのです。

Google Cloud for Games について詳しくは、goo.gle/cloudforgames をご覧ください。

お読みいただきありがとうございました。

- Google Cloud、ゲーム業界ソリューション担当ディレクター Jack Buser

Google Cloud Marketplace を介し Redis Enterprise でマッチメイキングを実現

Wed, 04 Jan 2023 22:00:00 +0000

※この投稿は米国時間 2022 年 12 月 17 日に、Google Cloud blog に投稿されたものの抄訳です。

対戦相手に満足できなかったマルチプレーヤーゲームをプレーしたことがありますか？このシナリオはよくあることで、おそらく誰にとっても理想的な体験ではないでしょう。

ゲーム開発者は、少なくとも同等程度の実力のプレーヤー同士が対戦できるように心がけます。プレーヤー同士のマッチングを正確に行うことは、マルチプレーヤーゲームにとって必須条件です。なぜなら、適切なマッチングを行うことで維持率と収益を増やせるからです。何より、プレーヤーのゲームのリピート率が向上し、取引高を上げることができます。

マッチメイキング機能は必要不可欠ですが、効果的なマッチメイキング機能を開発するのは困難な作業です。スキルレベルやその他多くの属性を瞬時に評価することが求められます。ゲームにおけるマッチメイキングは、どのプレーヤーもゲームセッションに参加するために長時間待つことはないため、非常に迅速に行う必要があります。

課題

ハードウェアとソフトウェア両方の進化により、何百人ものプレーヤーがマッチングされてゲームまたは体験を楽しむ大規模なゲームも可能となっています。人気ゲームの同時プレーヤー数は、増加の一途をたどっています。現在、人気ゲームの同時プレーヤー数は、ゲーム、曜日、時間帯によって、300 万～1,000 万人1となっています。

プレーヤー層が拡大している一方で、期待されるレイテンシは短くなっています。この 2 つの力から、水平方向にスケーラブルで超高速なマッチメイキング用バックエンドの必要性が高まっています。このため、Google は Unity と提携し、Open Match というフレームワークを作成しました。Open Match は Kubernetes 上で動作し、Redis がデータレイヤーとなります。目標は、一から再開発しなくても済み、開発者がゲームに向けてプレーヤーをつなぐロジックに集中できるよう、自動スケーリング可能なマッチメイキングフレームワークを作ることでした。前回は Open Match と Memorystore の併用について説明しましたが、今回は Google Cloud Marketplace における Redis Enterprise について説明します。

Google Cloud Marketplace における Redis Enterprise

ハードウェアとソフトウェアの両方の進歩により、1 ゲームあたりにより多くの同時プレーヤーと大人数のプレーヤーがゲームに参加する中、スケーラビリティが Open Match の最重要課題となっています。Open Match は Kubernetes 上で動作するため、コンピューティングレイヤーが GKE のクラスタオートスケーラーなどの技術で自動スケーリング可能で、通常は DevOps エンジニアにとって大きな問題にはなりません。しかしながら、データレイヤーでスケーラビリティと高可用性を確保することは、Open Match の DevOps チームにとって面白みのない作業です。

スケーラビリティと高可用性の課題に対する第一歩として、OSS Redis に代わり、Redis Enterprise Cloud で Open Match フレームワークを立ち上げました。Redis Enterprise は直線的にスケールでき、ダウンタイムを必要とせずボタンをクリックするだけでスケールできるため、スケーラビリティの負担が大幅に軽減されます。そのうえ、高可用性は、管理コンソールのスライダーで管理できます。

スケーラビリティの設定（左）と高可用性の設定（右）

Redis Enterprise Cloud は、24 時間 365 日サポートと 99.999% の SLA が保証されたフルマネージド型サービスで、料金は 1 つの Google Cloud アカウントを通じてわかりやすい形で請求されます。

VPC ピアリング

Redis Enterprise Cloud は、Google Cloud Marketplace または Terraform プロバイダを通じて、数分でデプロイできます。データベースを作成したら、Google Cloud のプロジェクト名とネットワーク名を提供することで、GKE クラスタが所属する VPC と Redis のマネージド VPC をピアリングできます。ピアリングが完了すると、GKE クラスタがデータベースのプライベートエンドポイントを通じて Redis Enterprise データベースに接続できるようになります。

Redis Enterprise Cloud での Open Match の使用

新しく作成した Redis Enterprise Cloud データベースがプロビジョニングされたのであれば、使用準備が整っています。以下の helm コマンドを実行して、Redis Enterprise Cloud インスタンスを指す GKE クラスタに Open Match をインストールできます。

code_block: <ListValue: [StructValue([('code', 'helm install open-match open-match/open-match \\\r\n--set open-match-customize.enabled=true \\\r\n--set open-match-customize.evaluator.enabled=true \\\r\n--set open-match-override.enabled=true \\\r\n--set open-match-core.redis.enabled=false \\\r\n--set open-match-core.redis.hostname="Default:<password>@<Redis-Enterprise-Database-Private-Endpoint>" \\\r\n--set open-match-core.redis.port=<Redis-Enterprise-Database-Port-Number> \\\r\n-nopen-match'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa3720d51f0>)])]>

たとえば、次のようになります。

code_block: <ListValue: [StructValue([('code', 'helm install open-match open-match/open-match \\\r\n--set open-match-customize.enabled=true \\\r\n--set open-match-customize.evaluator.enabled=true \\\r\n--set open-match-override.enabled=true \\\r\n--set open-match-core.redis.enabled=false \\\r\n--set open-match-core.redis.hostname="Default:ZDtglM5R@redis-16264.internal.c21576.us-west1-mz.gcp.cloud.rlrcp.com" \\\r\n--set open-match-core.redis.port=16264 \\\r\n-nopen-match'), ('language', ''), ('caption', <wagtail.rich_text.RichText object at 0x7fa3720d5cd0>)])]>

このチュートリアルに沿って Open Match デモをデプロイして実行し、マッチを生成して Redis Enterprise の動作を確認できます。

まとめ

Redis Enterprise on Google Cloud は、20 以上の Google Cloud リージョンにまたがるアクティブ - アクティブ地理的分散機能により、線形スケーラビリティ、高可用性（99.999% SLA）を保証し、世界規模でのゲームのリリースをサポートします。ユーザーの急増は、ゲームの成功のための現実的かつ重要な機会です。ゲーム会社はこのような瞬間に備え、プラットフォーム上でプレーヤーを維持するために可能な限りのことを行う必要があります。Open Match with Redis Enterprise を採用することで、正確で、互換性が高く、超高速なマッチメイキング機能を大規模に実現できます。

次のステップ

^脚注:

^{1. Fortnite Player Count - 現在のプレーヤー数は？}

^{この記事は、Redis のクラウドパートナーソリューションアーキテクトである Gilbert Lau 氏に寄稿していただきました。}

- Redis、シニアパートナーソリューションアーキテクト Volkan Civelek 氏
- Google デベロッパーアドボケイト Jon Foust

Gaming

AI を活用した「生きたゲーム」への移行: 遊び方をレベルアップさせるお客様とパートナーをご紹介

Atlas: 広大な 3D ゲームの世界を創造する AI

Embody: 臨場感あふれるパーソナライズされた空間オーディオ

Ludeo: プレイ可能なハイライトを通じたゲームの発見

NACON: AI による変革でゲーム制作を加速

Nitrado: 完璧なマルチプレーヤー型ゲームのためのハイブリッド クラウド スケーリング

生成 AI とクラウドゲームでマルチプレーヤー ゲームを強化: 技術解説

Co-op モード: AI でゲームの未来を推進する新たなパートナー

バンダイナムコエンターテインメント / バンダイナムコスタジオ: GKE と Spanner で『鉄拳8』のグローバルなプレイ環境を支える

TEKKEN™8 & ©Bandai Namco Entertainment Inc.

バンダイナムコエンターテインメント、Google Cloud のスケーラブルで安全なインフラストラクチャを利用して、人気シリーズ全体でのシームレスなゲーム起動を実現

Tencent: より良いゲーム開発のために分析文化を醸成する

スケーラビリティと成長のためのアーキテクチャ

ゲームとマーケティング データセットを結び付ける新たな基盤

収益を生み出す技術スタックで前進する

-Funcom、ゲームデータ リード アナリスト Mathieu Ruiz 氏-Tencent、データ プラットフォーム担当マネージャー Hao Liang 氏

ゲームプレイの進化: ライブゲームから生きたゲームへ

ライブゲーム: 新しい時代、新しいニーズ

生成 AI によってライブゲームが生きたゲームに生まれ変わる

コラボレーション エコシステムでゲームプレイの未来を形作る

ライブサービス ゲーム向けにクラウドで ML を実行

クラウドベースの ML とライブサービス ゲームの進展

統合データ プラットフォームによりリアルタイム AI が実現

デモ機能

ゲームスタート: Aiven for Apache Kafka と BigQuery の究極の組み合わせ

リアルタイムでインフラストラクチャ スケーリングを自動化

将来を見据えた自動スケーリング

Aiven と Google Cloud の連携のメリット

まとめと次のステップ

ゲーム業界における生成 AI の革命: 無限の創造性への道

ゲームにおける生成 AI の違いを理解する

イノベーションへのスタートを切る

Google Cloud、カプコンとの新たなパートナーシップを発表

Improbable、DevOps Awards で「クラウドの機能を最大限に活用」賞を受賞

お客様のニーズに応える

ソリューション

クラウドの力

グローバル スケールのマルチプレーヤー型デモにより加速するマルチプレーヤー ゲーム開発

Droidshooter

アーキテクチャの概要

ゲーム状態のフロー

ゲーム クライアントの起動

マッチ メイキング

ゲームサーバーの割り当て

最終クリーンアップ

エコシステムの内訳

Terraform

GKE Autopilot と GKE Standard

Agones

Open Match

Unreal Engine 5

Cloud Build と Cloud Deploy

Artifact Registry

Anthos Service Mesh

Cloud Spanner

まとめ

Glance が Google と協力してワンランク上のゲーム レコメンデーション エンジンを構築

履歴に基づくデータセット

データの傾向の特定

外れ値の取り扱い

データの分割

データの前処理

実験およびモデリング アプローチ

実験の指標

結果と観察

Google Cloud AI サービス（AIS）によるエンドツーエンドの迅速な導入

GKE や Open Match、Agones を使用したマルチプレーヤー型 Google Doodle ゲームの構築

はじめに

Google Doodle とは何ですか？

マルチプレーヤー型 Google Doodle とは何ですか？

最近リリースされたマルチプレーヤー型 Google Doodle とはどのようなものですか？また、その後どうなりましたか？

Google ホームページ用のマルチプレーヤー型ゲームをリリースするうえでの課題は何ですか？

マルチプレーヤー型 Google Doodle にはどれくらいの数のプレーヤーが参加しますか？

ブラウザベースのゲームと他の種類のマルチプレーヤー型ゲームにはどんな違いがありますか？

これらのマルチプレーヤー型 Doodle ゲームをどのように作ったのかを教えてもらえますか？

どんな Google Cloud プロダクトを使用しましたか？

バックエンドにオープンソース プロジェクトを使用することにした理由は何ですか？

どのオープンソース プロジェクトを利用しましたか？

最終的に作成したカスタムコードの量はどれくらいですか？

Nitrado: 完璧なマルチプレーヤー型ゲームのためのハイブリッドクラウドスケーリング

生成 AI とクラウドゲームでマルチプレーヤーゲームを強化: 技術解説

ゲームとマーケティングデータセットを結び付ける新たな基盤

-Funcom、ゲームデータリードアナリスト Mathieu Ruiz 氏
-Tencent、データプラットフォーム担当マネージャー Hao Liang 氏

コラボレーションエコシステムでゲームプレイの未来を形作る

ライブサービスゲーム向けにクラウドで ML を実行

クラウドベースの ML とライブサービスゲームの進展

統合データプラットフォームによりリアルタイム AI が実現

リアルタイムでインフラストラクチャスケーリングを自動化

グローバルスケールのマルチプレーヤー型デモにより加速するマルチプレーヤーゲーム開発

ゲームクライアントの起動

マッチメイキング

Glance が Google と協力してワンランク上のゲームレコメンデーションエンジンを構築

実験およびモデリングアプローチ

バックエンドにオープンソースプロジェクトを使用することにした理由は何ですか？

どのオープンソースプロジェクトを利用しましたか？

通常は、グローバルプレーヤーベースをサポートするのに、1 つの Open Match インスタンスが推奨されています。リージョンごとにインスタンスを用意した理由は何ですか？

GKE Autopilot でゲームインフラストラクチャを実行して、プレーヤーエクスペリエンスに集中する

シークレットミッション: Google Cloud Deploy のマルチターゲット並列デプロイによる継続的デリバリー

ファンタジースポーツリーグ（FSL）ゲームの実装

Spanner へのスコアボードデータの保存

ゲームの将来を見据えて: Google Cloud のライブサービスゲーム戦略

ユビタスと Google Cloud、クラウド上のゲームストリーミングを強化する戦略的パートナーシップの締結を発表

ゲームの将来を見据えて: Google Cloud のライブサービスゲーム戦略