【CEDEC2017】Unityを使ったNintendo Switch™向けのタイトル開発・移植テクニック!!

Unityを使ったNintendo Switch™向けの タイトル開発・移植テクニック！！ ユニティ・テクノロジーズ・ジャパン合同会社 松岡貴之

講演資料の公開について この講演のスライドは CEDiLにアップロード済みです。 また、講演は録画されます。

講演資料の公開について ● 講演スライドの撮影 : 可 ● SNS への投稿 : 可 #cedec2017 / #cedecunity

まとめ 本日のまとめ

まとめ (1/3) Nintendo Switch 開発者の方は Unity を SDK インストーラから すぐに無償で使用可能

まとめ (2/3) Nintendo Switch 開発者でなくとも Unity 5.6.x で開発開始

まとめ (3/3) 開発のご質問は、開発者ポータル Nintendo Developer Portal 内 Unity 専用掲示板へ！ Nintendo Developer Portal: https://developer.nintendo.com/

• https://developer.nintendo.com/

完

ご清聴ありがとうございました!! 完

よく知らないんだけど 実際のところ どんなことができるの？

実際にUnityを使っているタイトルは？ ロンチ時に５本 ロンチから半年で 4０本リリース済み (2017年8月24日時点)

実際にUnityを使っているタイトルは？ 40本って何本くらい？

実際にUnityを使っているタイトルは？ 40本って何本くらい？ ニンテンドーeショップ内 販売タイトルの３割

実際にUnityを使っているタイトルは？ ● Nintendo Switchロンチ時の発売タイトル ○ 任天堂「いっしょにチョキッと スニッパーズ」 ○ コナミ「スーパーボンバーマンR」 ○ スクウェア・エニックス「いけにえと雪のセツナ」 ○ など、5本

実際にUnityを使っているタイトルは？ 任天堂 / SFB Games 「いっしょにチョキッと スニッパーズ」 【Unite 2017 Tokyoでの Made with Unity ブース展示】 http://events.unity3d.jp/unite2017tokyo/booth.html Nintendo Switch 用にデザインされた専用タイトル

• http://events.unity3d.jp/unite2017tokyo/booth.html

実際にUnityを使っているタイトルは？ コナミ (開発 ヘキサドライブ) 【Unite 2017 Tokyo講演】 Unityを使ったNintendo Switch™ローンチタイトル制作 ～スーパーボンバーマンRの事例～ https://www.youtube.com/watch?v=JwogVwg-zZ0 インターネットを含めた様々なマルチプレイ (任天堂プラットフォームネットワーク機構のUnity版を使用)

• https://www.youtube.com/watch?v=JwogVwg-zZ0

実際にUnityを使っているタイトルは？ スクウェア・エニックス / Tokyo RPG Factory 【Unite 2017 Tokyo講演】 Nintendo Switch™ 本体同時発売必達、 家庭用向けRPG「いけにえと雪のセツナ」開発の裏側 https://www.youtube.com/watch?v=NZmwn2yq1HQ 他プラットフォーム(PC,PS)からSwitchへのポーティング

• https://www.youtube.com/watch?v=NZmwn2yq1HQ

実際にUnityを使っているタイトルは？ ● 市販の Nintendo Switch での知的財産の確認 ホームメニュー > アプリ選択 > ＋ボタン押下 > ソフトの情報 > 知的財産の表記

実際にUnityを使っているタイトルは？

実際にUnityを使っているタイトルは？ 意外と (?) いろいろできる

実際にUnityを使っているタイトルは？ 独立系で 少人数の開発は まだ無理？

実際にUnityを使っているタイトルは？ フライハイワークス / スキップモア / Kan.Kikuchi 「神巫女 -カミコ-」 【Made with Unity インタビュー】 2人×4ヶ月で作り上げた、懐かしさと新しさ https://madewithunity.jp/interviews/kamiko/ ２人のインディーゲーム開発者による短期間開発と リリース (2017/4/13 - ロンチから６週後) Nintendo Switch 上半期DLランキングでも4位

• https://madewithunity.jp/interviews/kamiko/

実際にUnityを使っているタイトルは？ やる気と実力があれば できる！

実力はある。やる気も ちょっと あるけれど……

Unityは バージョンたくさん ありすぎて どれが良いのか わからない

Unityエンジン開発の内情 ● エンジン開発 ○ Unity Editor や共通ランタイムは デンマークや米国などが中心 ○ Nintendo Switch版は日本で開発中

マルチ開発のためのロードマップ ● 2017年7月まで ○ Unity 5.5.0p1 ベースの Nintendo Switch 用ブランチ ○ 厳密には 5.5.0p1 の上位互換 ○ マルチ開発の際に細かな違いがあった

マルチ開発のためのロードマップ ● 2017年8月から ○ Nintendo Switch 用 Unity 5.6.x ○ Unity 5.6.x の本流にマージ済み ■ パッチ等のリリーススケジュールも同じ 現時点では２週間に１度

マルチ開発のためのロードマップ ● 2017年8月から (Nintendo Switch 用 Unity 5.6.x) ○ 一般に配布されている Unity エディタに 開発者ポータルで配布されている Nintendo Switch アドオンを追加して開発 ○ Unityのプラットフォーム切り替え機能を用いて、 マルチ開発が可能

マルチ開発のためのロードマップ Build Settings 内で Platform の１つとして Nintendo Switch を選択可能

マルチ開発のためのロードマップ ● 2017年内には ○ Unity 2017.x へ合流

マルチ開発のためのロードマップ ● プラットフォーム特有の制約に注意 ○ プラットフォームのSDKバージョンの整合性に注意 ■ Nintendo Switchに限らず発生する ○ iOS の皆殺しバージョンのようなもの ■ 全員そろってマイグレーションする時期がある リリース予定日、SDKおよびUnityのバージョンに注意

マルチ開発のためのロードマップ ● ネットワーク ○ 任天堂さまより、任天堂プラットフォーム固有の ネットワークライブラリの Unity 版を提供中 (スーパーボンバーマンRでも使用) ○ UNetはロードマップ上に存在するが、 リリース時期未定

マルチ開発時の互換性

マルチ開発時の互換性 かなり高い

マルチ開発時の互換性 ● 「いけにえと雪のセツナ」での例 ○ Unity 5.2 で製作 ■ PS4, PSVita, Windows でリリース ○ Nintendo Switch ロンチ時に Unity 5.5 でポーティング版リリース ■ 参考資料 https://www.slideshare.net/Unite2017Tokyo/unite2017-tokyo-day2halld51310kum agai

• https://www.slideshare.net/Unite2017Tokyo/unite2017-tokyo-day2halld51310kumagai

マルチ開発時の互換性 ● 豪華めのアセットも動作 ● アセットストアで販売されている 「ArchVizPRO Interior Vol.3」 もNintendo Switch上で60fps動作可能 https://www.assetstore.unity3d.com/en/#!/content/62337

• https://www.assetstore.unity3d.com/en/#!/content/62337

マルチ開発時の互換性 ● Nintendo Switchのアーキテクチャ ○ PC、据え置き、モバイルとの距離が近い ○ コンピュートシェーダなども動作

モバイル機とのマルチ開発時の指針

モバイル機とのマルチ開発時の指針 フツーに作って良い

モバイル機とのマルチ開発時の指針 ● どれくらい動くのか？ ○ 標準的なモバイル機向けのゲームは、問題なく Nintendo Switch 上で動作する ただし、UI、通信、ROM容量などは 注意が必要 はやめの実機チェックも忘れずに！

モバイル機とのマルチ開発時の指針 ● どのように開発をはじめるか ○ デスクトップ機で開発開始 ○ ゲームの形がわかるまでは、制約を気にしない ■ 開発初期には、何が重要なのか分からない ■ 形を作り、大事なものを見極めることを優先する ○ コード設計は後々のデバッグ、変更に耐えうるように ■ 例：ロード処理、非同期処理などは注意が必要 ■ 最初は簡単にラップする程度で良い

モバイル機とのマルチ開発時の指針 ● ゲームの形がわかってきたら、 下限ターゲット機とメモリ予算を決める ○ 例：iPhone5S世代を動作対象に入れるか？ ○ 「Unity 数字で見るゲーム市場」などを参照 ○ メモリ容量 ■ モバイルでは厳しい(搭載メモリの25〜50%) ■ Nintendo Switch ではより多くのメモリが使用可能

モバイル機とのマルチ開発時の指針 ● 調整＆量産 ○ 複数のターゲット機で実行 ○ テクスチャサイズ ○ レンダリング解像度 ○ ポスト処理 ■ 例：下限機でも、カラーグレーディングだけ有 ○ フレームレート ■ マルチ開発では可変フレームレート前提で考える

モバイル機とのマルチ開発時の指針 ● 調整＆量産 (Nintendo Switchでは？) ○ 複数のターゲット機で実行 ○ テクスチャサイズ (メモリ予算が潤沢→余裕がある) ○ レンダリング解像度 (ポスト処理負荷と相談) ○ ポスト処理 (けっこういける) ■ 例：下限機でも、カラーグレーディングだけ有 ○ フレームレート (QA&調整を考え、他機種に合わせる) ■ マルチ開発では可変フレームレート前提で考える

Nintendo Switch の3モード (携帯・テーブル・TV)

Nintendo Switch の3モード (携帯・テーブル・TV) ３モードで遊べる ● 携帯モード・テーブルモード・TVモード ○ 共通点：常に 16:9, 60Hz, VSync有

Nintendo Switch の3モード (携帯・テーブル・TV) ３モードで遊べる ● 携帯モード・テーブルモード・TVモード ○ 共通点：常に 16:9, 60Hz, VSync有 ● 解像度が違う ○ 本体:1280x720, TV-HDMI出力:1920x1080 ● 性能が違う ● Joy-Conの操作方法が違う ● TVモード以外ではタッチパネル使用可

Nintendo Switch の特徴 ３モードで遊べる ● 携帯モード・テーブルモード・TVモード ○ 共通点：常に 16:9, 60Hz, VSync有 ● 解像度が違う (場合がある) ○ 本体:1280x720, TV-HDMI出力:1920x1080 ● 性能が違う (場合がある) ● Joy-Conの操作方法が違う (場合がある) ● TVモード以外ではタッチパネル使用可 (使っても良い)

Nintendo Switch の特徴 ３モード (携帯・テーブル・TV) ● 絶対に３モード対応しないとダメなの？ → 対応したほうが良い ● ユーザは対応を期待している ○ 大きなゲーム、小さなゲームともメリットがある ■ 電車でひと駅だけ遊ぶ（携帯モード） ■ 昼休みや出先で遊ぶ（テーブルモード） ■ TVにつないでじっくり遊ぶ（TVモード）

ここまでのまとめ 既にタイトルが多数リリース済(40本) Unity 5.6.x で開発 マルチ開発可 特別な配慮をしなくても動作する ○ が、実機チェックも忘れずに！ ● ３モード (携帯・テーブル・TV) 対応はしたほうが良い ● ● ● ●

Nintendo Switch が スイッチするときに 何が起きるか？

スイッチ！ 変更通知 ● TV/非TVスイッチ時、および性能変更時はOSから通知が来る ● Nintendo Switch 用 UnityでもOSの通知を受け取れる ○ コールバック関数を登録して受け取る ○ Nintendo Switch 用 Unity 内にサンプルあり ● これを利用してUIや解像度等を変更することができる ○ 何もせず、デフォルトの挙動に任せても良い

スイッチ！ ● TV モード(ドック状態) と非 TV モードで 本体動作に差がある ○ タッチパネル ○ 解像度 ○ 性能

スイッチ！ タッチパネル ● TVモード時(ドック時)は使用不可 ○ 触れない ● タッチパネル専用 or 併用のUIに注意 ○ 例:バーチャルスティックで操作、メニューはタッチ ○ UGUIなどでタッチ、スティック両対応を考える

スイッチ！ 出力解像度 ● TVモード時は 1920 x 1080 ピクセル ● 非TVモード時は 1280 x 720 ピクセル ● UI表示が大きな影響を受ける ○ 基本的に 1920x1080 に合わせて素材を作る ○ 1280x720 時には縮小表示する ○ フォントは TextMeshPro など、 スケーリングがきれいなものも検討

スイッチ！ レンダリング解像度 (1/3) ● Nintendo Switch 用 Unity のデフォルトの挙動 ○ 自動的にレンダリング解像度を変更する ○ TVモード時は 1920 x 1080 ピクセル ○ 非TVモード時は 1280 x 720 ピクセル ● 挙動は開発者側で変更可能 ○ レンダリング解像度を変更しないことも可能

スイッチ！ レンダリング解像度 (2/3) ● お勧めの方法（特にマルチプラットフォーム開発時） ○ 3Dレンダリング用のRenderTextureを自分で用意 ■ ターゲット機に合わせて解像度を変える ○ UIレンダリング前にアップスケールする ■ UI用カメラを用意し、そこでアップスケール ■ その後、UIを実寸でレンダリング

スイッチ！ レンダリング解像度 (3/3) ● キャプチャしている場合に注意 ○ 例：ポーズ時などに、レンダリング結果を キャプチャ＆加工し、そのまま TV/非TV モードが 変更される ● 対応策 ○ キャプチャしなおす ○ 解像度が変わっても何もしない

スイッチ！ 性能 性能が変わるが、基本的に何も考えなくて良い ● CPUはいつも十分なパワーがある ○ 例:TV/非TVでロジックを変える、等は必要無し ● GPUは出力解像度に対し十分パワーがある ○ 例:出力とレンダリング解像度が比例していれば問題無 ● 詳細はSDKのドキュメントを参照

スイッチ！ 性能変更 ● 性能変更時に一時的に大きな処理落ちが 発生する場合がある

スイッチ！ ● 処理落ち時には… ○ 処理落ちしているため、Time.deltaTime (1フレームにかかった時間)がかなり大きくなる ○ バグの例 : 壁の方向に向かってスティックを 倒したまま、クレードル挿抜を行うと、壁抜け発生

スイッチ！ ● 処理落ち ○ 実際にはどのプラットフォームでも発生しうる ■ Nintendo Switch固有の問題ではない ○ 対策して損はない

スイッチ！ ● 処理落ちに対する、簡単な対策 ○ TimeManager を開く ■ Edit > Project Settings > Time ○ Maximum Allowed Timestep を小さくすることで Time.deltaTimeの最大値を制御可能(デフォルトは0.33 秒)

スイッチ！ ● 処理落ちに対する、簡単な対策 この値を 0.033 などに 設定

スイッチ！ ● 処理落ち対策 ○ 「ならFixedUpdate()にすると？」 ■ 一定の実時間内に呼び出される回数を保証 ■ が、おすすめしません ○ なぜ？ ■ フレームレートが逆に不安定になる ■ フレームレート変更不能 ■ 他のアセットの挙動の整合性がとりにくい

スイッチ！ ● さまざまな情況のクレードル挿抜エミュレーション可能 ○ SDK内にツールあり ■ 手で抜き挿ししなくても良い！ ○ QA前に必ず確認

スイッチ！（まとめ） ● タッチパネル ○ 対応する場合、タッチ、Joy-Con両対応UIを考える ● 解像度 ○ 面倒なら、デフォルトの挙動にまかせて良い ○ できれば、可変解像度に対応させる ● 性能 ○ 基本的に、気にしなくて良い ○ が、挿抜時の処理落ちに注意

ここからは いろいろ技術的なお話

こまごまとした 注意点を挙げます

Fixed Timestepの調整

Fixed Timestep の調整 ● Fixed Timestep の調整 ○ TimeManager を開く (Edit > Project Settings > Time) ○ Fixed Timestep を 0.02 (1/50, デフォルト値) から 0.01666 (1/60)に変更

Fixed Timestep の調整 ● Fixed Timestep の修正 ○ デフォルト値 (0.02秒 = 50Hz) の場合、 実際の VSync周期 (60Hz)と合わない ○ よって１フレームにゼロ回や複数回 FixedUpdate()が実行される場合がある ○ 結果として、スパイク（処理の急激な増加） が発生する ○ Unity 内蔵の Profilerで確認可能

Unityのプロジェクトを 開くのが面倒くさい

複数のバージョンのUnityを 使う必要があって困っている

複数バージョンのUnityの使用 ● 複数バージョンの Unity のインストール ○ どのUnityも、任意のディレクトリにインストール可能 ■ インストーラで指定

複数バージョンのUnityの使用 ● バッチファイルから起動 set "UNITY=インストールしたディレクトリ\Editor\Unity.exe" set "PROJECT=プロジェクトのパス" start "" "%UNITY%" -projectPath "%PROJECT%"

複数バージョンのUnityの使用 ● プラットフォーム指定可能 set "UNITY=インストールしたディレクトリ\Editor\Unity.exe" set "PROJECT=プロジェクトのパス" set "TARGET=Switch" start "" "%UNITY%" -buildTarget %TARGET% -projectPath "%PROJECT%"

複数バージョンのUnityの使用 ● Unityプロジェクトのパスとは ○ Assets ディレクトリを持つパス C:\MyProjects\MyTest\Assets\ 内にアセットがあるなら set "PROJECT=C:\MyTest\MyTestProject"

古いバージョンの Unityから持ってくるとき

古いバージョンのUnityからのポーティング ● 通常のUnityのバージョンアップと変わらない ○ ネームスペース、API名の変更（ほぼ自動） ○ 非互換な機能（すみません…） ○ 追加された機能 ■ Texture Importer などインポータ設定は確認が必要 ■ 追加されたプロパティは多くの場合自動的に イネーブルになる ■ 「余計なお世話」となってしまうときがある

Joy-Conからの入力

Joy-Conからの入力 ● Joy-Con ○ 付属のネイティブプラグインの使用を推奨 ■ HD振動、加速度・ジャイロセンサー 横持ち(「おすそわけ」)などにも対応 ○ Joy-Conの仕様は意外と大きい

Joy-Conからの入力 ● Joy-Con ○ 現状は、付属のネイティブプラグインから uGUIを操作できない ■ これを解消するには開発者側での InputModule の実装が必要 ○ 近い将来、InputModule を提供

Joy-Conからの入力 ● InputMangerによるJoy-Conアクセス ○ 現状は１人用の持ち方にのみ非公式に対応 ■ Joy-Conの「縦持ち」および、Proコントローラー ■ Windows上のXbox360コントローラと軸番号、 ボタン配置互換 ■ PCで開発してそのまま実行可能 ○ HD振動、加速度・ジャイロセンサー、横持ち未対応 ○ 簡易的な「動作確認用」の機能と考える

セーブデータ

セーブデータ ● セーブデータ ○ 付属のネイティブプラグインの使用を推奨 ○ Nintendo Switchに限らず、コンソール機向けUnityは、 PlayerPrefsに対応していない ■ アカウント等の扱いがからむため ○ 何らかの方法でシリアライズしてセーブ・ロード

パッチ

パッチサイズは できるだけ小さく

パッチ Asset Bundleを必ず使う

パッチ(まとめ) ● モバイル系プラットフォームで用いられている 基本的な技法を踏襲する ○ AssetBundleを小さめの粒度で作る ■ 例：プレイヤー1,2、敵1,2,3、設置物1,2,3 ○ Resourcesは最小限に ○ Streaming Assetsも検討 ○ シーンに直接アセットを入れない

パッチ ● Unityを使う場合、基本的に変更のあった、 ビルド後のファイルがパッチ対象となる ○ 実行ファイル ○ Resources（フォルダ内全体で1ファイル生成） ○ シーン（シーンごとにファイル生成） ○ アセットバンドル（開発者が指定）

パッチ ● 実行ファイル ○ 対処方法なし

パッチ ● Streaming Assets ○ 音楽、動画など ○ マルチプラットフォーム開発時は他の プラットフォームのアセットが混じらないように注意

パッチ ● Resourcesフォルダ ○ ビルド時に1つのファイルになる(resources.assets) ○ Resources内のファイルが変更された場合、 Resources全体がパッチ対象になる ○ このため、Resources内の容量は最小化するのが望まし い

パッチ ● シーン ○ ビルド時にシーン毎にファイルを生成 ■ シーン内の全アセットが単一ファイルになる (sharedassetsN.assets) ○ シーンに直接アセットを入れている場合、 シーン内の何か1つを変更すると、 ビルド後のシーンファイル全体がパッチ対象となる ○ 結果として、パッチが非常に大きくなる

パッチ ● Asset Bundle ○ どうやって分けるか？ ■ 「変更のありそうな単位」にする ■ 「プレイヤーA」「敵A」「敵B」などなど ○ ワークフロー上の負担も考慮 ■ 「Unite Tokyo アセットバンドル」などで検索 ○ Asset Bundle Graph Tool (午後の講演)

動画を流したい

動画 ● MP4 + H.264に対応 ● 再生フレームレートは 60.00 fps ○ NTSC の 59.94Hz ではない ● Nintendo Switch用Unity内にサンプルコード付属

microSDカードへの対応

microSD カード ● 速度を気にしすぎる必要は無い ○ 遅い microSD カードなど ● 音楽や動画の再生がうまくいかない場合はあり得る ● その場合でも「落ちない」「進行不能にならない」ようにする https://www.nintendo.co.jp/support/switch/data_management/microsdcard/

• https://www.nintendo.co.jp/support/switch/data_management/microsdcard/index.html

本体内蔵フォントを使う

本体内蔵フォントを使う ● Unity上で、本体内蔵フォントを使うことができる ○ 通常のフォントとして使用可能 ○ 中国語（繁体字、簡体字）など、 容量が大きいものに使うと便利 ○ ユーザ名表示等は企画上「当たり前の機能」という位置づ けだが、マルチリージョン、言語対応を独自フォントで真面 目に実装すると大変

なぜかガクガクする

Unity Editor 内蔵 Profilerを使いましょう

プロファイリング (Unity Profiler) ● Unity Editor 上でも、実機でも使用可能 ○ Development Build を指定する ● Unity Editor 上で確認 ○ Window > Profiler

プロファイリング (Unity Profiler) ● 関数ごとの時間 ● メモリアロケーション量 ● CPUやメモリのグラフ

プロファイリング (Unity Profiler) ● スパイク(処理量の極端な増加)に注目する ● Unity Editor (≒ PC) 上でスパイクが出ていたら、 ほぼ必ず実機でもスパイクが出る ● まずは Editor 上でスパイクをすべて潰す ● PCビルド版も試す ● その後実機で計測を必ず行う ○ PCと実機は違う！

プロファイリング (Unity Profiler) ● スパイク(処理量の極端な増加)のよくある理由(1) ○ Garbage Collection (GC) ■ GC Alloc を削減 ■ 文字列操作、特にデバッグログ生成に注意 ■ Mono Heapの大きさに注意 ● Mono Heapが大きいほどGCに時間がかかる

プロファイリング (Unity Profiler) ● スパイク(処理量の極端な増加)のよくある理由(2) ○ Physics関連 ■ Fixed Timestep (前述) を見直す ○ ロード、インスタンス生成や非同期処理 ■ 何をロード、処理しているか追いやすくする

プロファイリング (Unity Profiler) ● 実機でのプロファイリング (Unity Profiler) ○ 「PC比で何倍の時間がかかっている」かを調べる ■ PC上での性能目標を定義しやすくなる ○ PCと比べてワーカスレッド数が違う点に注意する ■ Unityのエンジン内のマルチスレッド処理の 実行速度が変わる ● Physics, Renderer, Occlusion Culling など

プロファイリング (Unity Profiler) ワーカスレッドの動作の確認方法

プロファイリング (Unity Profiler) ● Deep Profileを使う

プロファイリング (Unity Profiler) ● Deep Profileを使う ○ Editor, 実機とも使用可能 ○ 処理速度は低下する ○ 代わりに関数単位の詳細な計測が可能 ■ 時間 ■ GC Alloc ○ 性能目標を定めてから使うと良い ■ 例：「あと 2ms 削りたい」

プロファイリング (Unity Profiler) 【Unite 2017 Tokyo】 最適化をする前に覚えておきたい技術 (弊社 黒河による) https://www.slideshare.net/UnityTechnologiesJapan/unite-2017-tokyo-75775983 https://www.youtube.com/watch?v=rvnsU8oCMcI ロード時間やガベージコレクション対策あり

• https://www.slideshare.net/UnityTechnologiesJapan/unite-2017-tokyo-75775983
• https://www.youtube.com/watch?v=rvnsU8oCMcI&feature=youtu.be

SDK付属の CPUプロファイラを使う

SDK付属CPUプロファイラ ● いつ使うか？ ○ 最初はUnity内蔵のプロファイラを使う ○ もう詰められる部分が無くなったときが出番 ○ IL2CPPの出力結果を見るので、実際のC#のコード上での クラス名、関数名が分かりにくい場合がある

ポストエフェクトを盛って 画面をボカしたり キラキラ☆させたい

Post Processing Stackを使う

Post Processing Stack ● Unityの標準ポスト処理 ● Image Effectsはレガシー扱い ○ Post Processing Stack のほうが1.5 倍ぐらい高速 ● Asset Store 版と GitHub 版がある https://github.com/Unity-Technologies/PostProcessing ○ GitHub版のほうが頻繁に更新されている

• https://github.com/Unity-Technologies/PostProcessing

Post Processing Stack ● Post Processing Stack (詳しくはWebで！) 【Unite 2017 Tokyo】 ゲームの見た目も盛ったら変わる！！！！ヤバい！！ ポストプロセス！！入門！！！！！！！！！ (弊社 高橋による) https://www.youtube.com/watch?v=r5mNmH68KPQ Post Processing Stack の使い方の説明

• https://www.youtube.com/watch?v=r5mNmH68KPQ

GPUが重い？ ような？ 気がする？

レンダリングとGPUデバッガ ● プラットフォームを問わず、GPUネックのケースは意外と多い ● 開発後半までひきずることもある ● 早期に問題を特定したほうが、後で楽になる ○ アセット量産前がベストなタイミング ● ポーティング時に、GPU特性の違いで重い場合もある

レンダリングとGPUデバッガ ● 何を調べるか？ ○ GPU処理上の問題の有無 ■ 本当にGPUが重いのか？ ○ 最適化の対象候補 ■ どの処理が重いのか？ ○ 最適化案 ■ どのように処理を軽減するか？

レンダリングとGPUデバッガ ● まず、本当にGPUが重いのか確認

レンダリングとGPUデバッガ ● まず、本当にGPUが重いのか確認 ○ Development Buildで実機実行し、コンソールを確認

レンダリングとGPUデバッガ ○ カメラの Viewport Rect の Width, Height を 0.25 などにして、擬似的に解像度を下げて実機で実行 ● フレームレートが向上するならGPUネックの可能性有

レンダリングとGPUデバッガ ● GPUがボトルネックだと判明したら ● 無駄な描画をしていないか、PC上で調査 ○ RenderDocをインストール ○ https://docs.unity3d.com/Manual/RenderDocIntegration.html ○ Unity Editor上で描画のキャプチャができる

• https://docs.unity3d.com/Manual/RenderDocIntegration.html

レンダリングとGPUデバッガ ● RenderDocキャプチャ ● DrawCall単位の確認が可能 ○ 描画先 ○ 描いているポリゴン ○ シェーダ ○ 使用しているテクスチャ ○ テクスチャのフォーマット

レンダリングとGPUデバッガ ● RenderDoc上で確認すべきことの例 ○ 一見あり得ないミスに見えるが、高い技術と経験のある チームでも、忙しくなると確認を忘れがち

レンダリングとGPUデバッガ ● RenderDoc上で確認すべきことの例 ○ 無意味なカメラが動いていないか？ ■ → カメラをディゼーブルに ■ 動作しているカメラ数を表示して自衛

レンダリングとGPUデバッガ ● RenderDoc上で確認すべきことの例 ○ 無意味なポストエフェクトは無いか？ ■ → ポストエフェクトを切る

レンダリングとGPUデバッガ ● RenderDoc上で確認すべきことの例 ○ 完全に透明な半透明ポリゴンを描画していないか？ ■ → 完全に透明になった時点で描画をやめる

レンダリングとGPUデバッガ ● RenderDoc上で確認すべきことの例 ○ いつも隠れてしまうものを描画していないか？ ■ → 隠れることが分かる場合、描画しない ■ 複雑なシーンにはオクルージョンカリングも検討

レンダリングとGPUデバッガ ● RenderDoc上で確認すべきことの例 ○ 隠れる面積が大きい不透明ポリゴンを、奥→手前の順で 描画していないか？ ■ → 可能なら、手前→奥になるように、 Material.renderQueue を調整 ■ 例:「地面」や「遠景」はできるだけ後で描く

レンダリングとGPUデバッガ ● SDK付属の実機用GPUデバッガ ○ Unityも標準で対応 ■ ビルド時に指定 ○ 実行時のリアルタイム負荷グラフ ○ フレームをキャプチャ ■ RenderDocより詳細な内容を見られる

レンダリングとGPUデバッガ ● フレームキャプチャ時 ○ 使用しているシェーダ、頂点、テクスチャ確認可能 ○ ドローコール単位の消費時間を確認可能 ■ 使い方の例：ポストエフェクトのエフェクト毎の処理時間 を測って伝え、「予算」の中に収まるようにデザイナ側 で検討

マスター提出前の QAってどうすれば良いの？

QAをどう行うか？ ● 普段から実機で動作を確認する ● QAは基本的に実機で行う ● チェック項目が定められているので、それに従う ○ きちんとチェックしないと通らないので注意 ● 意外と時間を食うのでスケジュールにきちんと織り込む

まとめ 本日のまとめ

まとめ ● Nintendo Switch開発者はいますぐ Unityを使用可能 ● 困ったら開発者ポータル掲示板で質問 ● Unity 5.6 で作る ● AssetBundle を必ず使う

CEDEC会場内 任天堂さまブース Unityブース でもご質問ください

ご清聴ありがとうございました!!

Q&A