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

14.6K Views

August 31, 17

スライド概要

2017/8/30~9/1に開催されたCEDEC2017の講演スライドです。
講師:松岡 貴之(ユニティ・テクノロジーズ・ジャパン合同会社)

profile-image

リアルタイム3Dコンテンツを制作・運用するための世界的にリードするプラットフォームである「Unity」の日本国内における販売、サポート、コミュニティ活動、研究開発、教育支援を行っています。ゲーム開発者からアーティスト、建築家、自動車デザイナー、映画製作者など、さまざまなクリエイターがUnityを使い想像力を発揮しています。

シェア

またはPlayer版

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

関連スライド

各ページのテキスト
1.

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

2.

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

3.

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

4.

まとめ 本日のまとめ

5.

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

6.

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

7.

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

8.

9.

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

10.

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

11.

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

12.

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

13.

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

14.

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

15.

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

16.

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

17.

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

18.

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

19.

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

20.

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

21.

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

22.

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

23.

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

24.

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

25.

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

26.

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

27.

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

28.

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

29.

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

30.

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

31.

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

32.

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

33.

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

34.

マルチ開発時の互換性

35.

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

36.

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

37.

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

38.

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

39.

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

40.

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

41.

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

42.

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

43.

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

44.

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

45.

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

46.

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

47.

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

48.

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

49.

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

50.

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

51.

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

52.

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

53.

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

54.

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

55.

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

56.

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

57.

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

58.

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

59.

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

60.

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

61.

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

62.

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

63.

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

64.

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

65.

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

66.

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

67.

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

68.

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

69.

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

70.

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

71.

Fixed Timestepの調整

72.

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

73.

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

74.

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

75.

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

76.

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

77.

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

78.

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

79.

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

80.

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

81.

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

82.

Joy-Conからの入力

83.

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

84.

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

85.

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

86.

セーブデータ

87.

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

88.

パッチ

89.

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

90.

パッチ Asset Bundleを必ず使う

91.

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

92.

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

93.

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

94.

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

95.

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

96.

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

97.

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

98.

動画を流したい

99.

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

100.

microSDカードへの対応

101.

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

102.

本体内蔵フォントを使う

103.

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

104.

なぜかガクガクする

105.

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

106.

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

107.

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

108.

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

109.

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

110.

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

111.

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

112.

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

113.

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

114.

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

115.

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

116.

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

117.

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

118.

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

120.

Post Processing Stackを使う

121.

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

122.

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

123.

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

124.

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

125.

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

126.

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

127.

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

128.

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

129.

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

130.

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

131.

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

132.

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

133.

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

134.

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

135.

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

136.

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

137.

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

138.

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

139.

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

140.

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

141.

まとめ 本日のまとめ

142.

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

143.

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

144.

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

145.

Q&A