【DeNATechCon2024】大規模IPゲーム開発のDeNAが挑むMirrativライブゲーミング

2.4K Views

February 29, 24

スライド概要

このセッションでは、私たち DeNA が Mirrativ のライブゲーミングという新たな領域へチャレンジし得られた知見について紹介します。スマートフォン向けゲームのパイオニアとしての経験やこれまでの大規模開発の知見を活かしながら、全く新しいライブゲームのフレームワークと技術を探究しました。

ミラティブと DeNA が共同開発した「プリンセス&ナイト」での事例を交えつつ、Mirrativ やライブゲーミングの概要や、進める過程でぶつかった多くの技術的課題をどのように解決していったのか、アーキテクチャや構成技術を合わせて詳しく紹介します。私たちの経験が、ゲーム分野における新しい挑戦を考えている開発者の方々の参考になれば幸いです。

profile-image

DeNA が社会の技術向上に貢献するため、業務で得た知見を積極的に外部に発信する、DeNA 公式のアカウントです。DeNA エンジニアの登壇資料をお届けします。

シェア

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

⼤規模IPゲーム開発のDeNAが挑むMirrativライ ブゲーミング © DeNA Co., Ltd.

2.

⾃⼰紹介 ⼭下 駿 ゲームサービス事業本部開発事業部第⼀技術部テクノ ロジー推進第⼀グループ 2019年新卒で DeNA ⼊社 ⻑期運営タイトルのクライアントエンジニア 横断チームでの技術基盤の開発/提供 新規タイトルの機能モック作成など 現在はミラティブさんとの共同の取り組みである 『プリンセス&ナイト』のリードエンジニア © DeNA Co., Ltd. 2

3.

アジェンダ ● ● ● ● ● ● © DeNA Co., Ltd. これまでのDeNAのゲーム開発と今 新たな取り組みとなる『プリンセス&ナイト』とは Mirrativ/ライブゲーミングとは 本取り組みを進める上でぶちあたった技術的な課題 課題をどのようなアプローチで解消していったか まとめ 3

4.

これまでのDeNAのゲーム開発と今 © DeNA Co., Ltd. 4

5.

これまでのDeNAのゲーム開発と今 ゲームサービス事業本部の概要 ● ● ● 国内を開発‧運営の拠点とし、⾃社内製および協業でのゲーム開発‧運営を⾏う部⾨ ⻑期に楽しまれるアプリゲームやブラウザゲームを多数提供 サービスとしてゲームを開発‧運営する特⾊を踏まえ、2023年4⽉に現在の組織名に ゲームサービス事業本部で⼿掛けるタイトル例 © DeNA Co., Ltd. 5

6.

これまでのDeNAのゲーム開発と今 DeNAのゲーム事業の歩み 2009〜 怪盗ロワイヤルを Mobageで提供する 等、ゲームの提供 を開始 © DeNA Co., Ltd. 2013〜 2015〜 モバイルブラウザ 任天堂との業務‧資 ゲームからアプリ 本提携や、 ポケモ へシフト ンとの協業作品の提 供をはじめ、パート ナーシップを強化 2020〜 現在 グローバル市場に向 従来戦略に加えて新 けた⼤型IP中⼼のパ たなチャレンジを推 イプライン戦略を推 進 進 6

7.

これまでのDeNAのゲーム開発と今 ゲームサービス事業本部が⽬指すポートフォリオ 従来からの戦略 グローバル市場に向けた ⼤型IPを中⼼としたパイプライン ● ● ● © DeNA Co., Ltd. 多くのパートナー企業との協業 実績はDeNAの強みのひとつ ⼤型IPとのパートナーシップに よってヒット創出を狙う⽅針は 今後も継続 ゲームサービス事業本部におい ても来年度以降の新規タイトル を仕込み中 新たなチャレンジ 「運営⼒」を活かした 「⼩規模×フィードバック重視」の開発 ● ● の開発 開発や運営のコストが増加傾向の 市場において開発リスクを低減 DeNAの強みを活かした新たな開 発⽅針を通じた、持続的な事業運 営‧組織⼒の基盤構築 7

8.

これまでのDeNAのゲーム開発と今 ゲームサービス事業本部が⽬指すポートフォリオ 従来からの戦略 グローバル市場に向けた ⼤型IPを中⼼としたパイプライン ● ● ● © DeNA Co., Ltd. 多くのパートナー企業との協業 実績はDeNAの強みのひとつ ⼤型IPとのパートナーシップに よってヒット創出を狙う⽅針は 今後も継続 ゲームサービス事業本部におい ても来年度以降の新規タイトル を仕込み中 新たなチャレンジ 「運営⼒」を活かした 「⼩規模×フィードバック重視」の開発 ● ● の開発 開発や運営のコストが増加傾向の 市場において開発リスクを低減 DeNAの強みを活かした新たな開 発⽅針を通じた、持続的な事業運 営‧組織⼒の基盤構築 8

9.

これまでのDeNAのゲーム開発と今 本⽇ご紹介する『プリンセス&ナイト』はDeNAのゲーム開発におけ る新たなチャレンジ⽂脈に属した取り組みの⼀つとなります ※これ以外にも多くの取り組みを推進中! 『プリンセス&ナイト』を開発するにあたって、どういった課題にぶ つかり、どう解決したかをお話できればと思います。 © DeNA Co., Ltd. 9

10.

新たな取り組みとなる『プリンセス&ナイト』とは © DeNA Co., Ltd. 10

11.

新たな取り組みとなる『プリンセス&ナイト』とは CONFIDENTIAL © DeNA Co., Ltd. 11

12.

新たな取り組みとなる『プリンセス&ナイト』とは 本サービスはミラティブ社とDeNAの共同開発プロジェクトです パブリッシャー ライブゲーム開発 / 運⽤実績から培った様々 な知⾒と、PF技術を提供 共同開発パートナー 豊富なモバイルゲーム開発経験と⾼い技術⼒ により、「Mobile x WebGL」の厳しい制約 の中で開発難易度の⾼いゲーム性を実現 『プリンセス&ナイト』はMirrativ上で遊べるライブゲーム(※)として 2023年4⽉末にリリースいたしました ※実は2024年1⽉にGoogle Play/App Storeでもアプリ版をリリース済です © DeNA Co., Ltd. 12 12

13.

新たな取り組みとなる『プリンセス&ナイト』とは コンセプト 四⽅⼋⽅から襲い掛かるモンスターの⼤群から配信 者、参加者、視聴者全員で⽣き残るゲーム 操作は移動のみ+⾃動攻撃 仲間とのコンビネーションや武器の特性に合わせて戦 いが変化する奥深い設計 配信者1名+視聴者参加2名の3名マルチプレイ 視聴者全員が攻撃⽀援や回復⽀援で参加可能 通常のライブストリーミング同様に、配信者と視聴者 がコミュニケーションを取りながら遊べます © DeNA Co., Ltd. 13 13

14.

Mirrativ/ライブゲーミングとは © DeNA Co., Ltd. 14

15.

⾃⼰紹介 菅⾕ 琢磨 株式会社ミラティブ Unityグループマネージャー DONUTS に新卒で⼊社し複数のリズムゲーム開発に携わる。新 規開発と運営の両⽅でリードエンジニアを経験した後、2020年 にミラティブにジョイン。現在は Unity グループマネージャー として、Mirrativ 内のアバター機能「エモモ」や「ライブゲー ム」の開発‧運⽤に⼒を注ぐ。 © DeNA Co., Ltd. 15

16.

Mirrativ/ライブゲーミングとは 今⽇話すこと © DeNA Co., Ltd. ● プロダクト「Mirrativ」の紹介 ● Mirrativのライブゲーミング ● ライブゲーミングを⽀える技術 16

17.

Mirrativ/ライブゲーミングとは プロダクト 「Mirrativ」の紹介 © DeNA Co., Ltd. 17

18.

Mirrativ/ライブゲーミングとは スマホでかんたんにアバター配信 ができる顔出しナシのゲーム配信 プラットフォーム 共通の趣味=ゲームを通じて ⼈と⼈とがつながり、わかりあうための 「居場所」を創っています。 © DeNA Co., Ltd. 18

19.

Mirrativ/ライブゲーミングとは ゲーム配信コミュニティの性質 配信プラットフォームであり ながらアクティブユーザーの 約30% が配信者というSNS的 な配信者⽐率が特徴です。 © DeNA Co., Ltd. 19

20.

Mirrativ/ライブゲーミングとは Mirrativのライブゲーミング © DeNA Co., Ltd. 20

21.

Mirrativ/ライブゲーミングとは ゲーム配信が中核にあるのがMirrativの特徴。 友だちの家でいっしょにゲームを遊んでいるようなコミュニティ空 間を作っています。 © DeNA Co., Ltd. 21

22.

Mirrativ/ライブゲーミングとは ライブゲーミングとは、 配信中のゲームに視聴者が介⼊できる ゲームとライブ配信が融合した次世代のゲーム体験です。 © DeNA Co., Ltd. 22

23.

Mirrativ/ライブゲーミングとは ライブゲーミングによる体験 © DeNA Co., Ltd. 23

24.

Mirrativ/ライブゲーミングとは 視聴者のコメントやギフトなどのアクションが ライブ配信中のゲームプレイに介⼊する新しい体験を⽣み出します 視聴者 配信者 ①コメントやギフトが贈られる ③配信者のゲームに介⼊ ②アクション内容を通知 © DeNA Co., Ltd. Mirrativサーバ ゲームサーバ 24

25.

Mirrativ/ライブゲーミングとは ライブゲーミングの例 ギフトでの介⼊ 視聴者から贈られたギフトがリアルタイムにゲームで使えるアイテムになります 視聴者 © DeNA Co., Ltd. 配信者 ギフトを贈ると配信者にお助けアイテムが届く 25

26.

Mirrativ/ライブゲーミングとは ライブゲーミングの例 視聴者の参加 マルチプレイのゲームでは配信者が視聴者をその場で誘って⼀緒に遊べます。 © DeNA Co., Ltd. 26

27.

Mirrativ/ライブゲーミングとは ライブゲーミングの可能性 © DeNA Co., Ltd. 27

28.

Mirrativ/ライブゲーミングとは 最新型のソーシャル体験 視聴者が配信に介⼊することでオンライン上の交流が⽣まれる 常時接続時代の新しいソーシャルゲームです。 © DeNA Co., Ltd. 28

29.

Mirrativ/ライブゲーミングとは 誰かのためにお⾦を使うゲーム市場 視聴者が配信に装備アイテムやガチャ等をギフトできるライブゲームは、これまであ りそうでなかった「誰かのためにお⾦を使うゲーム市場」です。 © DeNA Co., Ltd. 29

30.

Mirrativ/ライブゲーミングとは 低開発費で、⾼い売上可能性 開発費は1,500万円〜6,000万円でありながら、ユーザー同⼠のギフトの贈りあいを活 性化させる構造であるためソーシャルゲームに劣らない平均課⾦額が期待できます。 © DeNA Co., Ltd. 30

31.

Mirrativ/ライブゲーミングとは ライブゲーミングを ⽀える技術 © DeNA Co., Ltd. 31

32.

Mirrativ/ライブゲーミングとは ライブゲームの全体構成 ● ライブゲーム on Mirrativ ○ ● ゲームサーバー ○ ● MirrativサーバーやWebGLゲームと連携する Mirrativサーバー ○ © DeNA Co., Ltd. Mirrativアプリ上でWebGLゲームを遊びながら配信する ライブゲームにMirrativの機能を提供する 32

33.

Mirrativ/ライブゲーミングとは ギフトを送る 視聴者からギフトが送られると各種サービスが連携して動き、配信者のライブゲームに届く © DeNA Co., Ltd. 33

34.

Mirrativ/ライブゲーミングとは ゲームに視聴者を招待する 配信者が視聴者を招待して、 視聴者と⼀緒に同じゲームで遊べる © DeNA Co., Ltd. 34

35.

Mirrativ/ライブゲーミングとは 開発の領域と特徴 ● Mirrativの機能はミラティブ社が開発‧提供 ● ライブゲームはDeNA様などのライブゲーム開発パートナーが開発 ○ ● © DeNA Co., Ltd. ゲームごとに開発しやすい⾔語やライブラリが使⽤できる Mirrativサーバーはライブゲームサーバーとのみ通信する ○ Mirrativサーバーとライブゲーム(WebGLゲーム)は直接通信しない ○ 独⽴性を⾼める作り 35

36.

Mirrativ/ライブゲーミングとは Mirrativの提供するライブゲームの機能 ● ● © DeNA Co., Ltd. MirrativライブゲームAPIの提供 ○ 視聴者の招待 ○ 視聴者の視聴画⾯上でゲーム画⾯を起動する ○ コメント投稿 ○ コメントやギフトなどのリアルタイム情報を受け取る(Webhooks) Mirrativ特有の機能や機会の提供 ○ ライブゲームとコラボしたエモモ(Mirrativ内の3Dアバター)のアイテム ○ 配信ランキングなどのMirrativ内イベントの実施 36

37.

Mirrativ/ライブゲーミングとは Mirrativアプリの構成 ● 配信機能やアプリ内UIはネイティブ製 ○ iOS:Swift + ReplayKit 2 + HaishinKit ○ Android:Kotlin + MediaProjection ● アプリ内で動かすライブゲームはUnity製 © DeNA Co., Ltd. ○ WebGL ○ (Unity as a Library) 37

38.

Mirrativ/ライブゲーミングとは WebGLゲーム ● WebGL ○ ウェブブラウザでGPUを利⽤したリッチコンテンツを表⽰する技術 ○ UnityでもWebGLゲームが作れる ■ © DeNA Co., Ltd. Unity6からUnity Webとしてモバイルの動作を公式サポート 38

39.

Mirrativ/ライブゲーミングとは WebGLゲームの構成イメージ ● MirrativアプリのWebView上でWebGLゲームを動かす ● モバイルゲームのガワネイティブと同じ仕組み WebGLゲーム WebView Mirrativアプリ © DeNA Co., Ltd. 39

40.

Mirrativ/ライブゲーミングとは WebGL採⽤の背景 ● ライブゲーム開発パートナーが簡単に作成しリリースできる環境が必要 ● 開発のしやすさ‧⾃由度の⾼さからWebGLの⽅式を採⽤ ● 様々な企業と開発中 ● ミラティブ内製での開発も実施 © DeNA Co., Ltd. 40

41.

Mirrativ/ライブゲーミングとは WebGLゲームの特徴 ● メリット ○ ⾃由度が⾼い ■ WebViewからURL指定でゲームを起動 ● ■ Mirrativアプリとゲームとを分離させやすい ゲーム内容‧表現‧開発⽅法が⾃由 ● デメリット © DeNA Co., Ltd. ○ ブラウザベースのためパフォーマンスが出にくい ○ WebGLに関する知⾒や情報が少ない 41

42.

本取り組みを進める上でぶちあたった技術的な課題 © DeNA Co., Ltd. 42

43.

本取り組みを進める上でぶちあたった技術的な課題 そもそもUnityでのWebGLビルドはどういったものか © DeNA Co., Ltd. 43

44.

本取り組みを進める上でぶちあたった技術的な課題 UnityのWebGLビルド概要 ざっくり表現すると 「iPhone 5sやiPhone 6あたりでネイティブのゲームを作る感覚」 © DeNA Co., Ltd. 44

45.

本取り組みを進める上でぶちあたった技術的な課題 UnityのWebGLビルド概要 ● Unity 2021.3ではマルチスレッドが使えない ○ Unity 2022.2からExperimentalでC/C++スレッドが使えるようになる が、C#スレッドはまだ使えない… ○ © DeNA Co., Ltd. ※シングルスレッドの⾮同期処理は使えるので、UniTaskは使える 45

46.

本取り組みを進める上でぶちあたった技術的な課題 UnityのWebGLビルド概要 ● Resourcesやビルトインシーンは単⼀ファイル(.data)にパックされ、アプ リ起動時にダウンロード→⾮圧縮状態でメモリに読み込まれて常駐する ● アセットバンドルは他のプラットフォームと同じように使うことができる ○ アセットバンドルもResourcesと同じく⼀旦メモリに全部読み込まれ るが、Resourcesと違ってアンロードすることができる ● UnityはIndexedDBにデータキャッシュやPlayerPrefsを保存する ○ 揮発性が⾼いため、本来はPlayerPrefsに保存するような重要でないオ プション設定等もサーバに保存するほうが好ましい © DeNA Co., Ltd. 46

47.

本取り組みを進める上でぶちあたった技術的な課題 UnityのWebGLビルド概要 ● ● WebGLはOpenGL ESの機能に基づいており、 ○ WebGL 1.0はほぼOpenGL ES 2.0 ○ WebGL 2.0はほぼOpenGL ES 3.0 テクスチャの圧縮フォーマットはデバイスに依存 ○ ● © DeNA Co., Ltd. モバイル限定であれば殆どの端末でASTCが使える URP(Universal Render Pipeline)が使える 47

48.

本取り組みを進める上でぶちあたった技術的な課題 UnityのWebGLビルド概要 ● モバイルブラウザの正式サポートはまだされていない(Unity 6を予定) ○ Unity 2021.3以下だとInputFieldが動かない… ■ WebGLInput(OSS)を導⼊すれば動く ● ● ※『プリンセス&ナイト』ではDebugMenuのみで使⽤ ⼀部のiPadはuserAgentに’iPad’が含まれない ○ 「’macintosh’が含まれてタッチ⼊⼒が可能なら恐らくiPadだと思う」 というような判定で対応 © DeNA Co., Ltd. 48

49.

本取り組みを進める上でぶちあたった技術的な課題 UnityのWebGLビルド概要 ● iOS(Safari)は使えるメモリがかなり少ない ○ 数百MBオーダーの世界 ○ コードサイズが⾺⿅にならない ○ ■ ストリップレベルをHighにする ■ 不要なパッケージを削除する ■ link.xmlはスコープを最⼩限にする 常駐リソースも⾺⿅にならない ■ © DeNA Co., Ltd. →極限までアセットバンドル化を⾏う 49

50.

本取り組みを進める上でぶちあたった技術的な課題 『プリンセス&ナイト』でぶち当たった技術的な課題 © DeNA Co., Ltd. 50

51.

本取り組みを進める上でぶちあたった技術的な課題 ライブゲームの特性 ● 前述の通り、メモリ的な制約やパフォーマンス⾯がそもそもWebGLという環 境要因できついのに加えて、ライブゲーミングでは配信が裏で動いているため その負荷が乗ることを前提にする必要がある。 © DeNA Co., Ltd. 51

52.

本取り組みを進める上でぶちあたった技術的な課題 ゲームの特性 ● 更に... ⼤量の敵、攻撃、経験値等が出る © DeNA Co., Ltd. 52

53.

本取り組みを進める上でぶちあたった技術的な課題 ぶちあたった課題まとめ ● メモリの制約が⾮常に厳しい(特にiOS) ● 通常のネイティブアプリと⽐較してWebベースであるが故にパフォーマン スをだしにくい環境 ● 配信が裏で動くためその負荷が乗ってくる状態 ● 上記の中で、物量の出るゲームを作る必要があった 限られた開発期間の中、どうすればゲーム性を実現できるか © DeNA Co., Ltd. 53

54.

課題をどのようなアプローチで解消していったか © DeNA Co., Ltd. 54

55.

課題をどのようなアプローチで解消していったか ⽅針 「要件を決め、その要件に沿ってカリカリにチューニングされたシステムを構築する」 具体的には ● ● © DeNA Co., Ltd. パフォーマンスファーストのグラフィックスシステムのスクラッチでの実装 グリッドベースの2Dコリジョンシステムのスクラッチでの実装と最適化 55

56.

本取り組みを進める上でぶちあたった技術的な課題 なぜスクラッチ? © DeNA Co., Ltd. ● Unityというグラフィックスシステムもコリジョンシステムも⼗分な性能のも のがすでにビルトインされている ● ⼀⽅でWebGLという未知の環境下 ○ Unityシステムに乗っかって⼗分なパフォーマンスが出なかった場合に軌 道修正が困難 ● インパクトが⼤きいであろうグラフィックス、コリジョンについては最初から スクラッチで実装する⽅針に ○ ミニマムかつコントローラブルなシステムを構築 ○ 実際にパフォーマンスを⽐較した訳では無い 56

57.

課題をどのようなアプローチで解消していったか パフォーマンスファーストのグラフィックスシステムのスクラッチ での実装と最適化 © DeNA Co., Ltd. 57

58.

課題をどのようなアプローチで解消していったか グラフィックスシステム:⽅針決め 要件(やりたいこと‧やらないこと)の明確化 ● ● 2Dのスプライトベース ○ スプライト=四⾓形ポリゴンに絵を貼り付けたもの ○ 3Dはやらない ⼤量のスプライトを出したい ○ 数百〜数千のアニメーションするスプライト ● ⾼度な表現は⾏わなくても良い ● ⼤量のコンテンツ制作は⾏わない ○ 現在はほぼ三桁のキャラクター、三桁のエフェクト、⼆桁のマップ... (今考えると⼗分多かった...) © DeNA Co., Ltd. 58

59.

課題をどのようなアプローチで解消していったか グラフィックスシステム:⽅針決め ○ ⼤量に物量を出したい ■ ○ 制作物量は少な⽬ & エンジニアが組み込みまで⾏う ■ ○ カリカリチューニングが出来る余地が欲しい UnityEditor上でのデータ編集にこだわる必要はない WebGLビルドが未知数 ■ 掘り下げる&リカバーする時間は無いので、できるだけシンプルに使いたい ⇒全てを把握できる独⾃描画システムを作ることに © DeNA Co., Ltd. 59

60.

課題をどのようなアプローチで解消していったか グラフィックスシステム:描画システム全体像 描画システムには以下の主なサブシステムがある ● ● ● ● ● ● ● © DeNA Co., Ltd. CharacterSystem EffectSystem MapSystem DamageDisplaySystem ItemSystem Renderer AnimationSystem 主要なデータは以下がある ● ● ● SpriteAtlas(テクスチャ) SpriteAnimationData(アニメーションデータ) ドット絵の無劣化圧縮 60

61.

課題をどのようなアプローチで解消していったか グラフィックスシステム:CharacterSystem ● キャラクターを表⽰するシステム (操作キャラクター、敵キャラクター) ● 各キャラクターは複数のアクション(Walk、 Idle、Victory、Fatal等)を持っており、それ ぞれのアニメーションがある ● ゲーム要件により、左右反転、半透明表⽰ (ディザによる疑似半透明)なども⾏う © DeNA Co., Ltd. 61

62.

課題をどのようなアプローチで解消していったか グラフィックスシステム:Renderer ● スプライトをレンダリングする仕組みを提供する ○ 他のサブシステムの基盤的役割 ○ 不必要な処理を省いて処理負荷が低減できるように努めた ■ ○ レンダリングはGameObjectベースではなく、Graphics APIを使って⾏った ■ ● スプライトを回転する物/しない物で分けて管理したり 参考:【Unity】RenderMesh API で⼤量のオブジェクトを描画してみよう レンダリングパイプラインを管理する © DeNA Co., Ltd. ○ 描画レイヤー‧描画順の管理‧視錐台カリングなどもここで⾏う ○ ポストエフェクトもここで実装する予定だったが、メモリの都合などにより断念 62

63.

課題をどのようなアプローチで解消していったか グラフィックスシステム:SpriteAtlas(テクスチャ) ● 複数素材をパックしたTextureAtlas(パックテクスチャ)を、更にTexture2DArray(テクスチャ配 列)にパックしたもの ○ ● ArrayにすることでMaterialの変更なしで複数Atlasを参照できる 1Atlasの⼤きさを255x255にすることで、byte精度のUVでピクセル単位の指定が出来る © DeNA Co., Ltd. 63

64.

課題をどのようなアプローチで解消していったか グラフィックスシステム:ドット絵の無劣化圧縮 ● 当初、テクスチャ圧縮は出来るだけ⾼品質に 元絵 レンダリング(ASTC 4x4) するためASTC 4x4 を選択した ● 悪くはないが劣化は感じられる... ○ ⽩⽬があふれる ○ ⾸の⾊化け ○ 髪の⽑に雑味が ○ 王冠のハイライト ○ 全体的な⾊味の変化 ■ ● コントラストが落ち気味 キャラは魅⼒の⼀つなので妥協したくない... © DeNA Co., Ltd. 64

65.

課題をどのようなアプローチで解消していったか グラフィックスシステム:ドット絵の無劣化圧縮 ● ● IndexColor(8bit)描画を実装 ○ 原理上劣化無し ○ 4bitColorは⾊数が⾜りなかった 元絵 レンダリング(IndexColor) CLUT(ColorLookUpTable)テクスチャ Indexテクスチャ の⽣成の仕組みを構築 ● ASTCとほぼ同容量のデータで 満⾜いく表現が出来た © DeNA Co., Ltd. 65

66.

課題をどのようなアプローチで解消していったか グラフィックスシステム:最適化したポイント DrawCall数の低減について ● WebGLの処理性能が未知数(特にCPU)だったので、出来る限り低負荷にしたかった→DrawCall数を 出来る限り少なくしたい そこで ● SpriteAtlas(Texture2DArray)で、同じような描画を⾏うスプライト群を1テクスチャ(≒1マテリア ル)に詰め込み ● 同⼀マテリアルのオブジェクトは1SubMeshに含まれるように頂点データを構築することで、出来るだ け少ないDrawCallで描画を⾏った(DynamicBatchingのような考え⽅) © DeNA Co., Ltd. 66

67.

課題をどのようなアプローチで解消していったか グラフィックスシステム:最適化したポイント DrawCall数の低減について ● 理想的な状態では 6 DrawCall で画⾯描画(UI除く)が完了する ○ © DeNA Co., Ltd. キャラクター 67

68.

課題をどのようなアプローチで解消していったか グラフィックスシステム:最適化したポイント DrawCall数の低減について ● 理想的な状態では 6 DrawCall で画⾯描画(UI除く)が完了する © DeNA Co., Ltd. ○ キャラクター ○ エネミー 68

69.

課題をどのようなアプローチで解消していったか グラフィックスシステム:最適化したポイント DrawCall数の低減について ● 理想的な状態では 6 DrawCall で画⾯描画(UI除く)が完了する © DeNA Co., Ltd. ○ キャラクター ○ エネミー ○ アイテム 69

70.

課題をどのようなアプローチで解消していったか グラフィックスシステム:最適化したポイント DrawCall数の低減について ● 理想的な状態では 6 DrawCall で画⾯描画(UI除く)が完了する © DeNA Co., Ltd. ○ キャラクター ○ エネミー ○ アイテム ○ マップ 70

71.

課題をどのようなアプローチで解消していったか グラフィックスシステム:最適化したポイント DrawCall数の低減について ● 理想的な状態では 6 DrawCall で画⾯描画(UI除く)が完了する © DeNA Co., Ltd. ○ キャラクター ○ エネミー ○ アイテム ○ マップ ○ エフェクト 71

72.

課題をどのようなアプローチで解消していったか グラフィックスシステム:最適化したポイント DrawCall数の低減について ● 理想的な状態では 6 DrawCall で画⾯描画(UI除く)が完了する © DeNA Co., Ltd. ○ キャラクター ○ エネミー ○ アイテム ○ マップ ○ エフェクト ○ ダメージ表⽰ 72

73.

課題をどのようなアプローチで解消していったか グラフィックスシステム:最適化したポイント DrawCall数の低減について ● ● 理想的な状態では 6 DrawCall で画⾯描画(UI除く)が完了する ○ キャラクター ○ エネミー ○ アイテム ○ マップ ○ エフェクト ○ ダメージ表⽰ 上記のそれぞれが 1 SubMesh になっている © DeNA Co., Ltd. 73

74.

課題をどのようなアプローチで解消していったか グラフィックスシステム:まとめ 『プリンセス&ナイト』では ● 未知の環境 ● ハイパフォーマンス要求 ● 汎⽤的なシステムである必要はない 等の条件が重なり、独⾃の描画システムを構築するに⾄った。 結果として、「⼤量の敵や経験値の表⽰」と「グラフィックの品質」を⼀定両⽴できた。 © DeNA Co., Ltd. 74

75.

課題をどのようなアプローチで解消していったか グラフィックスシステム:まとめ が、基本的には 既存の仕組みでは⽬標を達成できそうにないor不確実性が⾼すぎて既存 の仕組みに乗るだけではリスクが⾼いなどやむにやまれない事情がある 場合にのみ 「独⾃の描画システムを作る」という選択をする⽅が良いと思います © DeNA Co., Ltd. 75

76.

課題をどのようなアプローチで解消していったか グラフィックスシステム:まとめ なぜか? ● ● Unityが既に持っている機能が利⽤できない ○ レンダリングパイプライン(カリング、Zソート) ○ アニメーション ○ パーティクルシステム © DeNA Co., Ltd. 低↓ Editorが役に⽴たない ○ ● ⇒⽣産性‧効率 実⾏しないとシーンが⾒られない Asset‧知⾒‧経験の横展開‧積み上げが難しい 76

77.

課題をどのようなアプローチで解消していったか グラフィックスシステム:まとめ そのためまずは、、、 素直にUnityなどのゲームエンジンに乗ることを第⼀に検討しどうし ても独⾃システムが必要な場合に覚悟を持って取り組みましょう © DeNA Co., Ltd. 77

78.

課題をどのようなアプローチで解消していったか グリッドベースの2Dコリジョンシステムの スクラッチでの実装と最適化 © DeNA Co., Ltd. 78

79.

課題をどのようなアプローチで解消していったか 改めて、ゲーム性について ● © DeNA Co., Ltd. この量をライブゲーム上で処理する必要がある ○ ⼤量の敵 ○ またその敵1体1体が経験値を落とす ○ 経験値もまた当たり判定を持つ 79

80.

課題をどのようなアプローチで解消していったか コリジョンシステム:概要 ● ● フルスクラッチのシングルスレッド2Dコリジョンシステム ○ シングルスレッドなのは、Unity WebGLはC#のマルチスレッド⾮対応のため ○ Unsafeな内部実装で愚直に⾼速化 © DeNA Co., Ltd. GC-less ■ Function Pointer (C#9)も活⽤ コリジョンの種類は実体を持つSubstanceと実体を持たないTriggerの2つ ○ ● ■ Substance同⼠の押し出しに対応 コリジョンレイヤーは8個(レイヤー間での判定有無を個別に設定) 80

81.

課題をどのようなアプローチで解消していったか コリジョンシステム:概要 ● © DeNA Co., Ltd. 対応しているコリジョン形状は3種類のみ ○ ■AlignedBox: 座標軸に沿ったボックス(軽量、⼤体はこれ) ○ ■OrientedBox: 回転に対応したボックス(重い) ○ ●Circle: 円(そこそこ軽い) 81

82.

課題をどのようなアプローチで解消していったか コリジョンシステム:概要 例:グリッドが4分割の場合 *実際のゲームでのサイズと異なります ● グリッドベースのシンプルな空間分割アルゴリズム ○ 1グリッドは64x64ドット ○ 32x32の固定グリッドで管理 ○ グリッド内で総当たり判定を⾏う(例) ■ 0,0 : × ■ 0,1 : × ■ 単⼀グリッドに多数のSubstanceが侵⼊すると × 0,0 0,1 1,0 1,1 × 計算量がやばいことになる © DeNA Co., Ltd. 82

83.

課題をどのようなアプローチで解消していったか コリジョンシステム:概要 64 dots ■グリッド⽤メモリ 2,2 2,3 2,0 2,1 2,2 2,3 2,0 2,1 3,2 3,3 3,0 3,1 3,2 3,3 3,0 3,1 総当りのチェックの対象に 0,2 0,3 0,0 0,1 0,2 0,3 0,0 0,1 ● 実装としてはハッシュテーブルに近い 1,2 1,3 1,0 1,1 1,2 1,3 1,0 1,1 ● 『プリンセス&ナイト』はフィールドが実質無限に広がるが、グ 2,2 2,3 2,0 2,1 2,2 2,3 2,0 2,1 3,2 3,3 3,0 3,1 3,2 3,3 3,0 3,1 0,2 0,3 0,0 0,1 0,2 0,3 0,0 0,1 1,2 1,3 1,0 1,1 1,2 1,3 1,0 1,1 ● グリッドはループして配置される ○ ○ と は座標的には離れているが、同⼀グリッド内 リッドをループさせることでアロケーションなしで判定できる ● プリンセス&ナイトに登場するエンティティの⼤半は姫周辺に⽣ 成されるため、グリッド全体が⼗分に広ければ、ループによる総 当りチェックの増加はあまり発⽣しない。 ※簡略化のため4x4グリッドで表現 © DeNA Co., Ltd. 83

84.

課題をどのようなアプローチで解消していったか 押し出し ● 企画の期待する密度感を出すために、敵同⼠の押し出しが必須 ○ ⼀箇所に集中する敵を、処理負荷を抑えつつ綺麗に 押し出す必要がある © DeNA Co., Ltd. 84

85.

課題をどのようなアプローチで解消していったか 今回の押し出しに求められる要件 ● 敵同⼠が極⼒重ならないこと ● 可変フレームでも結果が安定すること ● 計算負荷が極⼒⼩さいこと ● 企画側の期待する密度感を出せること © DeNA Co., Ltd. 85

86.

課題をどのようなアプローチで解消していったか 押し出し⽅法 ● ● ● 押し出し⼒が2つの当たり判定(AABB)の内接円がめり込んでいる割合で決定される ○ 内接円を⽤いることで処理を簡略化 ○ 2物体の内接円の半径の合計から、2物体の距離を引くことでめり込み量を算出 ○ 2物体の内接円の半径の合計に対するめり込み量の割合で押し出し⼒が線形増加 ○ ⼀定割合以上めり込むと押し出し⼒が増加しなくなる 押し出し専⽤の速度ベクトルに⼒を反映 ○ 優先順位が⾼い⽅が低い⽅を押し出す ○ 同じ場合は半々で⼒を受け取る ○ 優先順位が0の場合は押し出しをスキップ 押し出し⼒100% 押し出し⼒100% 速度ベクトルは毎フレーム位置へ反映、減速 ○ © DeNA Co., Ltd. 押し出し⼒60% 減速は現在の速度×減速⼒×deltaTime 押し出し⼒は線形増加し、 ⼀定割合以上めり込むと、押し出し⼒が増加しなくなる 86

87.

課題をどのようなアプローチで解消していったか 押し出しの⼩話 © DeNA Co., Ltd. 87

88.

課題をどのようなアプローチで解消していったか 押し出しの⼩話 ● リリース直前、特定のステージのFPSが5だと判明した ○ 押し出し不⾜でプレイヤー付近のグリッドに 敵が30~100体近く重なっていた ○ © DeNA Co., Ltd. 急遽押し出しロジックを修正することに 88

89.

課題をどのようなアプローチで解消していったか 急遽、押し出しロジックを修正することに ● 猶予が⼀週間ちょっとだった ● 可変フレームレートで動いてしまっていた ○ 今から修正は難しい!! ○ ただでさえ処理落ちしやすいゲーム。 ○ 低FPSのときに安定しない!! ● 企画側の期待する密度感を損なわない調整が必要 ● たまたま個⼈で似た領域を勉強していたので引き受けたが、 ⾃分がこういった仕組みを作るのが初 ● パラメータが悪いのか、ロジックが悪いのか... 失敗例 © DeNA Co., Ltd. 89

90.

課題をどのようなアプローチで解消していったか 試⾏錯誤の末、先程の実装に落ち着き... ● 重なりが解消された事でワーストケースでの処理負荷が1/10以下に! ● 13FPSくらいならギリ遊べる安定感! ● 企画の期待する密度感も実現できた ● ○ 攻撃のヒット判定は⼤きく ○ 押し出しの判定は⼩さく 特定のステージでの コリジョン周りのメソッド呼び出し回数 初期 改修後 締め切りもギリギリ何とかなった 13FPS時の⾒た⽬ ※13FPSに⾒えないのはgif出⼒のせい ※計測を⾏った際の録画ではない © DeNA Co., Ltd. 90

91.

まとめ © DeNA Co., Ltd. 91

92.

まとめ ● Unity WebGLを使ってモバイルブラウザで物量の出 るゲームを30〜60fpsで動かすためにはCPU‧メモリ 共にドラスティックな最適化が必要だった。(※特に iOSのメモリが厳しい) ● 『プリンセス&ナイト』は敵の数が数百オーダー、ス プライトやコリジョンの総エンティティ数は数千オー ダーに達するが、その物量を捌くためにインスタン ス管理‧コリジョン判定‧レンダリング周り全般を スクラッチ実装し、チューニングの柔軟性を担保で きたことで⽬標を達成することができた。 © DeNA Co., Ltd. ※上の画⾯のコリジョンを可視化した状態↑ 92

93.

まとめ ● 1st DrawCall 対応1:パフォーマンスファーストのグラフィックスシステム ○ レガシーパイプラインベースの専⽤バッチレンダラ ○ Texture2DArrayを⽤いた独⾃のテクスチャパッキング ○ CLUT(ColorLookUpTable)を⽤いたドット絵の無劣化圧縮 ○ etc… 2nd DrawCall Index(8bit) + 3rd DrawCall 4th DrawCall 5th DrawCall CLUT (32bit) = 6th DrawCall SpriteAtlas [256x256x25slice] © DeNA Co., Ltd. 93

94.

まとめ ● 対応2:グリッドベースの2Dコリジョンシステム ○ マルチスレッドやBurstコンパイラが使えないため、 Unsafeな内部実装で愚直に⾼速化 ○ ■ GC-less ■ Function Pointer (C#9)も活⽤ ゲームの空間的局所性を活かした省メモリ設計 ■ ○ ⼀定距離離れたグリッドのメモリを共有 多対多の⾼速な押し出し処理 ■ 低スペック端末でフレームレートが低下して も安定した動作を実現(右の動画) © DeNA Co., Ltd. 13FPS 94

95.

まとめ ● ゲームエンジンが⾮常に強⼒になり、ビルトインのシステムでもかなり使い やすく、パフォーマンスも出るようになってきたのは⾮常に開発側としてはあ りがたいし、どんどん有効活⽤すべき。 ● ⼀⽅で今回の『プリンセス&ナイト』のように環境の限界を攻めていくような ケースにおいては、古よりゲーム開発界隈で培われてきたいわば「レガシー」 と⾔える技術やテクニックが活躍する機会はまだまだある。 ○ そのため最新の技術やエコシステムを追う/使うのはもちろん⼤事だしや るべきだが、それらがどのように作られているのか、スクラッチでシス テムを起こす場合どういう⽅法があるのかを知ることも⾮常に⼤事。 © DeNA Co., Ltd. 95

96.

ご清聴ありがとうございました! © DeNA Co., Ltd. 96