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/

完完

完完

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

よく知らないんだけど

実際のところ

どんなことができるの？

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

ロンチ時に５本

ロンチから半年で

4０本リリース済み(2017年8月24日時点)

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

40本って何本くらい？

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

ニンテンドーeショップ内

販売タイトルの３割

40本って何本くらい？

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

● Nintendo Switchロンチ時の発売タイトル

○ 任天堂「いっしょにチョキッと スニッパーズ」

○ コナミ「スーパーボンバーマンR」

○ スクウェア・エニックス「いけにえと雪のセツナ」

○ など、5本

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

任天堂 / SFB Games

「いっしょにチョキッと スニッパーズ」

【Unite 2017 Tokyoでの Made with Unity ブース展示】

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

Nintendo Switch 用にデザインされた専用タイトル

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

コナミ (開発 ヘキサドライブ)

【Unite 2017 Tokyo講演】

Unityを使ったNintendo Switch™ローンチタイトル制作

～スーパーボンバーマンRの事例～

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

インターネットを含めた様々なマルチプレイ

(任天堂プラットフォームネットワーク機構のUnity版を使用)

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

スクウェア・エニックス / Tokyo RPG Factory

【Unite 2017 Tokyo講演】

Nintendo Switch™ 本体同時発売必達、

家庭用向けRPG「いけにえと雪のセツナ」開発の裏側

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

他プラットフォーム(PC,PS)からSwitchへのポーティング

実際に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位

実際に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-day2halld51310kumagai

マルチ開発時の互換性

● 豪華めのアセットも動作

● アセットストアで販売されている

「ArchVizPRO Interior Vol.3」もNintendo Switch上で60fps動作可能

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/

本体内蔵フォントを使う

本体内蔵フォントを使う

● 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

ロード時間やガベージコレクション対策あり

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版のほうが頻繁に更新されている

Post Processing Stack

● Post Processing Stack (詳しくはWebで！)

【Unite 2017 Tokyo】ゲームの見た目も盛ったら変わる！！！！ヤバい！！

ポストプロセス！！入門！！！！！！！！！

(弊社 高橋による)https://www.youtube.com/watch?v=r5mNmH68KPQ

Post Processing Stack の使い方の説明

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上で描画のキャプチャができる

レンダリングと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