$30 off During Our Annual Pro Sale. View Details »

全世界リリースを支えるマルチプレイゲームの裏側【CAGC2024】※2025年3月6日までの公開

CyberAgent
March 08, 2024
980

 全世界リリースを支えるマルチプレイゲームの裏側【CAGC2024】※2025年3月6日までの公開

アプリボットで全世界リリースしたゲームプロダクトにおいて、マルチプレイは多くの技術的挑戦を含んでいました。
本セッションでは、マルチプレイを開発・運用する上で立ち塞がった3つの壁と、その壁を乗り越えるために使った技術や戦術としてサーバーサイドC#、MagicOnion、Amazon GameLiftについて解説します。

https://cagc.cyberagent.co.jp/2024/session/index.html?id=N7z2nimH

© SQUARE ENIX Powered by Applibot, Inc. CHARACTER DESIGN: TETSUYA NOMURA / CHARACTER ILLUSTRATION: LISA FUJISE
Copyright © CyberAgent, Inc.

CyberAgent

March 08, 2024
Tweet

More Decks by CyberAgent

Transcript

  1. マルチプレイの要件 3 協力型 - 3人のプレイヤーが協力して共通の敵と戦う リアルタイムコマンドバトル - ターン制ではない - 格闘ゲームほどシビアではないが、

    他プレイヤーのコマンドがリアルタイムに反映される リアルタイムな通信の開発は弊社に前例がない → 難易度が高い開発になることが予想された
  2. 技術選定 : C#サーバ 8 バトル … アウトゲーム … マルチ基盤 …

    クライアントはUnity、サーバは.NETで開発し、バトルロジックを C#のコードレベルで共有することで開発コストを削減
  3. 技術選定 : 最終的な構成図 (関連部分のみ抜き出し) 11 ECS Cluster GameLift FleetIQ ECS

    Cluster GameLift GSG Auto Scaling Group API server realtime server GameLift FlexMatch SNS DynamoDB Lambda ALB Auto Scaling Group game play Cloud Front
  4. 技術選定 : 最終的な構成図 (関連部分のみ抜き出し) 12 ECS Cluster GameLift FleetIQ ECS

    Cluster GameLift GSG Auto Scaling Group API server realtime server GameLift FlexMatch SNS DynamoDB Lambda ALB Auto Scaling Group game play Cloud Front
  5. 技術選定 : 最終的な構成図 (関連部分のみ抜き出し) 13 ECS Cluster GameLift FleetIQ ECS

    Cluster GameLift GSG Auto Scaling Group API server realtime server GameLift FlexMatch SNS DynamoDB Lambda ALB Auto Scaling Group game play Cloud Front
  6. 技術選定 : 最終的な構成図 (関連部分のみ抜き出し) 14 ECS Cluster GameLift FleetIQ ECS

    Cluster GameLift GSG Auto Scaling Group API server realtime server GameLift FlexMatch SNS DynamoDB Lambda ALB Auto Scaling Group game play 通常のAPI通信 リアルタイム通信 (MagicOnion) Cloud Front
  7. 技術選定 : 最終的な構成図 (関連部分のみ抜き出し) 15 ECS Cluster ECS Cluster GameLift

    GSG Auto Scaling Group API server realtime server Auto Scaling Group DB ステートフルであり、 バトル中にDBアクセスしない
  8. 未経験開発の壁 19 壁1 : C#サーバの開発 - バトルを再実装するコストを抑えるために C#でサーバ開発することにしたが、弊社に前例がなかった なぜ必要か? -

    バトルにはソロプレイとマルチプレイがあり、ソロはアプリ上で、 マルチはサーバでロジックが動作する - 既にソロプレイ開発はかなり進行していた - 大規模なチームで開発する都合上、同じものを 二重に開発するコストは許容できない → バトルロジックは共有する必要があり、C#サーバは避けて通れない
  9. 未経験開発の壁 20 壁1 : C#サーバの開発 - バトルを再実装するコストを抑えるために C#でサーバ開発することにしたが、弊社に前例がなかった 解決策1 :

    クライアント・経験者・SREを中心に専任チームを結成 - バトルに詳しいクライアントエンジニア - C#サーバ開発経験があるサーバエンジニア - AWS上の構築を担うインフラエンジニア
  10. 未経験開発の壁 22 壁2 : リアルタイム通信の開発 - C#サーバと同様に弊社に前例がなかった 解決策2 : Cysharpサポートのもと、MagicOnionを採用

    - サイバーエージェントグループの Cysharp が開発したライブラリ MagicOnion を採用 - Cysharp と隔週でミーティングを行い、MagicOnion を使った開発を 直々にサポートしてもらう ↓ - 大きなハードルとなる通信基盤の開発コストを大幅に抑えられた
  11. 未経験開発の壁 23 MagicOgion とは? - サイバーエージェントグループの Cysharp が開発したgRPCベースの 通信ライブラリ -

    従来のgRPCでは難しかった複雑なリアルタイム通信が可能 - サーバーとクライアントがお互いの関数を呼び出しているかのように 記述できるため非常に分かりやすい
  12. 未経験開発の壁 24 壁3 : ステートフルサーバーの構築・運用 - 弊社に前例がなかった なぜ必要か? - リアルタイムであることが要件に含まれており、DB通信による

    レイテンシ増加は許容できない - 既に開発が進んでいたソロプレイのバトルロジックはデータが インメモリで管理されている前提だった
  13. 未経験開発の壁 25 壁3 : ステートフルサーバーの構築・運用 - 弊社に前例がなかった なぜ壁になったか? インフラ側の構築・運用が壁になった -

    通信サーバがバトルの状態を持つため、他サーバにアクセスしても 情報を取得できない - バトル中はクライアントがアクセスするサーバを固定する必要がある - 同じバトルに参加するユーザは同じサーバにアクセスする必要がある → 従来のAPIサーバのような単純なロードバランサが使えない
  14. 未経験開発の壁 26 壁3 : ステートフルサーバーの構築・運用 - 弊社に前例がなかった なぜ壁になったか? インフラ側の構築・運用が壁になった -

    通信サーバがバトルの状態を持つため、他サーバにアクセスしても 情報を取得できない - バトルが進行中のサーバを停止してはいけない → 従来のAPIサーバのように単純にスケーリングできない
  15. 未経験開発の壁 27 壁3 : ステートフルサーバーの構築・運用 - 弊社に前例がなかった 解決策3 : AWSサポートのもと、GameLiftを採用

    - サーバのスケーリングやバランシングに相当する部分に GameLift FleetIQ を使い、構築コストを削減
  16. 未経験開発の壁 31 GameLift FleetIQ 詳細は弊社記事「Amazon GameLift を導入してみた話」を参照 未使用 使用中 server1

    未使用 使用中 使用中 server2 未使用 client1 client2 client3 ※図は概念的なものであり、実際のリソース構成とは異なります FleetIQ 確保 URLを返却
  17. 未経験開発の壁 32 GameLift FleetIQ 詳細は弊社記事「Amazon GameLift を導入してみた話」を参照 未使用 使用中 server1

    未使用 使用中 使用中 server2 使用中 client1 client2 client3 ※図は概念的なものであり、実際のリソース構成とは異なります FleetIQ 接続