Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

18,571 views

Published on

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

Published in: Technology
  • Be the first to comment

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

  1. 1. Unityを使ったNintendo Switch™向けの タイトル開発・移植テクニック!! ユニティ・テクノロジーズ・ジャパン合同会社 松岡貴之
  2. 2. 講演資料の公開について この講演のスライドは CEDiLにアップロード済みです。 また、講演は録画されます。
  3. 3. 講演資料の公開について ● 講演スライドの撮影 : 可 ● SNS への投稿 : 可 #cedec2017 / #cedecunity
  4. 4. まとめ 本日のまとめ
  5. 5. まとめ (1/3) Nintendo Switch 開発者の方は Unity を SDK インストーラから すぐに無償で使用可能
  6. 6. まとめ (2/3) Nintendo Switch 開発者でなくとも Unity 5.6.x で開発開始
  7. 7. まとめ (3/3) 開発のご質問は、開発者ポータル Nintendo Developer Portal 内 Unity 専用掲示板へ! Nintendo Developer Portal: https://developer.nintendo.com/
  8. 8. 完完
  9. 9. 完完 ご清聴ありがとうございました!!
  10. 10. よく知らないんだけど 実際のところ どんなことができるの?
  11. 11. 実際にUnityを使っているタイトルは? ロンチ時に5本 ロンチから半年で 40本リリース済み (2017年8月24日時点)
  12. 12. 実際にUnityを使っているタイトルは? 40本って何本くらい?
  13. 13. 実際にUnityを使っているタイトルは? ニンテンドーeショップ内 販売タイトルの3割 40本って何本くらい?
  14. 14. 実際にUnityを使っているタイトルは? ● Nintendo Switchロンチ時の発売タイトル ○ 任天堂「いっしょにチョキッと スニッパーズ」 ○ コナミ「スーパーボンバーマンR」 ○ スクウェア・エニックス「いけにえと雪のセツナ」 ○ など、5本
  15. 15. 実際にUnityを使っているタイトルは? 任天堂 / SFB Games 「いっしょにチョキッと スニッパーズ」 【Unite 2017 Tokyoでの Made with Unity ブース展示】 http://events.unity3d.jp/unite2017tokyo/booth.html Nintendo Switch 用にデザインされた専用タイトル
  16. 16. 実際にUnityを使っているタイトルは? コナミ (開発 ヘキサドライブ) 【Unite 2017 Tokyo講演】 Unityを使ったNintendo Switch™ローンチタイトル制作 ~スーパーボンバーマンRの事例~ https://www.youtube.com/watch?v=JwogVwg-zZ0 インターネットを含めた様々なマルチプレイ (任天堂プラットフォームネットワーク機構のUnity版を使用)
  17. 17. 実際にUnityを使っているタイトルは? スクウェア・エニックス / Tokyo RPG Factory 【Unite 2017 Tokyo講演】 Nintendo Switch™ 本体同時発売必達、 家庭用向けRPG「いけにえと雪のセツナ」開発の裏側 https://www.youtube.com/watch?v=NZmwn2yq1HQ 他プラットフォーム(PC,PS)からSwitchへのポーティング
  18. 18. 実際にUnityを使っているタイトルは? ● 市販の Nintendo Switch での知的財産の確認 ホームメニュー > アプリ選択 > +ボタン押下 > ソフトの情報 > 知的財産の表記
  19. 19. 実際にUnityを使っているタイトルは?
  20. 20. 実際にUnityを使っているタイトルは? 意外と (?) いろいろできる
  21. 21. 実際にUnityを使っているタイトルは? 独立系で 少人数の開発は まだ無理?
  22. 22. 実際にUnityを使っているタイトルは? フライハイワークス / スキップモア / Kan.Kikuchi 「神巫女 -カミコ-」 【Made with Unity インタビュー】 2人×4ヶ月で作り上げた、懐かしさと新しさ https://madewithunity.jp/interviews/kamiko/ 2人のインディーゲーム開発者による短期間開発と リリース (2017/4/13 - ロンチから6週後) Nintendo Switch 上半期DLランキングでも4位
  23. 23. 実際にUnityを使っているタイトルは? やる気と実力があれば できる!
  24. 24. 実力はある。やる気も ちょっと あるけれど……
  25. 25. Unityは バージョンたくさん ありすぎて どれが良いのか わからない
  26. 26. Unityエンジン開発の内情 ● エンジン開発 ○ Unity Editor や共通ランタイムは デンマークや米国などが中心 ○ Nintendo Switch版は日本で開発中
  27. 27. マルチ開発のためのロードマップ ● 2017年7月まで ○ Unity 5.5.0p1 ベースの Nintendo Switch 用ブランチ ○ 厳密には 5.5.0p1 の上位互換 ○ マルチ開発の際に細かな違いがあった
  28. 28. マルチ開発のためのロードマップ ● 2017年8月から ○ Nintendo Switch 用 Unity 5.6.x ○ Unity 5.6.x の本流にマージ済み ■ パッチ等のリリーススケジュールも同じ 現時点では2週間に1度
  29. 29. マルチ開発のためのロードマップ ● 2017年8月から (Nintendo Switch 用 Unity 5.6.x) ○ 一般に配布されている Unity エディタに 開発者ポータルで配布されている Nintendo Switch アドオンを追加して開発 ○ Unityのプラットフォーム切り替え機能を用いて、 マルチ開発が可能
  30. 30. マルチ開発のためのロードマップ Build Settings 内で Platform の1つとして Nintendo Switch を選択可能
  31. 31. マルチ開発のためのロードマップ ● 2017年内には ○ Unity 2017.x へ合流
  32. 32. マルチ開発のためのロードマップ ● プラットフォーム特有の制約に注意 ○ プラットフォームのSDKバージョンの整合性に注意 ■ Nintendo Switchに限らず発生する ○ iOS の皆殺しバージョンのようなもの ■ 全員そろってマイグレーションする時期がある リリース予定日、SDKおよびUnityのバージョンに注意
  33. 33. マルチ開発のためのロードマップ ● ネットワーク ○ 任天堂さまより、任天堂プラットフォーム固有の ネットワークライブラリの Unity 版を提供中 (スーパーボンバーマンRでも使用) ○ UNetはロードマップ上に存在するが、 リリース時期未定
  34. 34. マルチ開発時の互換性
  35. 35. マルチ開発時の互換性 かなり高い
  36. 36. マルチ開発時の互換性 ● 「いけにえと雪のセツナ」での例 ○ Unity 5.2 で製作 ■ PS4, PSVita, Windows でリリース ○ Nintendo Switch ロンチ時に Unity 5.5 でポーティング版リリース ■ 参考資料 https://www.slideshare.net/Unite2017Tokyo/unite2017-tokyo-day2halld51310kum agai
  37. 37. マルチ開発時の互換性 ● 豪華めのアセットも動作 ● アセットストアで販売されている 「ArchVizPRO Interior Vol.3」 もNintendo Switch上で60fps動作可能 https://www.assetstore.unity3d.com/en/#!/content/62337
  38. 38. マルチ開発時の互換性 ● Nintendo Switchのアーキテクチャ ○ PC、据え置き、モバイルとの距離が近い ○ コンピュートシェーダなども動作
  39. 39. モバイル機とのマルチ開発時の指針
  40. 40. モバイル機とのマルチ開発時の指針 フツーに作って良い
  41. 41. モバイル機とのマルチ開発時の指針 ● どれくらい動くのか? ○ 標準的なモバイル機向けのゲームは、問題なく Nintendo Switch 上で動作する ただし、UI、通信、ROM容量などは 注意が必要 はやめの実機チェックも忘れずに!
  42. 42. モバイル機とのマルチ開発時の指針 ● どのように開発をはじめるか ○ デスクトップ機で開発開始 ○ ゲームの形がわかるまでは、制約を気にしない ■ 開発初期には、何が重要なのか分からない ■ 形を作り、大事なものを見極めることを優先する ○ コード設計は後々のデバッグ、変更に耐えうるように ■ 例:ロード処理、非同期処理などは注意が必要 ■ 最初は簡単にラップする程度で良い
  43. 43. モバイル機とのマルチ開発時の指針 ● ゲームの形がわかってきたら、 下限ターゲット機とメモリ予算を決める ○ 例:iPhone5S世代を動作対象に入れるか? ○ 「Unity 数字で見るゲーム市場」などを参照 ○ メモリ容量 ■ モバイルでは厳しい(搭載メモリの25〜50%) ■ Nintendo Switch ではより多くのメモリが使用可能
  44. 44. モバイル機とのマルチ開発時の指針 ● 調整&量産 ○ 複数のターゲット機で実行 ○ テクスチャサイズ ○ レンダリング解像度 ○ ポスト処理 ■ 例:下限機でも、カラーグレーディングだけ有 ○ フレームレート ■ マルチ開発では可変フレームレート前提で考える
  45. 45. モバイル機とのマルチ開発時の指針 ● 調整&量産 (Nintendo Switchでは?) ○ 複数のターゲット機で実行 ○ テクスチャサイズ (メモリ予算が潤沢→余裕がある) ○ レンダリング解像度 (ポスト処理負荷と相談) ○ ポスト処理 (けっこういける) ■ 例:下限機でも、カラーグレーディングだけ有 ○ フレームレート (QA&調整を考え、他機種に合わせる) ■ マルチ開発では可変フレームレート前提で考える
  46. 46. Nintendo Switch の3モード (携帯・テーブル・TV)
  47. 47. Nintendo Switch の3モード (携帯・テーブル・TV) 3モードで遊べる ● 携帯モード・テーブルモード・TVモード ○ 共通点:常に 16:9, 60Hz, VSync有
  48. 48. Nintendo Switch の3モード (携帯・テーブル・TV) 3モードで遊べる ● 携帯モード・テーブルモード・TVモード ○ 共通点:常に 16:9, 60Hz, VSync有 ● 解像度が違う ○ 本体:1280x720, TV-HDMI出力:1920x1080 ● 性能が違う ● Joy-Conの操作方法が違う ● TVモード以外ではタッチパネル使用可
  49. 49. Nintendo Switch の特徴 3モードで遊べる ● 携帯モード・テーブルモード・TVモード ○ 共通点:常に 16:9, 60Hz, VSync有 ● 解像度が違う (場合がある) ○ 本体:1280x720, TV-HDMI出力:1920x1080 ● 性能が違う (場合がある) ● Joy-Conの操作方法が違う (場合がある) ● TVモード以外ではタッチパネル使用可 (使っても良い)
  50. 50. Nintendo Switch の特徴 3モード (携帯・テーブル・TV) ● 絶対に3モード対応しないとダメなの? → 対応したほうが良い ● ユーザは対応を期待している ○ 大きなゲーム、小さなゲームともメリットがある ■ 電車でひと駅だけ遊ぶ(携帯モード) ■ 昼休みや出先で遊ぶ(テーブルモード) ■ TVにつないでじっくり遊ぶ(TVモード)
  51. 51. ここまでのまとめ ● 既にタイトルが多数リリース済(40本) ● Unity 5.6.x で開発 ● マルチ開発可 ● 特別な配慮をしなくても動作する ○ が、実機チェックも忘れずに! ● 3モード (携帯・テーブル・TV) 対応はしたほうが良い
  52. 52. Nintendo Switch が スイッチするときに 何が起きるか?
  53. 53. スイッチ! 変更通知 ● TV/非TVスイッチ時、および性能変更時はOSから通知が来る ● Nintendo Switch 用 UnityでもOSの通知を受け取れる ○ コールバック関数を登録して受け取る ○ Nintendo Switch 用 Unity 内にサンプルあり ● これを利用してUIや解像度等を変更することができる ○ 何もせず、デフォルトの挙動に任せても良い
  54. 54. スイッチ! ● TV モード(ドック状態) と非 TV モードで 本体動作に差がある ○ タッチパネル ○ 解像度 ○ 性能
  55. 55. スイッチ! タッチパネル ● TVモード時(ドック時)は使用不可 ○ 触れない ● タッチパネル専用 or 併用のUIに注意 ○ 例:バーチャルスティックで操作、メニューはタッチ ○ UGUIなどでタッチ、スティック両対応を考える
  56. 56. スイッチ! 出力解像度 ● TVモード時は 1920 x 1080 ピクセル ● 非TVモード時は 1280 x 720 ピクセル ● UI表示が大きな影響を受ける ○ 基本的に 1920x1080 に合わせて素材を作る ○ 1280x720 時には縮小表示する ○ フォントは TextMeshPro など、 スケーリングがきれいなものも検討
  57. 57. スイッチ! レンダリング解像度 (1/3) ● Nintendo Switch 用 Unity のデフォルトの挙動 ○ 自動的にレンダリング解像度を変更する ○ TVモード時は 1920 x 1080 ピクセル ○ 非TVモード時は 1280 x 720 ピクセル ● 挙動は開発者側で変更可能 ○ レンダリング解像度を変更しないことも可能
  58. 58. スイッチ! レンダリング解像度 (2/3) ● お勧めの方法(特にマルチプラットフォーム開発時) ○ 3Dレンダリング用のRenderTextureを自分で用意 ■ ターゲット機に合わせて解像度を変える ○ UIレンダリング前にアップスケールする ■ UI用カメラを用意し、そこでアップスケール ■ その後、UIを実寸でレンダリング
  59. 59. スイッチ! レンダリング解像度 (3/3) ● キャプチャしている場合に注意 ○ 例:ポーズ時などに、レンダリング結果を キャプチャ&加工し、そのまま TV/非TV モードが 変更される ● 対応策 ○ キャプチャしなおす ○ 解像度が変わっても何もしない
  60. 60. スイッチ! 性能 性能が変わるが、基本的に何も考えなくて良い ● CPUはいつも十分なパワーがある ○ 例:TV/非TVでロジックを変える、等は必要無し ● GPUは出力解像度に対し十分パワーがある ○ 例:出力とレンダリング解像度が比例していれば問題無 ● 詳細はSDKのドキュメントを参照
  61. 61. スイッチ! 性能変更 ● 性能変更時に一時的に大きな処理落ちが 発生する場合がある
  62. 62. スイッチ! ● 処理落ち時には… ○ 処理落ちしているため、Time.deltaTime (1フレームにかかった時間)がかなり大きくなる ○ バグの例 : 壁の方向に向かってスティックを 倒したまま、クレードル挿抜を行うと、壁抜け発生
  63. 63. スイッチ! ● 処理落ち ○ 実際にはどのプラットフォームでも発生しうる ■ Nintendo Switch固有の問題ではない ○ 対策して損はない
  64. 64. スイッチ! ● 処理落ちに対する、簡単な対策 ○ TimeManager を開く ■ Edit > Project Settings > Time ○ Maximum Allowed Timestep を小さくすることで Time.deltaTimeの最大値を制御可能(デフォルトは0.33 秒)
  65. 65. スイッチ! ● 処理落ちに対する、簡単な対策 この値を 0.033 などに 設定
  66. 66. スイッチ! ● 処理落ち対策 ○ 「ならFixedUpdate()にすると?」 ■ 一定の実時間内に呼び出される回数を保証 ■ が、おすすめしません ○ なぜ? ■ フレームレートが逆に不安定になる ■ フレームレート変更不能 ■ 他のアセットの挙動の整合性がとりにくい
  67. 67. スイッチ! ● さまざまな情況のクレードル挿抜エミュレーション可能 ○ SDK内にツールあり ■ 手で抜き挿ししなくても良い! ○ QA前に必ず確認
  68. 68. スイッチ!(まとめ) ● タッチパネル ○ 対応する場合、タッチ、Joy-Con両対応UIを考える ● 解像度 ○ 面倒なら、デフォルトの挙動にまかせて良い ○ できれば、可変解像度に対応させる ● 性能 ○ 基本的に、気にしなくて良い ○ が、挿抜時の処理落ちに注意
  69. 69. ここからは いろいろ技術的なお話
  70. 70. こまごまとした 注意点を挙げます
  71. 71. Fixed Timestepの調整
  72. 72. Fixed Timestep の調整 ● Fixed Timestep の調整 ○ TimeManager を開く (Edit > Project Settings > Time) ○ Fixed Timestep を 0.02 (1/50, デフォルト値) から 0.01666 (1/60)に変更
  73. 73. Fixed Timestep の調整 ● Fixed Timestep の修正 ○ デフォルト値 (0.02秒 = 50Hz) の場合、 実際の VSync周期 (60Hz)と合わない ○ よって1フレームにゼロ回や複数回 FixedUpdate()が実行される場合がある ○ 結果として、スパイク(処理の急激な増加) が発生する ○ Unity 内蔵の Profilerで確認可能
  74. 74. Unityのプロジェクトを 開くのが面倒くさい
  75. 75. 複数のバージョンのUnityを 使う必要があって困っている
  76. 76. 複数バージョンのUnityの使用 ● 複数バージョンの Unity のインストール ○ どのUnityも、任意のディレクトリにインストール可能 ■ インストーラで指定
  77. 77. 複数バージョンのUnityの使用 ● バッチファイルから起動 set "UNITY=インストールしたディレクトリEditorUnity.exe" set "PROJECT=プロジェクトのパス" start "" "%UNITY%" -projectPath "%PROJECT%"
  78. 78. 複数バージョンのUnityの使用 ● プラットフォーム指定可能 set "UNITY=インストールしたディレクトリEditorUnity.exe" set "PROJECT=プロジェクトのパス" set "TARGET=Switch" start "" "%UNITY%" -buildTarget %TARGET% -projectPath "%PROJECT%"
  79. 79. 複数バージョンのUnityの使用 ● Unityプロジェクトのパスとは ○ Assets ディレクトリを持つパス C:MyProjectsMyTestAssets 内にアセットがあるなら set "PROJECT=C:MyTestMyTestProject"
  80. 80. 古いバージョンの Unityから持ってくるとき
  81. 81. 古いバージョンのUnityからのポーティング ● 通常のUnityのバージョンアップと変わらない ○ ネームスペース、API名の変更(ほぼ自動) ○ 非互換な機能(すみません…) ○ 追加された機能 ■ Texture Importer などインポータ設定は確認が必要 ■ 追加されたプロパティは多くの場合自動的に イネーブルになる ■ 「余計なお世話」となってしまうときがある
  82. 82. Joy-Conからの入力
  83. 83. Joy-Conからの入力 ● Joy-Con ○ 付属のネイティブプラグインの使用を推奨 ■ HD振動、加速度・ジャイロセンサー 横持ち(「おすそわけ」)などにも対応 ○ Joy-Conの仕様は意外と大きい
  84. 84. Joy-Conからの入力 ● Joy-Con ○ 現状は、付属のネイティブプラグインから uGUIを操作できない ■ これを解消するには開発者側での InputModule の実装が必要 ○ 近い将来、InputModule を提供
  85. 85. Joy-Conからの入力 ● InputMangerによるJoy-Conアクセス ○ 現状は1人用の持ち方にのみ非公式に対応 ■ Joy-Conの「縦持ち」および、Proコントローラー ■ Windows上のXbox360コントローラと軸番号、 ボタン配置互換 ■ PCで開発してそのまま実行可能 ○ HD振動、加速度・ジャイロセンサー、横持ち未対応 ○ 簡易的な「動作確認用」の機能と考える
  86. 86. セーブデータ
  87. 87. セーブデータ ● セーブデータ ○ 付属のネイティブプラグインの使用を推奨 ○ Nintendo Switchに限らず、コンソール機向けUnityは、 PlayerPrefsに対応していない ■ アカウント等の扱いがからむため ○ 何らかの方法でシリアライズしてセーブ・ロード
  88. 88. パッチ
  89. 89. パッチサイズは できるだけ小さく
  90. 90. Asset Bundleを必ず使う パッチ
  91. 91. パッチ(まとめ) ● モバイル系プラットフォームで用いられている 基本的な技法を踏襲する ○ AssetBundleを小さめの粒度で作る ■ 例:プレイヤー1,2、敵1,2,3、設置物1,2,3 ○ Resourcesは最小限に ○ Streaming Assetsも検討 ○ シーンに直接アセットを入れない
  92. 92. パッチ ● Unityを使う場合、基本的に変更のあった、 ビルド後のファイルがパッチ対象となる ○ 実行ファイル ○ Resources(フォルダ内全体で1ファイル生成) ○ シーン(シーンごとにファイル生成) ○ アセットバンドル(開発者が指定)
  93. 93. パッチ ● 実行ファイル ○ 対処方法なし
  94. 94. パッチ ● Streaming Assets ○ 音楽、動画など ○ マルチプラットフォーム開発時は他の プラットフォームのアセットが混じらないように注意
  95. 95. パッチ ● Resourcesフォルダ ○ ビルド時に1つのファイルになる(resources.assets) ○ Resources内のファイルが変更された場合、 Resources全体がパッチ対象になる ○ このため、Resources内の容量は最小化するのが望まし い
  96. 96. パッチ ● シーン ○ ビルド時にシーン毎にファイルを生成 ■ シーン内の全アセットが単一ファイルになる (sharedassetsN.assets) ○ シーンに直接アセットを入れている場合、 シーン内の何か1つを変更すると、 ビルド後のシーンファイル全体がパッチ対象となる ○ 結果として、パッチが非常に大きくなる
  97. 97. パッチ ● Asset Bundle ○ どうやって分けるか? ■ 「変更のありそうな単位」にする ■ 「プレイヤーA」「敵A」「敵B」などなど ○ ワークフロー上の負担も考慮 ■ 「Unite Tokyo アセットバンドル」などで検索 ○ Asset Bundle Graph Tool (午後の講演)
  98. 98. 動画を流したい
  99. 99. 動画 ● MP4 + H.264に対応 ● 再生フレームレートは 60.00 fps ○ NTSC の 59.94Hz ではない ● Nintendo Switch用Unity内にサンプルコード付属
  100. 100. microSDカードへの対応
  101. 101. microSD カード ● 速度を気にしすぎる必要は無い ○ 遅い microSD カードなど ● 音楽や動画の再生がうまくいかない場合はあり得る ● その場合でも「落ちない」「進行不能にならない」ようにする https://www.nintendo.co.jp/support/switch/data_management/microsdcard/
  102. 102. 本体内蔵フォントを使う
  103. 103. 本体内蔵フォントを使う ● Unity上で、本体内蔵フォントを使うことができる ○ 通常のフォントとして使用可能 ○ 中国語(繁体字、簡体字)など、 容量が大きいものに使うと便利 ○ ユーザ名表示等は企画上「当たり前の機能」という位置づ けだが、マルチリージョン、言語対応を独自フォントで真面 目に実装すると大変
  104. 104. なぜかガクガクする
  105. 105. Unity Editor 内蔵 Profilerを使いましょう
  106. 106. プロファイリング (Unity Profiler) ● Unity Editor 上でも、実機でも使用可能 ○ Development Build を指定する ● Unity Editor 上で確認 ○ Window > Profiler
  107. 107. プロファイリング (Unity Profiler) ● 関数ごとの時間 ● メモリアロケーション量 ● CPUやメモリのグラフ
  108. 108. プロファイリング (Unity Profiler) ● スパイク(処理量の極端な増加)に注目する ● Unity Editor (≒ PC) 上でスパイクが出ていたら、 ほぼ必ず実機でもスパイクが出る ● まずは Editor 上でスパイクをすべて潰す ● PCビルド版も試す ● その後実機で計測を必ず行う ○ PCと実機は違う!
  109. 109. プロファイリング (Unity Profiler) ● スパイク(処理量の極端な増加)のよくある理由(1) ○ Garbage Collection (GC) ■ GC Alloc を削減 ■ 文字列操作、特にデバッグログ生成に注意 ■ Mono Heapの大きさに注意 ● Mono Heapが大きいほどGCに時間がかかる
  110. 110. プロファイリング (Unity Profiler) ● スパイク(処理量の極端な増加)のよくある理由(2) ○ Physics関連 ■ Fixed Timestep (前述) を見直す ○ ロード、インスタンス生成や非同期処理 ■ 何をロード、処理しているか追いやすくする
  111. 111. プロファイリング (Unity Profiler) ● 実機でのプロファイリング (Unity Profiler) ○ 「PC比で何倍の時間がかかっている」かを調べる ■ PC上での性能目標を定義しやすくなる ○ PCと比べてワーカスレッド数が違う点に注意する ■ Unityのエンジン内のマルチスレッド処理の 実行速度が変わる ● Physics, Renderer, Occlusion Culling など
  112. 112. ワーカスレッドの動作の確認方法 プロファイリング (Unity Profiler)
  113. 113. プロファイリング (Unity Profiler) ● Deep Profileを使う
  114. 114. プロファイリング (Unity Profiler) ● Deep Profileを使う ○ Editor, 実機とも使用可能 ○ 処理速度は低下する ○ 代わりに関数単位の詳細な計測が可能 ■ 時間 ■ GC Alloc ○ 性能目標を定めてから使うと良い ■ 例:「あと 2ms 削りたい」
  115. 115. プロファイリング (Unity Profiler) 【Unite 2017 Tokyo】 最適化をする前に覚えておきたい技術 (弊社 黒河による) https://www.slideshare.net/UnityTechnologiesJapan/unite-2017-tokyo-75775983 https://www.youtube.com/watch?v=rvnsU8oCMcI ロード時間やガベージコレクション対策あり
  116. 116. SDK付属の CPUプロファイラを使う
  117. 117. SDK付属CPUプロファイラ ● いつ使うか? ○ 最初はUnity内蔵のプロファイラを使う ○ もう詰められる部分が無くなったときが出番 ○ IL2CPPの出力結果を見るので、実際のC#のコード上での クラス名、関数名が分かりにくい場合がある
  118. 118. ポストエフェクトを盛って 画面をボカしたり キラキラ☆させたい
  119. 119. Post Processing Stackを使う
  120. 120. Post Processing Stack ● Unityの標準ポスト処理 ● Image Effectsはレガシー扱い ○ Post Processing Stack のほうが1.5 倍ぐらい高速 ● Asset Store 版と GitHub 版がある https://github.com/Unity-Technologies/PostProcessing ○ GitHub版のほうが頻繁に更新されている
  121. 121. Post Processing Stack ● Post Processing Stack (詳しくはWebで!) 【Unite 2017 Tokyo】 ゲームの見た目も盛ったら変わる!!!!ヤバい!! ポストプロセス!!入門!!!!!!!!! (弊社 高橋による) https://www.youtube.com/watch?v=r5mNmH68KPQ Post Processing Stack の使い方の説明
  122. 122. GPUが重い? ような? 気がする?
  123. 123. レンダリングとGPUデバッガ ● プラットフォームを問わず、GPUネックのケースは意外と多い ● 開発後半までひきずることもある ● 早期に問題を特定したほうが、後で楽になる ○ アセット量産前がベストなタイミング ● ポーティング時に、GPU特性の違いで重い場合もある
  124. 124. レンダリングとGPUデバッガ ● 何を調べるか? ○ GPU処理上の問題の有無 ■ 本当にGPUが重いのか? ○ 最適化の対象候補 ■ どの処理が重いのか? ○ 最適化案 ■ どのように処理を軽減するか?
  125. 125. レンダリングとGPUデバッガ ● まず、本当にGPUが重いのか確認
  126. 126. レンダリングとGPUデバッガ ● まず、本当にGPUが重いのか確認 ○ Development Buildで実機実行し、コンソールを確認
  127. 127. レンダリングとGPUデバッガ ○ カメラの Viewport Rect の Width, Height を 0.25 などにして、擬似的に解像度を下げて実機で実行 ● フレームレートが向上するならGPUネックの可能性有
  128. 128. レンダリングとGPUデバッガ ● GPUがボトルネックだと判明したら ● 無駄な描画をしていないか、PC上で調査 ○ RenderDocをインストール ○ https://docs.unity3d.com/Manual/RenderDocIntegration.html ○ Unity Editor上で描画のキャプチャができる
  129. 129. レンダリングとGPUデバッガ ● RenderDocキャプチャ ● DrawCall単位の確認が可能 ○ 描画先 ○ 描いているポリゴン ○ シェーダ ○ 使用しているテクスチャ ○ テクスチャのフォーマット
  130. 130. レンダリングとGPUデバッガ ● RenderDoc上で確認すべきことの例 ○ 一見あり得ないミスに見えるが、高い技術と経験のある チームでも、忙しくなると確認を忘れがち
  131. 131. レンダリングとGPUデバッガ ● RenderDoc上で確認すべきことの例 ○ 無意味なカメラが動いていないか? ■ → カメラをディゼーブルに ■ 動作しているカメラ数を表示して自衛
  132. 132. レンダリングとGPUデバッガ ● RenderDoc上で確認すべきことの例 ○ 無意味なポストエフェクトは無いか? ■ → ポストエフェクトを切る
  133. 133. レンダリングとGPUデバッガ ● RenderDoc上で確認すべきことの例 ○ 完全に透明な半透明ポリゴンを描画していないか? ■ → 完全に透明になった時点で描画をやめる
  134. 134. レンダリングとGPUデバッガ ● RenderDoc上で確認すべきことの例 ○ いつも隠れてしまうものを描画していないか? ■ → 隠れることが分かる場合、描画しない ■ 複雑なシーンにはオクルージョンカリングも検討
  135. 135. レンダリングとGPUデバッガ ● RenderDoc上で確認すべきことの例 ○ 隠れる面積が大きい不透明ポリゴンを、奥→手前の順で 描画していないか? ■ → 可能なら、手前→奥になるように、 Material.renderQueue を調整 ■ 例:「地面」や「遠景」はできるだけ後で描く
  136. 136. レンダリングとGPUデバッガ ● SDK付属の実機用GPUデバッガ ○ Unityも標準で対応 ■ ビルド時に指定 ○ 実行時のリアルタイム負荷グラフ ○ フレームをキャプチャ ■ RenderDocより詳細な内容を見られる
  137. 137. レンダリングとGPUデバッガ ● フレームキャプチャ時 ○ 使用しているシェーダ、頂点、テクスチャ確認可能 ○ ドローコール単位の消費時間を確認可能 ■ 使い方の例:ポストエフェクトのエフェクト毎の処理時間 を測って伝え、「予算」の中に収まるようにデザイナ側 で検討
  138. 138. マスター提出前の QAってどうすれば良いの?
  139. 139. QAをどう行うか? ● 普段から実機で動作を確認する ● QAは基本的に実機で行う ● チェック項目が定められているので、それに従う ○ きちんとチェックしないと通らないので注意 ● 意外と時間を食うのでスケジュールにきちんと織り込む
  140. 140. まとめ 本日のまとめ
  141. 141. まとめ ● Nintendo Switch開発者はいますぐ Unityを使用可能 ● 困ったら開発者ポータル掲示板で質問 ● Unity 5.6 で作る ● AssetBundle を必ず使う
  142. 142. CEDEC会場内 任天堂さまブース Unityブース でもご質問ください
  143. 143. ご清聴ありがとうございました!!
  144. 144. Q&A

×