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

by Cygames

Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

2/74 鈴木元気クライアントサイド / マネージャー 2014 年にCygames に合流。複数のスマホ向けゲームの新規開発、運用に従事。 2019 年からはクライアントサイドのマネージャーとしてスマホ向けタイトルの開発、運用を横断的にサポートし、技術力強化に取り組んでいる自己紹介安田朋広クライアントサイド / ゲームエンジニア家庭用ゲームの開発を経て 2017 年にCygames に合流。スマホ向けタイトルの新規開発、運用を経験後に「 Shadowverse : Worlds Beyond 」の開発に初期から参画。本作ではクライアントサイドのリーダーを務める元橋智紀クライアントサイド / ゲームエンジニア 2013 年にCygames に合流。「 Shadowverse 」を含めたスマホ向けゲームの新規開発、運用を経験後、「 Shadowverse : Worlds Beyond 」の開発に参画。本作ではカードバトルの開発全般にエンジニアのリードとして携わる

Slide 3

Slide 3 text

3/74 本セッションについてテーマ Cygames のスマホゲームにおけるクライアント部分技術設計『 Shadowverse 』の後継タイトル『 Shadowverse:Worlds Beyond 』における開発事例

Slide 4

Slide 4 text

4/74 本セッションについて記述名称について Shadowverse Shadowverse : Worlds Beyond シャドバ WB シャドバシャドウバースワールズビヨンドシャドウバースワールズビヨンドスライド上では … 口頭では…

Slide 5

Slide 5 text

5/74 1. Cygames のスマホゲーム開発 2. シャドバ WB について 3. シャドバ WB 開発事例～パーク～ 4. シャドバ WB 開発事例～バトル～アジェンダ

Slide 6

Slide 6 text

6/74 1. Cygames のスマホゲーム開発

Slide 7

Slide 7 text

7/74 Cygames について最高のコンテンツを作る会社

Slide 8

Slide 8 text

8/74 Cygames についてゲームの企画・開発・運営、アニメーション製作、漫画事業多様なエンターテインメントを届ける

Slide 9

Slide 9 text

9/74 主にスマホゲームの開発で利用 Cygames でのUnity 活用各タイトルのコンセプトに合わせて技術面もアップデート！本講演ではシャドバ、シャドバ WB を紹介

Slide 10

Slide 10 text

10/74 Cygames で現在採用している技術 UI uGUI 描画 URP バージョン管理 GitHub 動画 CRI Sofdec CI Jenkins Github Actions リアルタイム通信 Magic Onion マスターデータ Master Memory サウンド Wwise 非同期処理 R3/ UniTask

Slide 11

Slide 11 text

11/74 近年のスマホゲームの傾向品質、ボリュームへの対応マルチPF ・全世界対応 • 開発規模の増加 • チーム規模の拡大 • バランス調整、 QAコストの増加・コントローラー対応・多言語対応とローカライズゲームの品質やボリューム、カバー範囲への要求ラインが高まる

Slide 12

Slide 12 text

12/74 • タイトル毎にカスタマイズした Timeline エディター • シーン選択をサポートするダッシュボード • 通信のリクエスト、レスポンス確認ツール • リクエスト、レスポンスデータの内容確認 • 通信内容の改ざんや意図的なエラー発生も • 接続先サーバーの選択、内容確認ツール • 用途、利用期間、担当者、サーバープログラム、リソース情報など開発の効率化エディター拡張

Slide 13

Slide 13 text

13/74 • MVP 設計でロジックを独立し、 Unity 外で高速テストバランス調整、デバッグの効率化バランス調整デバッグ • テストシナリオに沿った自動テスト • オート操作による自動テスト

Slide 14

Slide 14 text

14/74 • プルリクエスト作成時やビルド時に様々なテストを実施 • metaファイルの存在チェック • マスターデータの不整合チェック • 各プラットフォームでのコンパイルエラーチェック • Unity Test Runnerでのユニットテストなど運用の効率化運用を支えるテスト（参考）ユーザを飽きさせない高頻度の更新を可能にする開発運用ノウハウ～ハイスピードな開発、リリースを実現するために～（ CEDEC2017 ） https://tech.cygames.co.jp/archives/3048

Slide 15

Slide 15 text

15/74 • 開発、運用コストの増加を抑える • 基本的な仕組みを用意し、対応範囲、確認範囲の拡大を防ぐローカライズへの対応基本方針開発方法 • テキストは直接入力せずに ID 等で外部ファイルを引用 • テキストの翻訳対応はUnity外で完結 • 単数、複数等の特殊なルールも考慮した設計にする • 「1勝、2勝」や「1 win、2 wins」など

Slide 16

Slide 16 text

16/74 2. シャドバ WB について

Slide 17

Slide 17 text

17/74 シャドバ WB とは

Slide 18

Slide 18 text

18/74 タイトル情報リリース概要プラットフォーム 2025 年6 月17 日 App Store / Google Play / Steam / Epic Games Store 2016 年6 月17 日 App Store / Google Play / DMM GAMES / Steam 4000 種を超える美麗カード！本格スマホカードバトル！「進化」で勝利を！ Shadowverse の正統後継作！新たな次元のデジタルカードゲーム！「超進化」が実現！シャドバシャドバ WB

Slide 19

Slide 19 text

19/74 シャドバ WB の主な要素バトルパーク

Slide 20

Slide 20 text

20/74 シャドバ WB での技術方針シャドバの設計やプログラムを流用新規タイトルとしてゼロから再構築前作シャドバのリソースをどうするか？

Slide 21

Slide 21 text

21/74 シャドバ WB での技術方針シャドバの設計やプログラムを流用新規タイトルとしてゼロから再構築前作シャドバのリソースをどうするか？今後の長期運用を見据え、様々な技術要素の見直しを行いました

Slide 22

Slide 22 text

22/74 3. シャドバ WB 開発事例～パーク～

Slide 23

Slide 23 text

23/74 アジェンダ・パークについての説明・パークの通信のための技術選定・パークの通信を用いた機能の事例紹介・最適化に関する取り組みについて

Slide 24

Slide 24 text

24/74 シャドバ WB におけるパークとは？リアルタイムで交流しながら、バトルに慣れてもらう空間バトルで交流ミニゲームで交流イベントで交流

Slide 25

Slide 25 text

25/74 シャドバ WB のゲームサーバー全体リアルタイム通信で交流を実現パークのサーバーを経由して他のプレイヤーとリアルタイム通信バトルのサーバー群パークのサーバー群キャラ座標などの送受信 API サーバーリアルタイムサーバー（非リアルタイム）クライアント

Slide 26

Slide 26 text

26/74 パーク内に様々な空間が存在パークギルドラウンジグループ内で１位を目指せ！次のバトルへの待ち時間ではサッカーも可能大会専用の空間ギルドメンバーと楽しくバトルやミニゲームが遊べる自分だけの空間装飾のカスタマイズ機能様々なユーザーとワイワイゆるやかな交流の場ロビースペース今日はどこに行こう？

Slide 27

Slide 27 text

27/74 パークパーク内ではバトルも可能ギルドラウンジ大会専用の空間より良いユーザー体験のために、今後の拡張や細かい調整も可能な形を目指した要件様々な空間に移動可能、空間に適したバトルを楽しめるロビースペース今日はどこに行こう？ 16 人もしくは 8 人のグループでマッチングして、小規模な大会を楽しめるギルドメンバーとバトル練習モードで指南もできるフレンドを招いてバトル同一ロビー内の人とバトル相手がいなければ、他のロビーの人とも

Slide 28

Slide 28 text

28/74 リアルタイムサーバーの技術選定 Photon: https://www.photonengine.com/ Node.js: https://nodejs.org/en MagicOnion : https://github.com/Cysharp/MagicOnion 過去の社内実績 Unity との親和性 △ 〇 × 〇〇 Node.js (前作で利用) 外部サービス（ Photon など）拡張への柔軟性 MagicOnion △ 〇〇 × 通信部分以外は実装必要その分、拡張に対して柔軟通信部分以外も機能が揃っている拡張への柔軟性はゲーム要件次第

Slide 29

Slide 29 text

29/74 過去の社内実績 Unity との親和性 △ × 〇〇 △ 拡張への柔軟性リアルタイムサーバーの技術選定非同期メソッドの呼び出しで通信を送り、結果待ちできるサーバー側も C# で書けるのでコードを共有可クライアント側のコード例サーバー側（ハブ）のコード例〇外部サービス（ Photon など） MagicOnion 〇〇 × Node.js (前作で利用)

Slide 30

Slide 30 text

30/74 リアルタイムサーバーの技術選定過去の社内実績 Unity との親和性 △ 〇 × 〇〇外部サービス（ Photon など）拡張への柔軟性 MagicOnion 長期運用の実績はないが、開発元のCysharp の協力でカバー △ 〇〇 × 参考：弊社での MagicOnion 採用例 C# によるクライアント /サーバーの開発言語統一がもたらす高効率な開発体制～プリコネ！グランドマスターズ開発事例～（ CEDEC2022 ） https://cedil.cesa.or.jp/cedil_sessions/view/2637 Node.js (前作で利用)

Slide 31

Slide 31 text

31/74 リアルタイム通信の技術選定シャドバ WB でパークを作る中で最高のユーザー体験が実現できることを目指した当時の想定機能だけではなく細かな調整や今後の拡張への対応を重視して技術選定を行った MagicOnion 採用

Slide 32

Slide 32 text

32/74 MagicOnion によるパークの実現方法サーバー側のゲームループでパークの処理を実行クライアントと 1:1 切断されたら破棄リアルタイム双方向通信ハブゲームループパークの処理 MagicOnion の通信を経由して、クライアントからハブのメソッドが呼ばれるが、パークの空間に紐づいた処理を直接実装するにはハブは不向き同じ空間内のクライアントパークサーバーハブからパークの処理を非同期で呼ぶキャラクターの座標同期大会の進行など

Slide 33

Slide 33 text

33/74 パークサーバー複数の空間内のクライアント MagicOnion によるパークの実現方法・実際のパークサーバーは、 1 台で複数の空間を管理・バトルのサーバーも全体的な構成は同じ同じ空間のプレイヤーパークの処理を空間毎に並列実行ハブ

Slide 34

Slide 34 text

34/74 パークとバトルと連携方法パークからバトル開始したときなど、パークサーバーからバトルサーバーに、情報を送るケースがある中継サーバーを経由して、 HTTP リクエストを送るパーク側バトル側ルールや対戦者情報などの送信中継サーバー

Slide 35

Slide 35 text

35/74 リアルタイムサーバーの活用例バトル配信・パーク内のバトルの様子を“パークにいながら”大勢で観戦・パークの交流をよりよいものにするために追加対応

Slide 36

Slide 36 text

36/74 どう実装する？クライアントに動画を配信する形を検討バトル配信を活用したいという方向性に伴ってダウンロードによるユーザー負担を懸念動画を視聴するためにはダウンロードが必要観戦している各クライアントでバトルを描画する形で実現できないか？

Slide 37

Slide 37 text

37/74 クライアント側での描画に向けてバトル側パーク側観戦者側でバトルを描画するためにバトルサーバーからパークサーバーへバトルの情報を送る必要に応じて配信範囲の調整も可能 ①バトルサーバーから送信 ②パークのサーバーに送信 ③クライアントに送信中継サーバー

Slide 38

Slide 38 text

38/74 配信バトルをパークで描画する方法パークとバトル共存しない前提だったので、レイヤーは流用していた画面出力 3DObj 用カメラパークの構成通常バトルの構成バトルシーン画面出力 3DObj 用カメラパークシーンパークの GameObject レイヤー： 3DObj バトルの GameObject レイヤー： 3DObj 配信バトルを対応する前他のレイヤーのオブジェクトもあるが、割愛

Slide 39

Slide 39 text

39/74 配信バトルをパークで描画する方法パークの構成画面出力 3DObj 用カメラ配信用スクリーンの RenderTexture Battle3DObj 用カメラパークシーンパークの GameObject レイヤー： 3DObj バトルの GameObject レイヤー： Battle3DObj 配信バトルを対応後他のバトルのオブジェクトも専用のレイヤーに・配信の画面は RenderTexture に描画して、パーク側の配信モニターに設定する・レイヤーを分けて、パークのカメラにバトルの GameObject が映らないように

Slide 40

Slide 40 text

40/74 機能的な実現の目途はたったクライアント描画でバトル配信の仕組みは作れそう！もちろん課題も …

Slide 41

Slide 41 text

41/74 パークのキャラ表示の目標パークに求められたことたくさんのキャラを表示したいワイワイ感の演出のために重要パークの場合、 1 つの空間に100 人接続するが可能な限り画面に表示したい！

Slide 42

Slide 42 text

42/74 パークのキャラ表示の目標パークに求められたことたくさんのキャラを表示したい配信のバトルもパークで動かすバトル配信の最適化が必須 NEW ・バトル配信のためにキャラの表示数は減らせない・モデルの品質も下げたくない

Slide 43

Slide 43 text

43/74 バトル配信をパークで動かすために最初に、どれくらい削れば実現できるのかを検討 12ms 500MB 100MB 2ms 処理負荷メモリ消費通常バトルの場合バトル配信の目標上記の目標の範囲内であれば、パークの処理負荷・メモリ消費が増えても、スマホで動かせる

Slide 44

Slide 44 text

44/74 バトル配信の実現に向けて通常バトルの画面品質を維持したまま実現は不可能配信バトルの描画品質や仕様を調整・ 3D 背景やプレイヤーキャラの Spine を静止画に・画面やカードイラストの解像度を落とす・ポストプロセスのカット・手札などの 3D モデルを簡易化・バトルエフェクトの種類削減

Slide 45

Slide 45 text

45/74 バトルの描画処理の最適化カメラ数の削減 CPU 負荷の削減描画順の不具合の発生ポストプロセスのカットやエフェクトの種類を削減したことで統合可能となった。最後はオフセット調整で地道に解決ベースカメラバトルのカメラスタック UI カメラ盤面・手札カメラ画面演出カメラエフェクトカメラ統合メリットデメリット

Slide 46

Slide 46 text

46/74 パークの負荷計測の方法キャラ移動し続けるより実際に近い状況で計測したい計測配信用にバトル開始パーク満員の状態で計測リアルタイムサーバーとの通信などキャラが移動しているときの負荷も反映パークは 100 人入るため、手動では不可能プレイヤー作成パーク入場計測のための手順自動化が必要

Slide 47

Slide 47 text

47/74 DFrame による自動操作 DFrame キャラ移動し続ける計測配信用にバトル開始プレイヤー作成パーク入場 C# でテストシナリオを書ける分散負荷テストフレームワーク元々サーバーの負荷試験で利用していたものを流用 DFrame でテストシナリオを実装して、計測時に実行するだけに Dframe : https://github.com/Cysharp/DFrame/ この部分を自動化計測のための手順

Slide 48

Slide 48 text

48/74 フレームレート計測の改善バッテリー温度上昇による影響を考慮した計測を行いたいフレームレートの変化のグラフを自動生成実機でCSV 出力 CIでグラフ化結果を自動ポスト・ FPS ・ CPU 処理時間・バッテリー温度（ Android のみ） iOS の温度はlibimobiledevice を使って Mac で取得（グラフ化は未対応）フレームレート変化が確認・比較しやすくなった libimobiledevice : https://libimobiledevice.org/

Slide 49

Slide 49 text

49/74 メモリ消費計測の効率化 MemoryProfiler の結果を CSV 出力できる仕組みを作成画面品質のどこを調整すると効果的か、試行錯誤できた各項目の数値を書き出したい

Slide 50

Slide 50 text

50/74 バトル配信もスマホで動作以上のような取り組みでパークの品質を落とさずバトル配信を実現できた

Slide 51

Slide 51 text

51/74 まとめパークの要件の実現と今後の拡張への対応のために MagicOnion を採用した MagicOnion の活用例としてバトル配信機能を紹介最適化と負荷計測しやすい環境の整備により、パークの品質を落とさず、バトル配信を実現できた

Slide 52

Slide 52 text

52/74 4. シャドバ WB 開発事例～バトル～

Slide 53

Slide 53 text

53/74 アジェンダ 1. カードゲームの開発について 2. シャドバからシャドバ WB へバトルロジックのサーバー移行 3. バトルロジックのサーバー移行結果 4. サーバー移行を活かしたシャドバ WB での開発

Slide 54

Slide 54 text

54/74 シャドバ WB のカードゲームの概要１対１で行うターン制のバトル対人戦 AI戦両方が存在

Slide 55

Slide 55 text

55/74 デジタルカードゲームの開発方針非公開情報（相手の手札、デッキ情報など）を不正に取得相手視点で非公開情報を送信しない対戦相手に不要な疑念を抱かせないため不正対策は必須前提ランダム処理の不正操作・好きなカードをドロー・ランダムな能力のコントロール乱数の算出が適正か検証公平性の担保が必要クライアント改ざんによる不正処理通信パラメータの解析による情報の不正取得

Slide 56

Slide 56 text

56/74 シャドバのカードバトル実装バトルロジックをクライアント側、サーバー側両方で保持クライアント側で主に保持している機能・カード能力・ソロプレイ時の敵 AI ・制限時間・切断による勝敗判定など UX向上のため

Slide 57

Slide 57 text

57/74 シャドバでの課題バトルロジックがクライアント側にもあることで … 不正対策のフローが煩雑 AIの思考思考速度が端末スペックに依存負荷が発熱につながるケースも ①自分と対戦相手、サーバーで非公開情報を意識した通信をしながら整合性の検証をする必要 ②相手の通信状況が自身にも影響

Slide 58

Slide 58 text

58/74 シャドバ WB での開発シャドバ運用中に検討もされたが、運用中の特大改修は厳しかったサーバーにバトルロジックを移行 →バトルロジックと演出ロジックが分離 MagicOnion を採用バトルロジックをクライアントから完全にサーバーへ移行シャドバでは Node.js で作っていたバトル部分も再設計が必要

Slide 59

Slide 59 text

59/74 処理の流れ（シャドバ）クライアントの通信ベース ①操作した結果のカード能力処理 ②操作情報をサーバーに送信 ③サーバー側でカード情報検証 ④カード操作情報を相手に送信 ⑤操作した結果のカード能力の処理 ⑥操作結果のカード能力の処理結果送信 ⑦自分と相手クライアントの処理結果検証処理が多く煩雑 … 自分クライアント ①カード能力処理相手クライアント ⑤カード能力処理 ② ⑥ ④ 処理結果の通信カードを手札から場に出す操作 Node.js サーバー ③検証 ⑦検証カード操作の通信

Slide 60

Slide 60 text

60/74 カード能力処理をサーバーに移動処理を減らしシンプルに処理の流れ（シャドバ WB ） ①カード操作情報をサーバーに送信 ②操作した結果カード能力の処理を実行し再生すべき演出の情報を作成 ③それぞれのクライアントへ送信演出を再生相手クライアント ③計算結果送信 MagicOnion サーバー ②カード能力処理カードを手札から場に出す操作 ①カード操作の通信自分クライアント

Slide 61

Slide 61 text

61/74 処理の流れ（シャドバ WB ）処理を減らしシンプルな流れに自分クライアント相手クライアント ①カード操作の通信 ③計算結果送信 MagicOnion サーバー ②カード能力処理自分クライアント ①カード能力処理相手クライアント ⑤カード能力処理 ② ⑥ ④ 処理結果の通信 Node.js サーバー ③検証 ⑦検証カード操作の通信

Slide 62

Slide 62 text

62/74 バトルロジック移行の結果不正対策のフローが簡潔に AIの思考端末のスペックによらず安定化 →AIアドバイスも可能に ①実装コストの低減 ②相手の通信状況に関係なくバトルを進行可能良かった点シャドバ課題点の解消移行前の課題

Slide 63

Slide 63 text

63/74 バトルロジック移行の結果カードを操作した時の処理にサーバー通信が必要単純にカード操作時に通信処理を入れると通信待ちで手触り感が悪化気持ちいいテンポ感、心地よい操作感は何度もカードをプレイする上でとても重要新たな課題通信を挟むことによる UXの低下

Slide 64

Slide 64 text

64/74 手触りを良くするために通信による待ちが発生 UI やカードで反応に遅れカードや UI の当たり判定を可視化して明確に通信などの処理が妨げになっているか確認して改善バトルロジックの計算結果を得るために通信による待ちが発生演出が止まったように見せないよう最大限最適化課題としてこれらをクリアした上で演出のテンポ感や UI の手触りを調整

Slide 65

Slide 65 text

65/74 手触りを良くするために操作通信開始計算結果を再生サーバー側が計算カードの演出再生カードを選択選択処理の反映アニメーション演出で通信待ちを調整

Slide 66

Slide 66 text

66/74 手触りを良くするためにシャドバシャドバ WB 通信を感じさせない上で演出を調整してテンポ調整同じ動作を比較

Slide 67

Slide 67 text

67/74 サーバー移行で得られた他メリット • カードゲームのテストプレイの効率化 • カード能力の自動デバッグの高速化 • カードマスターの整理が可能に

Slide 68

Slide 68 text

68/74 テストプレイの効率化開発環境ではブラウザでもカード操作できるクライアントの演出対応を待たずにカードが使用可能バトルサーバー通信パラメーター検証切断による勝敗処理などカード能力ロジッククライアントアプリ Web ブラウザブラウザのツール

Slide 69

Slide 69 text

69/74 カード能力の自動デバッグの高速化開発中のカード能力の調整コストを低減 2 ヶ月間隔の新カードパックリリースに貢献カード能力ロジックがサーバー側で完結クライアント抜きで自動デバッグサーバーで自動操作 1 バトル 10 ミリ秒程度クライアントで自動デバッグ開発端末で自動操作 1 バトル数分シャドバ開発時シャドバ WB 開発時

Slide 70

Slide 70 text

70/74 カード能力のマスターの整理カード能力のマスターは運用が長くなるにつれ肥大化カラム・ csv 記述が複雑化 70 カラム以上 … 600 文字以上の記述… 能力と演出に関する記述が混在カードマスターも分割！サーバーとクライアントでカード能力処理と演出処理が分離発動ルールに一貫性が必要でシステム的でシンプルにしやすいカード能力カードの見た目演出見た目やテンポ感にこだわるため、能力に応じて独特なパラメータが生まれやすい

Slide 71

Slide 71 text

71/74 まとめ MagicOnion 採用に伴いバトルロジックをクライアントからサーバーに移したサーバーに移すことで不正対策などの要件を満たしつつシンプルな構造に移せたサーバーに移したことで自動デバッグなども効率化することができた

Slide 72

Slide 72 text

72/74 まとめ

Slide 73

Slide 73 text

73/74 本セッションのまとめ Cygames のスマホゲームにおけるクライアント部分技術設計『 Shadowverse 』の後継タイトル『 Shadowverse:Worlds Beyond 』における開発事例バトルパーク

Slide 74

Slide 74 text

74/74