【U/Day Tokyo 2025 フォローアップ】Cygames流最新スマートフォンゲームの技術設計～「Shadowverse: Worlds Beyond」におけるアーキテクチャ再設計の挑戦～

こんにちは。クライアントサイドの鈴木、安田、元橋です。
U/Day Tokyo 2025で「Cygames流最新スマートフォンゲームの技術設計～『Shadowverse: Worlds Beyond』におけるアーキテクチャ再設計の挑戦～」というタイトルで講演を行いました。ご参加いただいた皆様、ありがとうございました。

当日の資料はこちらです。

この記事では、講演内容のフォローアップ、いただいた質問に対する回答をお伝えします。

MagicOnionについて

シャドバWBでリアルタイムサーバーの実装に採用したMagicOnionについてご紹介します。

MagicOnionは子会社である株式会社Cysharpが開発した、リアルタイム通信のためのOSSです。p.29でも少し触れていますが、下記のような特徴があります。

gRPCをベースにした高速な双方向ストリーミング通信が可能であり、サーバー側のコードもC#で記述可能
クライアントからサーバーのAPI呼び出しと結果待ちが非同期メソッド１つで書くことができ、クライアント実装が容易
API定義の形式がC#のinterfaceそのものであり、クライアントとサーバーでコードを共有できる

これらの特徴に加えて、通信部分以外の機能実装は自分たちの要件に合わせて自由に作りこめるため、今後のパークやバトルの仕様拡張にも柔軟に耐えられることを重要視した結果、シャドバWBではMagicOnionを採用しています。
MagicOnionやその開発事例ついては、弊社エンジニアブログや過去の講演資料もありますので、是非そちらもご参照ください。
MagicOnion – C#による .NET Core/Unity 用のリアルタイム通信フレームワーク
 C#によるクライアント/サーバーの開発言語統一がもたらす高効率な開発体制～プリコネ！グランドマスターズ開発事例～

パークのバトル配信機能について

パークの開発事例紹介では、バトル配信の最適化や実現に向けたアプローチに関する質問をいただきました。それぞれについて説明させていただきます。

バトル配信の最適化

バトル配信の実現のアプローチとして、クライアント側でパークと同時にバトルも描画する方法を採用しました。それについて、最適化が大変ではなかったか？といった質問をいただきました。
実際、パークやバトルの機能ができあがりつつある中で、この機能を追加して処理負荷やメモリ消費の面で問題ないか？という懸念は私たちの中にもありました。一方で、この機能が実現できれば、パークが目指す姿に近づくことが予想できていたため、実現の道を探っていくことにしました。

最初に、バトル配信による処理負荷と消費メモリの増加をどれくらいに収める必要があるかを、パークのこれまでの負荷計測結果やメモリ配分などを元に試算しました。その結果、p.43のようにかなり削減しなければならないことが分かりましたが、何をどのようにすれば、この数値に収められるかを検討していくことにしました。
具体的には、3D背景やSpineデータの静止画化など、検証が比較的容易で削減効果が特に大きそうな描画品質の調整を実際に行い、どれくらい効果があるかを計測しました。また、バトル配信の体験において何が重要で、何が調整可能なのかを、企画面・デザイン面で擦り合わせていきました。その結果、p.44のように描画品質を調整すれば実現は可能という技術的な当たりをつけることができました。

動画配信のアプローチをとらなかった背景

また、バトル配信で動画配信のアプローチをとらなかった理由についても質問をいただきました。これについて、p.36で説明したようなダウンロードの懸念以外にも理由がありますので、補足させていただきます。
それは対戦中のプレイヤーの画面が、バトル配信で求められる画面とは異なるという点です。たとえば、対戦中のプレイヤーの画面では互いに相手の手札は伏せられており、見ることができません。一方、バトル配信の画面は、試合展開をわかりやすくするため、両者の手札は公開された状態にする必要があります。そのため、動画配信のアプローチでは、単純にどちらかの画面を配信すればいいというものではなく、専用の仕組みを構築する必要がありました。
このような仕組みをイチからつくるよりは、上述のようにある程度技術的に当たりがついているクライアント側で描画するアプローチのほうが、実現が容易そうだと考えたということも背景にありました。

バトルの手触りと通信の関係

続いてバトルの開発事例からは、p.64の手触りの改善について補足します。
クライアント側にあったバトルロジックをサーバー側に移行する際の課題として、通信待ちの発生によるUXの低下がありました。
前作はカード操作の手触りの良さを追求して、演出中に次のカードを操作できるようにしています。
カードを操作した際、次のカードを操作するために

カードを操作に伴う演出情報
カードを操作後に次に操作できるカード情報

が必要であり、この情報はサーバー側処理の結果としてレスポンスで受け取ります。
この通信に伴うUX低下への対策として、p.65で紹介したフロー改善と、演出面の調整を行い、p.66のように前作よりも手触り感が向上しました。

バトル処理のサーバー移行コストについて

p.62などでも触れましたが、UX最優先のため前作の運用時期においてはクライアントのカードロジックの実装とそれに追従するサーバーの不正検証ロジックの両方を実装する必要がありました。
シャドバWBを新たに作るにあたり、1から作り直してサーバーにロジックを移す対応は、UX最優先の方針を維持しながら、長期運用を見据えた実装コストの低減を実現するために必要な挑戦でした。
シャドバWBでは本講演で紹介した通り、リアルタイム通信の技術選定として前作で使用していたNode.jsではなくMagicOnionを採用する方向であったことも移行を進めるきっかけとなりました。
シャドバWBとしての新規開発をしながら基礎設計を再構築したという形なので移行コストという形での計測ができてはいませんが、前作の開発、長年の運用で得られた知見が活かせる部分が多く、バトルを動かすまではスムーズに移行できました。
移行を進めるにあたって、元の課題であった手触り感の懸念解消、クライアント側でロジックを持つことによって生じた技術設計面の課題解決を併せて実現することを目指して取り組みました。
シャドバおよびシャドバWBは対戦型DCGであり、ターン制で進行するPvPバトルです。
そのため、サーバー側でロジックを処理することでのデメリットも少なく、今回の移行が開発の効率化につながり、機能拡張への対応速度も向上しました。

おわりに

今回の講演ではCygamesの最新スマホゲームにおけるクライアント部分を中心とした技術設計と、シャドバWBにおける開発事例について紹介しました。シャドバWBでは今後の機能拡張を見据えて、技術要素の刷新に挑戦しました。今後もユーザーの皆様に最高の体験を届けるために、私たちは常に技術をアップデートしていきます！
また、クライアントサイドセクションでは、「最高のコンテンツ」を一緒に実現していく仲間を募集しています。もし、ご興味をお持ちいただけましたらこちらの採用ページをご覧ください。