『Shadowverse: Worlds Beyond』の実装は前作からどう変わった？Unity技術基盤とバトルロジック刷新の裏側【U/Day Tokyo 2025】

左から、鈴木氏、安田氏、元橋氏

前作『Shadowverse』のリリースから9年を経て登場した『Shadowverse: Worlds Beyond（以下、Worlds Beyond）』は、カードバトルに新たなシステム「超進化」を導入したほか、プレイヤー同士が交流できる仮想空間「パーク」が新たに実装されています。

講演の冒頭では、鈴木氏より、Cygamesのスマートフォンゲーム開発における技術スタックが紹介されました。

同社のUnityを用いた開発では、バックエンドや非同期処理などの領域において、子会社であるCysharpが開発する技術を積極的に導入しています。

具体的には、gRPCベースのリアルタイム通信フレームワーク「MagicOnion」、リアクティブプログラミングライブラリ「R3」、Unity向け非同期処理ライブラリ「UniTask」、メモリ展開型の読み取り専用データベース「MasterMemory」などが採用されています。

これらの技術は社内での長期運用実績こそ多くないものの、開発元と密に連携を取りながら導入を進められる点が大きな利点となっています。

エディタ拡張と自動化による開発支援

大規模開発を支えるため、Unityのエディタ拡張機能を活用した開発支援ツールも整備されています。

現場のワークフローに即したツールとして、タイトルごとにカスタマイズしたTimeline機能や、開発中のシーン切り替えを効率化するダッシュボードを実装。

さらに、サーバー通信の内容を可視化するだけでなく、意図的なエラー発生やデータ改ざんのテストを補助するビューワーなど、イレギュラーケースの検証を効率化する仕組みも導入されています。

また、運用を支える自動化の取り組みとして、GitHubでのプルリクエスト作成時やビルド時に自動テストを実行しています。

Unity特有の.metaファイル追加漏れの検知、マスターデータの不整合チェック、各プラットフォームでのコンパイル確認、そしてUnity Test Runnerを用いたロジックの単体テストなどを自動化することで、問題の早期発見を実現しています。

ID管理によるローカライズコストの削減

グローバル展開におけるローカライズにおいても工夫が施されています。テキストをハードコードせずIDで外部ファイルを引用する設計を採用しているほか、言語ごとに異なる「単数形・複数形」などの表記ルールをプログラム側で吸収する仕組みを用意しています。

これにより、エンジニアの手を介さずに翻訳作業が完結し、確認範囲の肥大化を防ぐフローが構築されています。

続いて、安田氏より『Worlds Beyond』の主要機能である「パーク」の開発事例が語られました。

パークは、プレイヤーが3Dアバターを操作し、ロビーでの交流やギルドメンバーとのミニゲームなどが楽しめる仮想空間。1つの空間には最大100人が同時接続できます。

パークでは、キャラクターの移動同期やチャット、エモートなどのインタラクションを実現するために、通信技術としてMagicOnionが採用されました。

パーク内には、ユーザー同士が交流する「ロビー」、ギルドメンバー専用の「ギルドラウンジ」、個人で装飾を楽しめる「スペース」、大会専用空間など、目的の異なる多様なエリアが存在する

MagicOnionの選定理由

これらの多人数同時接続機能を実現するには、リアルタイムサーバーが必要です。リアルタイム通信に採用する技術として、開発チームは「外部サービス」「Node.js」「MagicOnion」を比較検討しました。

Photonなどの外部サービスは機能が充実しており導入が容易ですが、マッチングやルーム管理の仕様がサービス側に依存するため、独自の拡張がしにくい場合があります。

Node.jsを用いたライブラリは、前作での採用実績があり柔軟性は高いものの、Unity（C#）との親和性が低い課題がありました。

そのなかでMagicOnionを採用した理由として、本作が将来的にどのようなバトル形式や空間機能が追加されるか予測しづらいプロジェクトであったことから、自分たちで機能を実装・拡張できることを重視した点が挙げられました。

また、Unity（C#）との親和性の高さも大きな決め手となりました。MagicOnionはサーバーサイドもC#で実装するため、クライアントとサーバーで型定義（クラスや構造体）を共有できます。これにより、APIの定義変更に伴う通信エラーなどのミスが大幅に減少します。

さらに、サーバーへの通信と結果待ちの処理を「非同期メソッドの呼び出し」としてシンプルに記述できる点も高く評価されました。

MagicOnionのコード例。クライアント側（左）とサーバー側（右）の双方がC#で記述されており、非同期メソッド（async/await）を用いて直感的に通信処理を実装できる

ハブとゲームループを分離したサーバーアーキテクチャ

MagicOnionを用いて構築されたサーバーアーキテクチャについても解説が行われました。

MagicOnionには、クライアントと双方向通信を行うための機能「ハブ」が用意されています。ハブの中にゲームロジックを直接記述することも可能ですが、パークのように多数のキャラクターが同時に動き回り、さらに大会進行などが関わる複雑な空間管理を行う場合、ハブだけに処理を任せるのは不向きです。

そこで『Worlds Beyond』では、ハブはあくまで「通信の窓口」としての役割に留め、キャラクターの座標同期やイベント進行などのロジックは、サーバー側のゲームループで処理する構造を採用しました。

MagicOnionによるパークの実装構成。ハブはクライアントとの1:1通信を担当する

ゲームループは、1台の物理サーバー（パークサーバー）上で複数の空間を並列で処理できる構成になっており、サーバーリソースを効率的に活用しています。

パークとバトルの連携イメージ

パークには、他プレイヤーのカードバトルを大型モニター上でリアルタイムに観戦できる「バトル配信機能」が実装されています。

バトル配信機能を実現するにあたり、最初に検討されたのは動画データのストリーミング配信でした。しかし、観戦のたびに動画データのダウンロードが発生するため、ユーザーの通信量や待機時間の負担が大きくなってしまいます。

そこで開発チームは、動画を配信するのではなく、バトルの操作情報だけを受け取り、パークにいるクライアント側でバトル映像を描画するアプローチを採用。これにより、通信量を最小限に抑えつつ、リアルタイムの観戦体験が可能になりました。

クライアント描画の仕組み。観戦者はバトルサーバーから中継サーバー・パークサーバーを経由して、軽量な「操作情報」のみを受け取る

パークの空間内にバトルの空間を表示するために、パーク内に配置したバトル用のGameObjectを、専用のカメラを用いてRenderTexture（※）に書き出す手法を採用。
※　Unityでカメラが描画した映像をテクスチャに保存する機能

Unityのレイヤー機能を用いてバトル用オブジェクトに専用レイヤーを設定することで、パーク用カメラに映らないようにしている

処理負荷約6分の1を目指す最適化

クライアント描画方式では通信量を抑えられる反面、「端末の描画負荷」という新たな課題が生まれます。最大100人のアバターを表示するパーク内でリッチなバトル演出を描画すれば、負荷がモバイル端末で許容される量を超えてしまいます。

パーク内でバトルを描画するには、通常のバトルに対して約6分の1の処理時間（2ms）、約5分の1のメモリ消費（100MB）が求められました。

この目標を達成するため「3D背景やキャラクターのSpineデータを静止画に差し替える」「高負荷な専用エフェクトを軽量な共通エフェクトに置き換える」「カメラ数の削減」などの最適化を適用。これにより、大幅な負荷軽減を実現しています。

配信バトル用に実施された品質調整の内容

カメラの統合による最適化。描画順の不具合は座標調整で解決した

「DFrame」を活用して負荷テストを自動化

最適化の検証には、C#でシナリオ記述が可能な分散負荷テストフレームワーク「DFrame」を活用。大量のボットによる自動操作環境が構築されました。

さらに、モバイル端末特有の「発熱による性能低下（サーマルスロットリング）」に対処するため、FPSだけでなくバッテリー温度の推移も同時に記録・グラフ化する仕組みをCI上に整備し、負荷を正確に計測できるようにしています。

DFrameを用いた自動操作の流れ。プレイヤー作成からパーク入場、移動までのシナリオを自動実行し、負荷計測を行う

CI上で自動生成されたパフォーマンスグラフ。黒線がFPS、ピンク線がバッテリー温度を示しており、温度上昇に伴うフレームレートの変化が可視化されている

講演の後半では、元橋氏より、カードバトル部分のアーキテクチャ刷新について解説されました。

前作『Shadowverse』の課題とサーバー権限への移行

前作では、カード能力やAIロジックをクライアント側で計算し、サーバーが検証する「クライアント主導」の設計でした。この設計は、チート対策のフローが複雑化するだけでなく、通信断時の同期処理が難しい、さらにAIの思考速度が端末スペックに依存するなどの問題を抱えていました。

『Shadowverse』の通信フロー。クライアントでの計算結果をサーバーが検証し、さらに相手クライアントでも計算・検証を行うなど、処理が複雑になっていた

そこで『Worlds Beyond』では、バトルロジックを完全にサーバー側へ移行。クライアントは操作情報のみを送信し、すべての計算をサーバーが行いクライアントに結果を返すシンプルな構造となりました。

これにより、不正対策が不要になったほか、AIの思考が端末スペックに依存せず安定化しています。

『Worlds Beyond』の通信フロー。クライアントは操作を送るだけで、ロジック計算はサーバー側で一括して行われる

また、サーバーで処理が完結するため、前作では1バトルに数分かかっていた自動デバッグが約10ミリ秒に高速化するなど、開発効率が大幅に向上しました。

通信ラグへのUX対策とデータ構造の見直し

バトルロジックをサーバー側へ移行したことで、すべての操作に通信が発生することによるラグが新たな課題となりました。

そこで、操作（送信）から計算結果が返ってくるまでに再生される演出のテンポ感を調整することで、手触りをスムーズにしています。

操作から計算結果の反映までにアニメーションを挟むことで、プレイヤーに待機時間を感じさせないようにしている

ロジックと演出を独立可能に

また、カード能力の処理がサーバー側に完全移行したことで、マスターデータの設計にも自由度が生まれました。これを生かし、マスターデータを「カード能力（ロジック）」と「カードの見た目（演出）」に分離する設計を採用。

分離により、ロジックのマスターデータを変えずに独自の演出データを追加しやすい環境が実現しました。

最後に、鈴木氏は「これからの最高の体験に向けて、技術面もゲームも超進化させていきます」と述べ、講演を締めくくりました。

神谷 優斗

コーヒーがゲームデザインと同じくらい好きです