1人で！？PC向け4K60fpsゲームを、Nintendo Switch™向けに最適化できたお話
11.6K Views
October 25, 22
スライド概要
最大8人、コアメンバー3人という状況で、国産初のハイエンド機向け4K60FPSホラーゲーム「夕鬼」を発売し、その後「プログラマー1名、アート1名」で同タイトルをNintendo Switch™に移植しました。
担当者はグラフィクス系のプログラムの専門家ではなく、開発のために費やせる時間も長くはありません。
そのような状況でたった1名、どのようにこの課題をクリアしたのかをお話しします。
大規模な開発会社で使える最新の事例ではなく、小規模の開発者が、「手を伸ばせる範囲で」いかに問題を解決したかという事例のご紹介です。
こんな人におすすめ:
・ベストよりベター！とにかく素早さ＆コスト重視で最適化したい人
・スーパープログラマーなどいない！ミドルスキルでなんとかなる手法が知りたい人
・小規模開発の実例を知りたい人
受講者が得られる知見:
・ローエンド機でも動作可能なベイク済多重シーン構成
・費用対効果の高い最適化手法
・極小人数デベロッパーで4K60FPSゲームを作った人の苦悩と実例
出演:
由比 建 (株式会社トライコア)
--
初出: SYNC 2022 #UnitySYNC
https://events.unity3d.jp/sync/
リアルタイム3Dコンテンツを制作・運用するための世界的にリードするプラットフォームである「Unity」の日本国内における販売、サポート、コミュニティ活動、研究開発、教育支援を行っています。ゲーム開発者からアーティスト、建築家、自動車デザイナー、映画製作者など、さまざまなクリエイターがUnityを使い想像力を発揮しています。
関連スライド
各ページのテキスト
株式会社 トライコア https://www.tri-core.co.jp/ １⼈で！？PC向け4K60fpsゲームを、 Nintendo Switch™向けに 最適化できたお話 Nintendo Switch™は任天堂の商標です
⾃⼰紹介 由⽐ 建 （ゆい たける） • • • • • 代表取締役社⻑ (プログラマー) 元家庭⽤ゲーム機向けゲーム会社 １歳の娘がいます カヤック釣りとお庭いじりが最近の趣味 家族でももクロ⼤好き
事業内容： コンピューターゲームの企画・制作・販売 デジタルコンテンツの企画・制作・販売 専⾨学校等の講師業務 各種セミナー等の企画・運営 前各号に附帯関連する⼀切の事業 事業情報 設⽴： 2017年5⽉ 役員： 代表取締役 由⽐ 建 従業員数： 7名 （2022年9⽉現在）
所在地 • 博多からバスで１０分、地下鉄７分。福岡空港から合計２０分。 • アクセス抜群、グルメのまち！
お話の前に
前提として • ⾃社ゲームが作りたくて独⽴した極⼩⼈数開発者 • プログラマーの技術⼒は普通 （CTO不在） • 納期短！１⼈で最適化できる最短の⽅法を模索 先端を⾛る⼤企業では使えません。
⾃社開発タイトル ⼣⻤ 国産初の4K60FPS対応インディホラー：「⼣⻤」 PlayStation®5 / PlayStation®4 / PC Xbox Series X / Xbox One / Nintendo Switch™ 向けに好評発売中！ （⼀部の機器ではパッケージ版も販売）
⼣⻤ PV
⼣⻤ PV
⼣⻤ PV
⼣⻤ PV
⽤語 • GD: ゲームデザイナー、企画職 • AT: アーティスト、グラフィックデザイナー • PG: プログラマー
⼣⻤のシーン構成
要件 • マップの切り替えがシームレスで、範囲が広⼤ • ライト情報等がベイクされた⾼精細な部屋が複数ある • アセットが限られているので⼩物を多数配置して差別化 独⾃のシーンロードを実装する必要がある
シーン構成 • root : 敵AI、イベント、⼦シーンを含めた オクルージョンカリング、⼀部演出⽤オブジェクト • nav : ナビメッシュ情報 • childXX ： ライトベイク設定、⾒た⽬に関わるステージオブジェクト
シーン構成 • 必要な数のchildを読み破棄することで広⼤な範囲の管理が可能 • 細かくベイクされたchildが使えるので⾒た⽬がきれい • childを細かく分ければモバイルでも動作 かなりの広範囲 →Child例。もう少し細かく 分けるべきだった。
シーン構成 : root • root • nav : 敵AI、イベント、⼦シーンを含めた オクルージョンカリング、⼀部演出⽤オブジェクト : ナビメッシュ情報 • childXX ： ライトベイク設定、⾒た⽬に関わるステージオブジェクト 基本的にはGDとPGが触る。シーンを横断する情報が⼊る。 最終的にはATが調整したChildシーンと共に開き、各情報（オクルージョンカリング等）を反映させてベイクする。
シーン構成 : nav • root : 敵AI、イベント、⼦シーンを含めた オクルージョンカリング、⼀部演出⽤オブジェクト • nav : ナビメッシュ情報 • childXX ： ライトベイク設定、⾒た⽬に関わるステージオブジェクト GDがざっくりと作成したのち、 ATがchildシーンで⾒た⽬を調整。 その後GDが⾒た⽬をナビメッシュに反映させる。 AT作業に伴って変更されることが多いのでシーン分離。 データを焼き付けるのはroot。
シーン構成 : child • root : 敵AI、イベント、⼦シーンを含めた オクルージョンカリング、⼀部演出⽤オブジェクト • nav : ナビメッシュ情報 • childXX ： ライトベイク設定、⾒た⽬に関わるステージオブジェクト GDがざっくりと部屋割りをしたのち、⾒た⽬をATが作りこむ。 ライトベイク情報、ポストプロセスが⼊っている。
フローまとめ • • • • • • • GDがテンプレートからrootを準備 GDがホワイトレベルとして仮child複数とnavを作成 ATが仮childを本データに差し替え GDが本childをもとにnav調整 AT作りこみ、本childでnavに影響ある変更があればGDに通知 GD作りこみ、ゲームデザイン上childに変更がいればATに通知 PGはみんなが困ったら助ける。基本あまりシーンはいじらない
最適化について
デバッガーは実機に繋ごう • 実機とPCで負荷のかかるポイントが違う • 単純にPCで〇倍速くなったから⼤丈夫！とはならない • シェーダーキーワードの違いから発⽣したバグも
描画部分の負荷を⾒るために、専⽤ツールを使おう • • • • ポストプロセスやテクスチャ転送の負荷を実感するのに助かった とても⾒やすい どの機能を切り、残すのかあたりをつけやすい シェーダーの不具合の発⾒にもつながる
基本⽅針 • URPに変更、ライティングとポストプロセス全部やり直し • ステージ１で実験と落とし所策定 • Volumetric LightのシステムがBuiltin依存だったが、描画している モデルの量からして無理筋 • Builtin依存のVolumetricLightはURP対応の別物に
ShadowCast激重問題 • URPにしたものの、ShadowCastがCPUを酷使 • MixedLightingをShadowMaskからSubtractiveに • 影を落とすのはディレクショナルライト1本、動くものに絞った • メッシュ分割は導⼊コストから今回⾒送り • ポストプロセスを最優先したら、Cast３桁でオーバー。１桁に抑えた • 広範囲にリッチな描画を⾏うゲームの選択肢はこれ１つ？ →背景に重なるように影がつくので 違和感が少ない ←ただし、⾊計算の結果 妙な⾊の影がつくことがある
ハイクオリティな⾒た⽬にはライトベイク必須 • childシーン1つ（最⼤１０部屋程度につき）1ベイク • もっと少なくするべきだった • 接続部を扉で区切り、扉に⼿をかけた時点でライトプローブとア クティブなシーンは切り替え • 滑らかには⾒た⽬が変化しない • ⼿動でライトプローブの再計算(LightProbes.TetrahedralizeAsync)を⾏う必 要がある • 切り替えの瞬間が⾒えない⼯夫が必要
TextureQualityオプションはお⼿軽 • PlayerSettings→Quality→TextureQualityで HalfResolutionを選ぶ • 当然⼿動で⼀つ⼀つテクスチャの圧縮設定をするほうが効果は⾼い • ワンオプションですべてを忘れられるのは強い • 実は⼣⻤はテクスチャを使いすぎていて、MipMapLevelの⾃ 動調整により⾼解像度があまり活かされなかった • 結果この設定でも⼤きな違和感は⽣まれなかった
雑でもいいからアセットバンドル化しよう • アセットバンドル怖い！分からない！ • 巨⼤なSharedAssetsを可能な限り減らす。 ここだけクリアすればひとまずはOK ⼣⻤の実例しては、 ⼀部のサウンドが巨⼤なSharedAssetsにパッキングされ、 ⾳を鳴らした際にこのデータのロードが⾛り、画⾯が⼀瞬⽌ま る不具合が発⽣ ←なにもしていないとすべてここに⼊り、ゴリゴリ増える
⼣⻤のアセットバンドルポリシー • シーン、モデル、テクスチャ、マテリアル、シェーダー＋ ShaderVariantCollection、サウンド • モデル/テクスチャ/マテリアルはさらにシチュエーションで分ける (病院、学校、和室、共通、シナリオ等) 上記ルールで雑にパッキング、ゲーム起動時に全部オープンしたところ ロード爆速化＋ファイルサイズ60％縮⼩ 恐れずに必須レベルでやるべき ※ファイルパッキングを意識したフォルダ分けは初期から⾏おう！
Tips
なんか実機で⾒た⽬がおかしい！ • ほぼ原因はShaderVariantのストリップ • RenderPiplineの設定やProjectSettingの中にある ShaderStripの機能をオフにして確認 • 当然ながらビルド時間が超延びる • メモリにも優しくない • 狙い通りにストリップが⾛るように調整 • 結局はShaderVriantの仕組みを正しく理解することが必要 • ⾃前でストリップする仕組みを⼊れている場合は特に注意！ ⿊河さんのエントリーがとても参考になりました
ビルドに時間がかかる！ • ⼤体原因はShaderVariantの⽣成 • またお前か • standard/litのバリアント⽣まれすぎ問題 • UnityのShaderStrip機能を使ってもまだ⻑い • Unity公式ブログに⾃前でストリップする⽅法が！ • 脳死ではつかえない…！ • ShaderVariantCollectionを使ってストリップする⼿法をとった • 「ビルド⻑いな…」と感じたら勉強の合図と思うしかない • 調べれば⾊々出てくるが、脳死で使うと痛い⽬をみる • 基本は公式のStrip設定でなんとかなるはず
もっとビルド時間を減らしたい • standard/lit等ビルトインのシェーダーをコピーし、⾃前で キーワードを調整することでバリアントの数を抑制できる 例）どうせソフトシャドウ使わないから_SHADOWS_SOFT のキーワードをmulti_compileじゃなくしてしまおう！ ※検証の時間が⾜らず、最終的に⼣⻤ではこの⼿法を取りません でした
さいごに • まずは公式の機能/ツールをちゃんと調べよう • 回り道が正解の道のことも多い • コミュニティ⼤事。助け合おう
Thank You！