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-day2halld51310kum
agai

マルチ開発時の互換性
● 豪華めのアセットも動作
● アセットストアで販売されている
「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=インストールしたディレクトリEditorUnity.exe"
set "PROJECT=プロジェクトのパス"
start "" "%UNITY%" -projectPath "%PROJECT%"

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

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

古いバージョンの
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