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

2025/12/11 U/Day Tokyo 2025

Transcript

2. 2/74 鈴木 元気 クライアントサイド / マネージャー 2014 年にCygames に合流。 複数のスマホ向けゲームの新規開発、 運用に従事。 2019 年からはクライアントサイドの マネージャーとしてスマホ向けタイト ルの開発、運用を横断的にサポートし、 技術力強化に取り組んでいる 自己紹介 安田 朋広 クライアントサイド / ゲームエンジニア 家庭用ゲームの開発を経て 2017 年にCygames に合流。 スマホ向けタイトルの新規開発、 運用を経験後に「 Shadowverse : Worlds Beyond 」の開発に初期 から参画。本作ではクライアント サイドのリーダーを務める 元橋 智紀 クライアントサイド / ゲームエンジニア 2013 年にCygames に合流。 「 Shadowverse 」を含めたスマホ向け ゲームの新規開発、運用を経験後、 「 Shadowverse : Worlds Beyond 」 の開発に参画。本作ではカードバトル の開発全般にエンジニアのリードとし て携わる
3. 3/74 本セッションについて テーマ Cygames のスマホゲームにおける クライアント部分技術設計 『 Shadowverse 』 の後継タイトル 『 Shadowverse:Worlds Beyond 』 における 開発事例
4. 4/74 本セッションについて 記述名称について Shadowverse Shadowverse : Worlds Beyond シャドバ WB シャドバ シャドウバース ワールズ ビヨンド シャドウバース ワールズビヨンド スライド上では … 口頭では…
5. 5/74 1. Cygames のスマホゲーム開発 2. シャドバ WB について 3. シャドバ WB 開発事例～パーク～ 4. シャドバ WB 開発事例～バトル～ アジェンダ
6. 6/74 1. Cygames のスマホゲーム開発
7. 7/74 Cygames について 最高のコンテンツを作る会社
8. 8/74 Cygames について ゲームの企画・開発・運営、アニメーション製作、漫画事業 多様なエンターテインメントを届ける
9. 9/74 主にスマホゲームの開発 で利用 Cygames でのUnity 活用 各タイトルのコンセプトに合わせて 技術面もアップデート！ 本講演ではシャドバ、シャドバ WB を紹介
10. 10/74 Cygames で現在採用している技術 UI uGUI 描画 URP バージョン管理 GitHub 動画 CRI Sofdec CI Jenkins Github Actions リアルタイム通信 Magic Onion マスターデータ Master Memory サウンド Wwise 非同期処理 R3/ UniTask
11. 11/74 近年のスマホゲームの傾向 品質、ボリュームへの対応 マルチPF ・全世界対応 • 開発規模の増加 • チーム規模の拡大 • バランス調整、 QAコストの増加 ・コントローラー対応 ・多言語対応とローカライズ ゲームの品質やボリューム、カバー範囲への要求ラインが高まる
12. 12/74 • タイトル毎にカスタマイズした Timeline エディター • シーン選択をサポートするダッシュボード • 通信のリクエスト 、レスポンス確認ツール • リクエスト、レスポンスデータの内容確認 • 通信内容の改ざんや意図的なエラー発生も • 接続先サーバーの選択、内容確認ツール • 用途、利用期間、担当者、サーバープログラム、リソース情報など 開発の効率化 エディター拡張
13. 13/74 • MVP 設計でロジックを独立し、 Unity 外で高速テスト バランス調整、デバッグの効率化 バランス調整 デバッグ • テストシナリオに沿った自動テスト • オート操作による自動テスト
14. 14/74 • プルリクエスト作成時やビルド時に様々なテストを実施 • metaファイルの存在チェック • マスターデータの不整合チェック • 各プラットフォームでのコンパイルエラーチェック • Unity Test Runnerでのユニットテスト など 運用の効率化 運用を支えるテスト （参考） ユーザを飽きさせない高頻度の更新を可能にする開発運用ノウハウ ～ハイスピードな開発、リリースを実現するために～（ CEDEC2017 ） https://tech.cygames.co.jp/archives/3048
15. 15/74 • 開発、運用コストの増加を抑える • 基本的な仕組みを用意し、対応範囲、確認範囲の拡大を防ぐ ローカライズへの対応 基本方針 開発方法 • テキストは直接入力せずに ID 等で外部ファイルを引用 • テキストの翻訳対応はUnity外で完結 • 単数、複数等の特殊なルールも考慮した設計にする • 「1勝、2勝」や「1 win、2 wins」 など
16. 16/74 2. シャドバ WB について
17. 17/74 シャドバ WB とは
18. 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
19. 19/74 シャドバ WB の主な要素 バトル パーク
20. 20/74 シャドバ WB での技術方針 シャドバの設計や プログラムを流用 新規タイトルとして ゼロから再構築 前作シャドバのリソースをどうするか？
21. 21/74 シャドバ WB での技術方針 シャドバの設計や プログラムを流用 新規タイトルとして ゼロから再構築 前作シャドバのリソースをどうするか？ 今後の長期運用を見据え、 様々な技術要素の見直し を行いました
22. 22/74 3. シャドバ WB 開発事例～パーク～
23. 23/74 アジェンダ ・パークについての説明 ・パークの通信のための技術選定 ・パークの通信を用いた機能の事例紹介 ・最適化に関する取り組みについて
24. 24/74 シャドバ WB におけるパークとは？ リアルタイムで交流 しながら、バトルに慣れてもらう空間 バトルで交流 ミニゲームで交流 イベントで交流
25. 25/74 シャドバ WB のゲームサーバー全体 リアルタイム通信で交流を実現 パークのサーバーを経由して他のプレイヤーとリアルタイム通信 バトルのサーバー群 パークのサーバー群 キャラ座標などの 送受信 API サーバー リアルタイムサーバー （非リアルタイム） クライアント
26. 26/74 パーク内に様々な空間が存在 パーク ギルドラウンジ グループ内で１位を目指せ！ 次のバトルへの待ち時間では サッカーも可能 大会専用の空間 ギルドメンバーと 楽しくバトルや ミニゲームが遊べる 自分だけの空間 装飾のカスタマイズ機能 様々なユーザーとワイワイ ゆるやかな交流の場 ロビー スペース 今日はどこに 行こう？
27. 27/74 パーク パーク内ではバトルも可能 ギルドラウンジ 大会専用の空間 より良いユーザー体験のために、今後の拡張や細かい調整も可能な形を目指した 要件 様々な空間に移動可能、空間に適したバトルを楽しめる ロビー スペース 今日はどこに 行こう？ 16 人もしくは 8 人のグループ でマッチングして、 小規模な大会を楽しめる ギルドメンバーとバトル 練習モードで指南もできる フレンドを招いて バトル 同一ロビー内の人とバトル 相手がいなければ、 他のロビーの人とも
28. 28/74 リアルタイムサーバーの技術選定 Photon: https://www.photonengine.com/ Node.js: https://nodejs.org/en MagicOnion : https://github.com/Cysharp/MagicOnion 過去の社内実績 Unity との親和性 △ 〇 × 〇 〇 Node.js (前作で利用) 外部サービス （ Photon など） 拡張への柔軟性 MagicOnion △ 〇 〇 × 通信部分以外は実装必要 その分、 拡張に対して柔軟 通信部分以外も機能が揃っている 拡張への柔軟性はゲーム要件次第
29. 29/74 過去の社内実績 Unity との親和性 △ × 〇 〇 △ 拡張への柔軟性 リアルタイムサーバーの技術選定 非同期メソッドの呼び出しで通信を送り、結果待ちできる サーバー側も C# で書けるのでコードを共有可 クライアント側のコード例 サーバー側（ハブ）のコード例 〇 外部サービス （ Photon など） MagicOnion 〇 〇 × Node.js (前作で利用)
30. 30/74 リアルタイムサーバーの技術選定 過去の社内実績 Unity との親和性 △ 〇 × 〇 〇 外部サービス （ Photon など） 拡張への柔軟性 MagicOnion 長期運用の実績はないが、 開発元のCysharp の協力でカバー △ 〇 〇 × 参考：弊社での MagicOnion 採用例 C# によるクライアント /サーバーの開発言語統一がもたらす高効率な 開発体制 ～プリコネ！グランドマスターズ開発事例～ （ CEDEC2022 ） https://cedil.cesa.or.jp/cedil_sessions/view/2637 Node.js (前作で利用)
31. 31/74 リアルタイム通信の技術選定 シャドバ WB でパークを作る中で 最高のユーザー体験が実現できることを目指した 当時の想定機能だけではなく細かな調整や 今後の拡張への対応を重視して技術選定を行った MagicOnion 採用
32. 32/74 MagicOnion によるパークの実現方法 サーバー側のゲームループでパークの処理を実行 クライアントと 1:1 切断されたら破棄 リアルタイム双方向通信 ハブ ゲームループ パークの処理 MagicOnion の通信を経由して、クライアントから ハブのメソッドが呼ばれるが、 パークの空間に紐づいた処理を直接実装するにはハブは不向き 同じ空間内のクライアント パークサーバー ハブからパークの処理を 非同期で呼ぶ キャラクターの座標同期 大会の進行など
33. 33/74 パークサーバー 複数の空間内のクライアント MagicOnion によるパークの実現方法 ・実際のパークサーバーは、 1 台で複数の空間を管理 ・バトルのサーバーも全体的な構成は同じ 同じ空間のプレイヤー パークの処理 を空間毎に並列実行 ハブ
34. 34/74 パークとバトルと連携方法 パークからバトル開始したときなど、 パークサーバーからバトルサーバーに、情報を送るケースがある 中継サーバーを経由して、 HTTP リクエストを送る パーク側 バトル側 ルールや対戦者情報などの送信 中継サーバー
35. 35/74 リアルタイムサーバーの活用例 バトル配信 ・パーク内のバトルの様子を“パークにいながら”大勢で観戦 ・パークの交流をよりよいものにするために追加対応
36. 36/74 どう実装する？ クライアントに動画を配信する形を検討 バトル配信を活用したいという方向性に伴って ダウンロードによるユーザー負担を懸念 動画を視聴するためにはダウンロードが必要 観戦している各クライアントで バトルを描画する形で実現できないか？
37. 37/74 クライアント側での描画に向けて バトル側 パーク側 観戦者側でバトルを描画するために バトルサーバー から パークサーバー へバトルの情報を送る 必要に応じて配信範囲 の調整も可能 ①バトルサーバー から送信 ②パークのサーバー に送信 ③クライアント に送信 中継サーバー
38. 38/74 配信バトルをパークで描画する方法 パークとバトル共存しない前提だったので、 レイヤーは流用 していた 画面出力 3DObj 用カメラ パークの構成 通常バトルの構成 バトルシーン 画面出力 3DObj 用カメラ パークシーン パークの GameObject レイヤー： 3DObj バトルの GameObject レイヤー： 3DObj 配信バトルを対応する前 他のレイヤーの オブジェクトもあるが、割愛
39. 39/74 配信バトルをパークで描画する方法 パークの構成 画面出力 3DObj 用カメラ 配信用スクリーンの RenderTexture Battle3DObj 用カメラ パークシーン パークの GameObject レイヤー： 3DObj バトルの GameObject レイヤー： Battle3DObj 配信バトルを対応後 他のバトルのオブジェクトも 専用のレイヤーに ・配信の画面は RenderTexture に描画して、パーク側の配信モニターに設定する ・レイヤーを分けて、パークのカメラにバトルの GameObject が映らないように
40. 40/74 機能的な実現の目途はたった クライアント描画で バトル配信の仕組みは作れそう！ もちろん 課題も …
41. 41/74 パークのキャラ表示の目標 パークに求められたこと たくさんのキャラを表示したい ワイワイ感の演出のために重要 パークの場合、 1 つの空間に100 人接続するが 可能な限り画面に表示したい！
42. 42/74 パークのキャラ表示の目標 パークに求められたこと たくさんのキャラを表示したい 配信のバトルもパークで動かす バトル配信の最適化 が必須 NEW ・バトル配信のためにキャラの表示数は減らせない ・モデルの品質も下げたくない
43. 43/74 バトル配信をパークで動かすために 最初に、どれくらい削れば実現できるのかを検討 12ms 500MB 100MB 2ms 処理負荷 メモリ消費 通常バトルの場合 バトル配信の目標 上記の目標の範囲内であれば、 パークの処理負荷・メモリ消費が増えても、スマホで動かせる
44. 44/74 バトル配信の実現に向けて 通常バトルの画面品質を維持したまま実現は不可能 配信バトルの描画品質や仕様を調整 ・ 3D 背景やプレイヤーキャラの Spine を静止画に ・画面やカードイラストの解像度を落とす ・ポストプロセスのカット ・手札などの 3D モデルを簡易化 ・バトルエフェクトの種類削減
45. 45/74 バトルの描画処理の最適化 カメラ数の削減 CPU 負荷の削減 描画順の不具合の発生 ポストプロセスのカットやエフェクトの種類を 削減したことで統合可能となった。 最後はオフセット調整で地道に解決 ベースカメラ バトルのカメラスタック UI カメラ 盤面・手札カメラ 画面演出カメラ エフェクトカメラ 統合 メリット デメリット
46. 46/74 パークの負荷計測の方法 キャラ移動 し続ける より実際に近い状況で計測したい 計測 配信用に バトル開始 パーク満員の状態で計測 リアルタイムサーバーとの通信などキャラが移動しているときの負荷も反映 パークは 100 人入るため、手動では不可能 プレイヤー作成 パーク入場 計測のための手順 自動化が必要
47. 47/74 DFrame による自動操作 DFrame キャラ移動 し続ける 計測 配信用に バトル開始 プレイヤー作成 パーク入場 C# でテストシナリオを書ける分散負荷テストフレームワーク 元々サーバーの負荷試験で利用していたものを流用 DFrame でテストシナリオを実装して、計測時に実行するだけに Dframe : https://github.com/Cysharp/DFrame/ この部分を自動化 計測のための手順
48. 48/74 フレームレート計測の改善 バッテリー温度上昇による影響を考慮した計測を行いたい フレームレートの変化のグラフを自動生成 実機でCSV 出力 CIでグラフ化 結果を自動ポスト ・ FPS ・ CPU 処理時間 ・ バッテリー温度 （ Android のみ） iOS の温度はlibimobiledevice を 使って Mac で取得（グラフ化は未対応） フレームレート変化が確認・比較しやすくなった libimobiledevice : https://libimobiledevice.org/
49. 49/74 メモリ消費計測の効率化 MemoryProfiler の結果を CSV 出力できる仕組みを作成 画面品質のどこを調整すると効果的か、試行錯誤できた 各項目の数値を書き出したい
50. 50/74 バトル配信もスマホで動作 以上のような取り組みで パークの品質を落とさずバトル配信を実現できた
51. 51/74 まとめ パークの要件の実現と今後の拡張への対応のために MagicOnion を採用した MagicOnion の活用例としてバトル配信機能を紹介 最適化と負荷計測しやすい環境の整備により、 パークの品質を落とさず、バトル配信を実現できた
52. 52/74 4. シャドバ WB 開発事例～バトル～
53. 53/74 アジェンダ 1. カードゲームの開発について 2. シャドバからシャドバ WB へ バトルロジックのサーバー移行 3. バトルロジックのサーバー移行結果 4. サーバー移行を活かしたシャドバ WB での開発
54. 54/74 シャドバ WB のカードゲームの概要 １対１ で行う ターン制のバトル 対人戦 AI戦 両方が存在
55. 55/74 デジタルカードゲームの開発方針 非公開情報（相手の手札、デッキ情報など） を不正に取得 相手視点で非公開情報を送信しない 対戦相手に不要な疑念を抱かせないため 不正対策は必須 前提 ランダム処理の不正操作 ・好きなカードをドロー ・ランダムな能力のコントロール 乱数の算出が適正か検証 公平性の担保が必要 クライアント改ざんによる 不正処理 通信パラメータの解析 による 情報の不正取得
56. 56/74 シャドバのカードバトル実装 バトルロジックを クライアント側、サーバー側両方で保持 クライアント側で主に保持している機能 ・カード能力 ・ソロプレイ時の敵 AI ・制限時間 ・切断による勝敗判定 など UX向上のため
57. 57/74 シャドバでの課題 バトルロジックがクライアント側にもあることで … 不正対策のフローが煩雑 AIの思考 思考速度が端末スペックに依存 負荷が発熱につながるケースも ①自分と対戦相手、サーバーで非公開 情報を意識した通信をしながら 整合性の検証をする必要 ②相手の通信状況が自身にも影響
58. 58/74 シャドバ WB での開発 シャドバ運用中に検討もされたが、運用中の特大改修は厳しかった サーバーにバトルロジックを移行 →バトルロジックと演出ロジック が分離 MagicOnion を採用 バトルロジックを クライアントから 完全にサーバーへ移行 シャドバでは Node.js で作っていたバトル部分も 再設計が必要
59. 59/74 処理の流れ（シャドバ） クライアントの通信ベース ①操作した結果の カード能力処理 ②操作情報をサーバーに送信 ③サーバー側でカード情報 検証 ④カード操作情報を相手に送信 ⑤操作した結果の カード能力の処理 ⑥操作結果のカード能力の処理結果送信 ⑦自分と相手クライアントの処理結果 検証 処理が多く煩雑 … 自分クライアント ①カード能力処理 相手クライアント ⑤カード能力処理 ② ⑥ ④ 処理結果の通信 カードを手札から場に出す操作 Node.js サーバー ③検証 ⑦検証 カード 操作の通信
60. 60/74 カード能力処理をサーバーに移動 処理を減らしシンプルに 処理の流れ（シャドバ WB ） ①カード操作情報をサーバーに送信 ②操作した結果 カード能力の処理 を実行し 再生すべき演出の情報を作成 ③それぞれの クライアント へ送信 演出を再生 相手クライアント ③計算結果送信 MagicOnion サーバー ②カード能力処理 カードを手札から場に出す操作 ①カード 操作の通信 自分クライアント
61. 61/74 処理の流れ（シャドバ WB ） 処理を減らしシンプルな流れに 自分クライアント 相手クライアント ①カード 操作の通信 ③計算結果送信 MagicOnion サーバー ②カード能力処理 自分クライアント ①カード能力処理 相手クライアント ⑤カード能力処理 ② ⑥ ④ 処理結果の通信 Node.js サーバー ③検証 ⑦検証 カード 操作の通信
62. 62/74 バトルロジック移行の結果 不正対策のフローが簡潔に AIの思考 端末のスペックによらず安定化 →AIアドバイス も可能に ①実装コストの低減 ②相手の通信状況に関係なく バトルを進行可能 良かった点 シャドバ課題点の解消 移行前の課題
63. 63/74 バトルロジック移行の結果 カードを操作した時の処理に サーバー通信が必要 単純にカード操作時に通信処理を入れると通信待ちで手触り感が悪化 気持ちいいテンポ感、心地よい操作感は 何度もカードをプレイする上でとても重要 新たな課題 通信を挟むことによる UXの低下
64. 64/74 手触りを良くするために 通信による待ちが発生 UI やカードで反応に遅れ カードや UI の当たり判定を 可視化して明確に 通信などの処理が 妨げになっているか確認して改善 バトルロジックの計算結果を 得るために通信による待ちが発生 演出が止まったように見せないよう 最大限最適化 課題として これらをクリアした上で演出のテンポ感や UI の手触りを調整
65. 65/74 手触りを良くするために 操作 通信 開始 計算結果を 再生 サーバー側が計算 カードの演出再生 カードを選択 選択処理の反映 アニメーション演出で 通信待ちを調整
66. 66/74 手触りを良くするために シャドバ シャドバ WB 通信を感じさせない上で演出を調整してテンポ調整 同じ動作を比較
67. 67/74 サーバー移行で得られた他メリット • カードゲームのテストプレイの効率化 • カード能力の自動デバッグの高速化 • カードマスターの整理が可能に
68. 68/74 テストプレイの効率化 開発環境ではブラウザでもカード操作できる クライアントの演出対応を待たずにカードが使用可能 バトルサーバー 通信パラメーター検証 切断による勝敗処理など カード能力 ロジック クライアントアプリ Web ブラウザ ブラウザのツール
69. 69/74 カード能力の自動デバッグの高速化 開発中のカード能力の調整コストを低減 2 ヶ月間隔の新カードパックリリースに貢献 カード能力ロジックがサーバー側で完結 クライアント 抜き で自動デバッグ サーバーで自動操作 1 バトル 10 ミリ秒程度 クライアントで自動デバッグ 開発端末で自動操作 1 バトル 数分 シャドバ開発時 シャドバ WB 開発時
70. 70/74 カード能力のマスター の整理 カード能力のマスター は運用が長くなるにつれ 肥大化 カラム・ csv 記述が複雑化 70 カラム以上 … 600 文字以上の記述… 能力と演出に 関する記述が混在 カードマスターも 分割！ サーバーとクライアントで カード能力処理と演出処理が分離 発動ルールに一貫性が必要で システム的でシンプルにしやすい カード能力 カードの見た目 演出 見た目やテンポ感にこだわるため、 能力に応じて独特なパラメータが生まれやすい
71. 71/74 まとめ MagicOnion 採用に伴い バトルロジックを クライアントからサーバーに移した サーバーに移すことで不正対策などの要件 を満たしつつ シンプルな構造に 移せた サーバーに移したことで 自動デバッグなども効率化 することができた
72. 72/74 まとめ
73. 73/74 本セッションのまとめ Cygames のスマホゲームにおける クライアント部分技術設計 『 Shadowverse 』 の後継タイトル 『 Shadowverse:Worlds Beyond 』 における開発事例 バトル パーク
74. 74/74