『神撃のバハムート』『グランブルーファンタジー』『ウマ娘 プリティーダービー』などの人気タイトルを続々とリリースするCygamesは、いかにしてスマートフォン用ゲームを開発しているのか？
セッションが実施されたのは、2025年12月11日（木）にベルサール汐留で開催された、ゲームクリエイター、エンジニア、アーティスト向けのUnity公式技術カンファレンス「U/Day Tokyo 2025」にて。Cygamesの「クライアントサイド」という部署より、マネージャーの鈴木元気氏、ゲームエンジニアの安田朋広氏、同じくゲームエンジニアの元橋智紀氏が登壇し、おもにクライアント部分の技術設計を、最新作『Shadowverse: Worlds Beyond』を例に解説しました。
Cygamesの基本的な開発環境は？
近年のゲーム業界はスマートフォン向けゲームに限らず、高クオリティ・大ボリューム化に加えマルチプラットフォーム対応が求められており、開発規模が拡大し、バランス調整の広範囲化やコストの増加などが問題となっています。そこでCygamesでは開発の効率化をめざして様々なアプローチを実施しました。
そのほとんどがUnity内のエディター拡張を利用したツール開発ですが、たとえばイベントシーンなどの演出で利用しているTimelineでは、タイトルごと専用のエディターを用意し、用途に合わせた形で運用しています。
そのほかシーンの選択および切り替え用にサポート用ダッシュボードを作成、通信機能を確認するためのビューワーの使用、併設したサーバーを管理・切り替えをするためのサーバー選択ツールなどで効率化を果たしました。
バランス調整とデバックの効率化では、プログラム設計としてMVPパターンを採用し、ロジックを独立させることでUnityから切り離して高速テストを行い、ゲームバランスを調整しています。デバックの効率化では基本的に自動テストを採用していますが、テストシナリオを用いるパターンとオート操作のパターンを使い分けることで対応しています。
続いて運用の効率化です。プルリクエスト作成時やビルドの際に様々なテストが行われており、たとえばmetaの追加漏れを検知する存在チェック、マスターデータの不整合チェック、各プラットフォームでのコンパイルエラーチェック、Unity Test Runnerでのユニットテストなどで問題の早期発見を目指したとのこと。
最後にローカライズ対応です。基本方針として開発・運用コストを抑えたいという意図があるので、基本的な仕組みを用意して対応範囲や確認範囲が拡大しないようにしています。そのうえで以下のような取り組みを行いました。
まずテキストは直接入力せず、Unityの外で編集できるようID等で外部ファイルを引用する形にしました。また「1勝、2勝」「1win、2win」などプログラム側で対応できる部分はプログラム側で対応し、なるべく翻訳の範囲を狭めるよう努めたことが紹介されました。
以上がCygamesの基本的な開発環境となります。
リアルタイムで交流する、その仕組みとは？
さてここからは『Shadowverse Worlds Beyond』を例に実際の開発についての解説です。
『Shadowverse Worlds Beyond』はシリーズ第1作となる『Shadowverse』の正当後継作で、デジタルカードゲームの基本システムはそのままに、「パーク」と呼ばれる新機能を実装したタイトルとなっています。サービス開始日は2025年6月17日。iOS/Androidの他にSteamとEpic Games Storeでも提供されています。
『Shadowverse Worlds Beyond』を開発するにあたり、これまでの設計やプログラムを流用するのか、それとも新規タイトルとしてゼロから再構築するのか検討されました。資産を流用すればそれだけ負担の軽減はできますが、今後の長期運用を見据えた場合、各技術要素を見直すほうが将来性はあります。そこで今回はゼロから再構築することになりました。
それでは実際にどのような開発がおこなわれたのか？ 本作の特徴である「パーク」と、ゲームの核である「カードゲーム」の部分について解説します。
まず「パーク」ですが、こちらはユーザーコミュニケーションを目的とした機能で、バトルやミニゲームでの交流など、複数のユーザーがリアルタイムで集う場となります。目玉はやはり「リアルタイム」という点。『Shadowverse Worlds Beyond』ではAPIサーバーのほかにリアルタイムサーバーを設置し、パークとバトルについてはそちらと通信することで実施しました。つまりユーザーがパーク内を移動すると、その座標がリアルタイムサーバーを介して他ユーザーにも共有され、他ユーザー側のクライアントと同期するといった流れです。
それは移動情報だけに限りません。「パーク」にはロビーをまたいでバトルできる「ロビー」、ギルドメンバーに手札を公開しながらバトルを教わる「ギルドラウンジ」、小規模の大会ができる大会用の空間もあります。
その「パーク」を実現するのに最適で、なおかつ将来的な機能拡張にも対応したリアルタイム用のサーバーはどれが良いのかを検討した結果、「MagicOnion」を使用することが決定。「MagicOnion」なら拡張性があり、Unityとの親和性が高く申し分ありません。
なお「MagicOnion」を用いたリアルタイムサーバーの仕組みは以下の通り。通常はクライアントが「MagicOnion」で通信を行うと、サーバー側で「MagicOnion」のハブに定義されたメソッドを呼び出します。しかし大会の進行やキャラの座標などパークの空間に紐づいた処理を直接実装するには不向きです。そこでパークの処理はサーバー側のゲームループで実行するよう構成しました。ちなみにバトルのサーバーでも同様の構成となっています。
パークとバトルで連携が必要な時は、パークとバトルの中間に設置した中継サーバーを介することで情報の受け渡しをしました。たとえばロビーでバトルを開始すると、パークで設定したルールなどが中継サーバーを介し、httpの通信を送受信することでバトル側との情報の受け渡しをします。
以上がリアルタイムサーバーのおおまかな仕組みです。
