運営中コンテンツにおける大型アップデート成功のための考え方とUnity最適化手法

Slide 1

Slide 1 text

Slide 2

Slide 2 text

2/79 アジェンダ •  本講演では、モバイルアプリの⼤型アップデート実現に必要となる効果的な３Dグラフィック表現の事例、アップデート成功のための考え⽅とUnityを⽤いた開発⼿法について、弊社での適応事例を元に解説します •  開発においては、アップデート規模と実現難易度が⽐例する傾向があります。⼤型アップデートではユーザーの新しい体験につながる新機能を追加したい。運営中アプリは機能追加を必要最低限にしたい

Slide 3

Slide 3 text

3/79 ⾃⼰紹介 •  ⾦井⼤ •  Cygames Research/シニアゲームエンジニア •  ゲーム開発を軸にVR、ゲームエンジン、グラフィックスなど、幅広い分野の研究開発に従事。 •  本件で紹介する⼤型アップデート施策では、3Dグラフィックス関連のマネジメントとアーキテクト、実装を担当

Slide 4

Slide 4 text

4/79 アジェンダ • コンテンツと⼤型アップデート施策の概要について • ⼤型アップデートで⾏われた3Dグラフィックスのクオリティアップの詳細について • 運営中コンテンツの⼤型アップデートを成功させるための考え⽅、Unityを使った開発の進め⽅について

Slide 5

Slide 5 text

コンテンツと⼤型アップデート施策の概要について

Slide 6

Slide 6 text

6/79 弊社での適応事例の紹介 •  2015年にリリースのゲームコンテンツ •  Unityで60fpsを担保しつつ3Dグラフィックス表現しているのが⼤きな特徴。キャラクター種類数は200体以上 •  2017年6⽉に⼤型アップデートを適応。運営チームとは別にアップデートチームを結成し、三か⽉で開発を⾏う 2015年アプリのリリース 2017年⼤型アップデートアップデートチームにて三か⽉間で開発

Slide 7

Slide 7 text

7/79 Speaker Deckに資料があります •  Unite2016で講演した内容とほぼ重複する内容です •  Unity 3D 考え⽅でググると出てきます https://speakerdeck.com/cygames/unity-sumahode3dgemukai-fa-zui-shi-hua-surutamefalsekao-efang

Slide 8

Slide 8 text

8/79 なぜ⼤型アップデートを⾏うのか •  3Dグラフィックスの品質を底上げをする必要があった •  リリースから２年以上が経過している •  3Dグラフィックスを⽤いたアプリも増えました •  リリース前から「⾼品質版を⽤意したいね」という話はあり、「必要になったらやりましょう」としていた •  時は来た

Slide 9

Slide 9 text

9/79 ⼤型アップデートで⾏われた事 •  グラフィックスの⾼品質版を追加 •  2D版と3D版を含め、ゲーム中の品質設定の選択肢が６段階に３D ⾼品質(アップデートで追加) ３D 標準３D 軽量２D ⾼品質(アップデートで追加) ２D 標準２D 軽量

Slide 10

Slide 10 text

10/79 ⼤型アップデートによる品質選択の変化 •  従来は標準版が最⾼スペックであったが、アップデートによりミドルレンジに降格⾼品質版標準版軽量版ハイエンド端末でのみ体験できる⾼品質な画⾯を提供ミドルレンジ端末で⾼品質な画⾯を提供、 60fpsをキープ幅広い動作保証のため限界までスペックを落としつつ60fpsをキープ

Slide 11

Slide 11 text

⼤型アップデートで⾏われた3Dグラフィックスのクオリティアップの詳細について

Slide 12

Slide 12 text

12/79 3Dグラフィックスの⾼品質化で⾏ったこと •  イメージエフェクトのクオリティアップ •  プロジェクションシャドウ •  ミラー •  ライトシャフト、その他多数 •  キャラクターのクオリティアップ •  シェーダーの拡張（リム、スペキュラ、環境マップ •  キャラのスペック向上（1500tri程度） •  キャラの法線データを⼆重化 •  専⽤アセットバンドルの構築 •  画⾯解像度 •  フレームバッファの⾼解像度切り替え •  MSAAの導⼊ •  ETC2フォーマットの導⼊ •  OpenGLES 3.0への対応 •  Unityのバージョンアップ

Slide 13

Slide 13 text

イメージエフェクトのクオリティアップ

Slide 14

Slide 14 text

14/79 イメージエフェクトのクオリティアップ •  シェーダーの対応が中⼼となるため、プログラマ⼯数が発⽣するが、既存アセットの修正量は少ない •  種類によっては描画パスが増え頂点処理コストが上昇するが、基本はフラグメント処理コストが上昇する処理負荷を基準に判断できるため、採択が簡単。運営中のアップデートに適している

Slide 15

Slide 15 text

15/79 軽量版のパイプライン •  UnityのレンダリングはCameraを基準に制御される •  軽量版での3Dレンダリングは、全てForwardBase中で⾏われている 15 Camera ForwardBase

Slide 16

Slide 16 text

16/79 標準版のパイプライン •  標準版ではBloomとDOF(被写界深度)が動作、ForwardBaseに加えてShadowCasterによるUpdateDepthTexture処理と、 ImageEﬀect処理が追加される •  UpdateDepthTextureにより描画頂点数は2倍弱に増える 16 Camera UpdateDepthTexture ForwardBase ImageEﬀect

Slide 17

Slide 17 text

17/79 ⾼品質版のパイプライン •  プロジェクションシャドウ、ミラー処理等でカメラが増え、対となるForwardBaseとImageEffectが追加される Camera UpdateDepthTexture ForwardBase ImageEffect Camera (Mirror) ForwardBase ImageEffect Camera (ProjectionShadow) ForwardBase ImageEffect

Slide 18

Slide 18 text

18/79 プロジェクションシャドウ •  Unity標準のソフトシャドウはモバイルで利⽤できないため、⾃前で実装する •  ライトスペースのカメラを⽤意してシャドウマップをレンダリング、特定のモデルに対してプロジェクションする •  描画パスが増えるので、影を落とすモデルをLayerで管理するハードシャドウはジャギーが⽬⽴つソフトシャドウにより柔らかい光源を表現

Slide 19

Slide 19 text

19/79 •  ミラー⽤カメラを⽤意して鏡⾯レンダリング、特定のモデルに対してプロジェクションし、地⾯への映り込みをリアルタイム処理する •  UnityのReplaced Shadersを利⽤して、ミラーパスでの描画に利⽤するシェーダーの品質を制御するミラー Tags { “Mirror"=“Chara" } Character.shader （Mirrorタグを持たない） Object.shader Tags { “Mirror"=“Chara" } Mirrored.shader Replace Camera.SetReplacementShader( Mirrored, ”Mirror” )

Slide 20

Slide 20 text

20/79 ライトシャフト •  深度値を参照しブラーをかけ、放射状に散乱する光を再現する。イメージエフェクトのみで完結し、光源の表現を豊かにできる •  UnityのLegacy Image EﬀectにあるSunShaftsをベースにし、サンプル数やブラーのかけ⽅をカスタマイズ深度バッファを元にブラー処理結果をフレームバッファへ

Slide 21

Slide 21 text

21/79 レンズフレア •  Unity標準のレンズフレアにて対応。コリジョン機能が必要となるため⾃前で実装するのは⾮現実的 •  光源が隠れた際にフレアが正しく消えないと不⾃然に⾒える。コライダーの設定にはアセット作成の⼯数が発⽣するため、作業⼯数が課題となる •  キャラクターは⼈型しかないので、ひな型を作って量産化、問題があるデータを順次修正して対応 Unity標準機能でも⼀定品質を担保可能

Slide 22

Slide 22 text

22/79 ティルトシフト •  画⾯の上下、左右などをボカす機能。ImageEﬀectのみでかなり柔軟な表現が可能 •  DOFとは異なり深度値情報が不要なため、頂点負荷にやさしい •  Legacy Image Eﬀectをベースにカスタマイズ

Slide 23

Slide 23 text

23/79 まとめ •  イメージエフェクトは⼤型アップデートに含むか採択しやすい。処理負荷にのみに着⽬することができる •  基本の頂点スペックには配慮が必要。追加するイメージエフェクトによって描画パスの数が変動するため •  全てを⾃作する必要はない。Unity機能をそのまま利⽤したり、 Unity機能をベースとすることで開発期間を短縮し、空いた時間を他の要素のクオリティアップに回す

Slide 24

Slide 24 text

キャラクターのクオリティアップ

Slide 25

Slide 25 text

25/79 ライティングアルゴリズム変更の課題 •  前提として、シェーダーは全て⾃社で作成している。標準版までは軽量化のためライティングを⾏っておらず、diﬀuseテクスチャに陰影を描き込んでいた •  ライティングを強化し、キャラクターの動きに応じた陰影の変化や、スペキュラーやリム、環境マップなどの表現を⼊れたい •  しかしながら、テクスチャやシェーダーを変更せず表現をリッチにするのは限界がある

Slide 26

Slide 26 text

26/79 アセット修正の課題 •  本事例では、200体以上のキャラクターアセットが存在しており、極⼒⼿を⼊れたくない。既存アセットの修正には作業コストと管理コストが発⽣する •  シェーダー修正はプログラマーが⾏うため、適切に⾏えばアセット修正よりも格段に修正コストが低くなる既存アセットの修正と増加量が最⼩限となるよう、ライティングアルゴリズムを修正する必要がある

Slide 27

Slide 27 text

27/79 ライティングアルゴリズムの変更 •  検証の結果、キャラクターに以下を導⼊する •  リム •  環境マップ •  スペキュラー •  以下は検証を⾏ったが、対応を⾒送る •  ノーマルマップ •  トゥーンレンダリング https://docs.unity3d.com/ja/current/Manual/StandardShaderMaterialParameterSpecular.html

Slide 28

Slide 28 text

28/79 ライティングアルゴリズムの変更 •  リム、スペキュラ、環境マップの対応は、キャラクターやカメラ移動に応じた変化により⾮常に効果が⾼い。 diﬀuseテクスチャに描き込んだ陰影の修正も最低限となりそう •  ノーマルマップはデータ作成にあたりUVの⼤幅な修正が必要となり、フラグメント負荷も予想しずらいため、対応を⾒送り •  トゥーンレンダリングについてはテクスチャ陰影とのバッティングする要素が多く対応を⾒送り

Slide 29

Slide 29 text

29/79 •  リム、環境マップ、スペキュラーの強度を制御するためのパラメーターテクスチャを導⼊。専⽤のテクスチャを⽤意し、 RGBチャンネルで強度を制御する制御マップの導⼊制御マップ R G B 特定箇所のみ環境マップを有効化するといった⽤途には頂点単位の制御では不⼗分であり、制御マップが必須となる

Slide 30

Slide 30 text

30/79 正しいライティングを⾏うための課題 •  正しい法線情報を保持する必要がある。 •  標準版まではライティングしておらず法線情報を持っていない。正確には、アウトライン⽤に調整された法線を保持している •  リムや環境マップ計算には、正しい法線情報が必要となるが、 Unityのメッシュデータは２つ以上の法線情報を保持できないため、ライティング時に問題となるアウトライン幅等の調整をメッシュの法線で⾏っているため、正しい法線情報が⽋落している

Slide 31

Slide 31 text

31/79 正しいライティングを⾏うための課題 •  Unityはスキニング結果が頂点シェーダーに渡ってくるため、 UV2に法線を⼊れてもスキニングされた法線を算出できない •  tangentに法線を持たせればスキニングの問題は解決するが、法線を埋め込む⽅法が⾒当たらない。MayaからのFBX出⼒時に tangentへアクセスできない Vertex Normal Tangent UV0 頂点シェーダースキニングされるスキニングされない

Slide 32

Slide 32 text

32/79 •  AssetImport時に処理すれば解決できる •  UV2とUV3に法線情報を⼊れたFBXを別途⽤意し、UnityのFBX インポート時にUV2とUV3をtangentへ移動させる対になる２つのFBXを AssetImport時に処理し、 tangentに法線を⼊れる２つの法線情報を保持させる⽅法従来のFBX 正しいNormalを保持したFBX スキニング処理された２つの法線を持つ Meshとなる

Slide 33

Slide 33 text

33/79 オーサリングの課題と解決 •  今まではMaya上の⾒た⽬がUnityと概ね⼀致していたが、ライティングアルゴリズム変更により⼀致しなくなった。 •  リムやスペキュラ、環境マップをUnityでしか確認できないのはアーティストからすると⾮効率。200体以上のデータ確認と今後のデータ作成を踏まえた対策が必要 •  Mayaでプレビューできるのが直観的。CGFXでも動作するようシェーダーを組み直し、イテレーション速度と品質を担保する

Slide 34

Slide 34 text

34/79 まとめ •  ライティングアルゴリズムの変更は、影響範囲について最⼤の配慮が必要。既存アセットの修正数によってはアルゴリズムの変更が困難となるため、そもそも適応できない可能性があった •  導⼊したアルゴリズムは⾮常に効果的であった。キャラクターやカメラの移動に応じた陰影の変化は視覚的に重要 •  アーティストへの配慮が必要。ワークフローが変化しDCCツール上でのプレビューの優先度が上がる

Slide 35

Slide 35 text

画⾯解像度

Slide 36

Slide 36 text

36/79 フレームバッファの⾼解像度化とMSAA •  ⾼品質版では解像度が選択可能となった。従来の標準版はジャギーが⽬⽴っており、特にiPhone6Plusなど横1920以上の端末では顕著になっていた •  標準解像度ではMSAAx4を適応 •  ⾼解像度ではドットバイドットになるよう配慮。将来的な端末の⾼解像度化を考慮して、iPad Pro想定の上限値を設定している解像度 MSAA 標準設定横1280で固定 MSAAx4 ⾼解像度設定横2732が上限無効

Slide 37

Slide 37 text

37/79 MSAA導⼊時の注意点 •  マルチサンプルによりテクスチャのサンプリング範囲が広がり、 UVレイアウトによっては、テクスチャにノイズが表⽰される意図しない近傍ピクセルが表⽰されてしまうこのテクスチャを左半分だけ貼っても

Slide 38

Slide 38 text

38/79 MSAA導⼊時の注意点 •  テクスチャを修正することで対応 •  背景はノイズが⽬⽴つ箇所のみパディングを４ドットに拡張（従来は２ドット確保） •  キャラクターについてはUV外にピクセルを拡⼤。 3D-Coatを⽤いテクスチャのパディング幅を４に調整することで対応

Slide 39

Slide 39 text

39/79 まとめ •  解像度変更は採択しやすい。処理負荷に影響するが、基本的にアセット修正は不要 •  パディングは統⼀ルールを設ける。マルチサンプルによるノイズは発⽣個所が予測できず、後追いの対応はコストが⾼い •  ジャギーの緩和⾃体は効果がある。パディングルールさえ統⼀されていれば作業コストなくスペックの選択肢にできる

Slide 40

Slide 40 text

ETC2フォーマットの導⼊

Slide 41

Slide 41 text

41/79 なぜETC2フォーマットが必要なのか？ •  Androidプラットフォームにおけるテクスチャ圧縮時に発⽣するバンディング問題を解決したい •  実は「圧縮テクスチャの品質を改善したい」という声が⼤型アップデート前より強く上がっていた •  ⾼品質版対応に伴い３Dグラフィックスの品質が向上したため、バンディング問題を解決する必要が出てきた

Slide 42

Slide 42 text

42/79 バンディングの例 •  繊細な表現に問題が発⽣する。キャラクターの表情など ETC ETC2 ETC ETC2 トーンカーブを調整した結果元画像

Slide 43

Slide 43 text

43/79 バンディングの現実的な解決⼿法 •  ETC2は圧縮時間と品質をバランスよく担保することができる •  ETCでも圧縮品質をBestにすることによりバンディングをある程度除去できるが、圧縮時間に40秒かかり現実的ではない。対象のテクスチャは1000枚以上存在するため、開発の速度に⼤きなインパクトを与える ETCフォーマット ETC2フォーマット圧縮品質 Normal Best Normal Best バンディング × 〇〇〇圧縮時間約0.5秒約40秒約0.5秒約70秒

Slide 44

Slide 44 text

44/79 なぜETC2を使っていなかった？ •  OpenGLES 2.0ではETC2は拡張扱いであり、未サポート端末ではメモリ使⽤量が６倍となり、アプリ⾃体が動作しなくなるリスクが⾼い（テクスチャがフルカラー展開されるため） •  Unityのテクスチャは１プラットフォーム中で複数フォーマットを保持することができないため、テクスチャ⾃体をETC/ETC2⽤に複数保持しておく必要がある •  UnityにはETC2サポートを問い合わせるインターフェースが存在するが、Unity5.1.2ではバグにより正しく判定されないため、例外対応を⾏うことができない

Slide 45

Slide 45 text

45/79 ETC2フォーマットを導⼊するために •  前提としてUnityのバージョンアップが必須となる •  キャラクターのみETC2を利⽤、AssetBundleを⾼品質版と標準版とで２種類保持する •  標準版まではETCフォーマット、⾼品質版はETC2を利⽤するように対応するキャラクターの品質は上がるが、対応に必要となるコストは⼤きい

Slide 46

Slide 46 text

46/79 まとめ •  ETCはテクスチャ品質が低く、バンディング問題が発⽣しやすい。圧縮率での調整は⾮現実的 •  ETC2を採⽤するには動作保証する端末を適切に⾏う •  Unityにもバグは存在するが、広い⼼で受け⽌めよう

Slide 47

Slide 47 text

運営中コンテンツの⼤型アップデートを成功させるための考え⽅、Unityを使った開発の進め⽅について

Slide 48

Slide 48 text

48/79 ⾃⼰紹介・名前：稲⽥健⼈・職業：エンジニア・⼤型ネイティブアプリで新規開発からリリース、運⽤まで全てに携わり、2D、3D関わらずゲーム全般の開発に従事

Slide 49

Slide 49 text

49/79 アジェンダ • Unityバージョンアップを成功させるための考え⽅と開発の進め⽅ • アプリの⼤型アップデートを成功させるための考え⽅と開発の進め⽅

Slide 50

Slide 50 text

Unityバージョンアップを成功させるための考え⽅と開発の進め⽅

Slide 51

Slide 51 text

51/79 今回の⼤型アップデートでは •  今回の⼤型アップデートでは、Unityバージョンを5.1.2から 5.4.5へバージョンアップした •  以前よりUnityのバージョンアップが可能か検討を⾏っていたが、バージョンアップ検証と安定運営との両⽴が難しく、先送りとなっていた •  ⼤型アップデートによるグラフィックスの品質向上に伴い、 ETC2フォーマットの採⽤が必要となったため、Unityバージョンを上げることになった

Slide 52

Slide 52 text

52/79 Unityバージョンアップを⾏うための考え⽅ •  どう進めれば安定した運営を提供し続けられるのか •  運営側の負担が最⼩限になるように5.4.5への移⾏作業は全てアップデートチームが⾏った •  アップデートでは既存の機能の検証やバージョン違いによる不具合の修正、バージョン移⾏期間中のサポートなど多くの作業が発⽣する。作業を分担して運営チームには運営の作業に集中してもらう

Slide 53

Slide 53 text

53/79 今回のバージョンアップの前提 •  このプロジェクトでは、リリースしてからの２年間、Unityバージョンを上げたことがない •  運営に⼊ったプロジェクトでのUnityバージョンアップのポリシーは概ね２つのケースに分かれる •  基本は安定版を利⽤、バージョンアップやパッチ適応は最低限とする •  可能な限り最新バージョンに追従する •  安定版を利⽤すると機能追加に制限が⼊り、バグ対応が困難なケースがある。最新バージョンへの追従は、特にメジャーバージョンの変更時にインパクトが⼤きい •  今回のプロジェクトでは前者のケース

Slide 54

Slide 54 text

54/79 Unityアップデートをどのように進めるか？ •  プロジェクトには多数の運営スタッフが関わっており、安易なバージョンアップは危険。同プロジェクト内で新旧のリソースが混在してしまう、などの混乱が予想される •  どのバージョンに、チーム内のどの順番であげ、どのように混乱を避けるか、と計画性をもって取り組む必要がある •  アップデートチームがまずバージョン選定を⾏う。本来であれば可能な限り複数バージョンを検証したいが、社内での運⽤実績が多く、更にある程度検証済みの5.4.5p1を候補とする

Slide 55

Slide 55 text

55/79 ブランチ運⽤の構成図 develop develop_rich Unity5.4.5 release feature 定期的にマージ全ての作業が終わったらマージアップデート運営

Slide 56

Slide 56 text

56/79 コーディングのポリシー •  5.1.2と5.4.5のコードを混在させ、何時でもバージョン切り替えができるように開発を進める •  ⼤型アップデートの作業中は機能実装のテンポが速く、新旧バージョンで動作結果を⽐較したいケースが多々ある •  ２バージョンのみであれば、#ifでの分割も現実的と判断

Slide 57

Slide 57 text

57/79 シェーダーのAutoUpgrade対応 •  同様の理由から、シェーダーもバージョン分岐させる •  注意点としてAutoUpgradeを無効化する。AutoUpgradeはコメントも⾒境なく更新するため、#ifで分けたはずのコードが勝⼿にアップグレードされてしまう https://unity3d.com/jp/unity/whats-new/unity-5.4.0

Slide 58

Slide 58 text

58/79 AssetBundleの互換性を保つ •  本プロジェクトではAssetBundleが意図しないシェーダーを含むケースがあり、5.1.2でビルドしたAssetBundleが5.4.5では利⽤できなくなっていた •  シェーダーに互換性がないのが原因。uniform名が変更されているため、5.1.2のシェーダーは5.4.5ではコンパイルエラーになる •  互換性がないAssetBundleは、シェーダーを分離させて互換性を持つように対応をした

Slide 59

Slide 59 text

59/79 どうやってシェーダーを⾒つけるか？ •  チェックツールを作成してシェーダーを含んでいる AssetBundleを特定 •  単体テストできる環境を⽤意し、 AssetBundleのダウンロードとロードを⾏えばシェーダーが含まれるかは確認できる •  併せてmanifestを確認すれば構成は把握できる

Slide 60

Slide 60 text

60/79 シェーダーをAssetBundleから分離する •  シェーダーをAssetBundle化すれば分離できる •  AssetBundle化したシェーダーはダウンロードしなければ影響はない •  ビルド箇所に明⽰的にシェーダーを含むようにして修正

Slide 61

Slide 61 text

⼤型アップデート成功のための考え⽅と開発の進め⽅

Slide 62

Slide 62 text

62/79 ⼤型アップデート成功のための考え⽅ •  ⼤型アップデートは機能を開発して終了ではなく、開発したものが運営に対してどういう影響を与えるか、ということまで考える必要がある •  今回の⼤型アップデートで増えたリソースの数は約7000件、増えたAssetBundleの数は約2150件あるため、運営側への影響は⾮常に⼤きい •  ほんの少しの懸念でも、運営に⼊っては取り返しのつかないことになる可能性があるので、開発の段階で全て潰す

Slide 63

Slide 63 text

63/79 懸念される問題 • AssetBundleのビルド時間の増⼤ • Unity起動時のアセットインポート時間の増⼤ • 新規リソースの追加による管理コストの増⼤

Slide 64

Slide 64 text

64/79 AssetBundleのビルド時間の増⼤ •  AssetBundle数が2000件以上増えたが、最終的にはビルド時間は⼤きな問題とならなかった •  プロジェクト側が⽤意したビルドシステムが⾮常に有⽤だった •  プロジェクトでは並列ビルドシステムを使⽤していた

Slide 65

Slide 65 text

65/79 AssetBundleの並列ビルドシステム •  異なるPC間でManifestを共有することで、ビルドを並列化できる •  ビルドはアセットとManifestの差分を⾒て発⽣する。従って、ビルド済みのManifestを共有すれば再ビルドは発⽣しない

Slide 66

Slide 66 text

66/79 AssetBundleの並列ビルドシステム •  アセットをカテゴリごとに管理し、ビルド不要なカテゴリは事前にManifestをコピーして必要なアセットのみをビルドする •  アップデートで増加したAssetBundleを新カテゴリとすることで、ビルドPCのスケールによるビルド時間の改善が可能

Slide 67

Slide 67 text

67/79 アセットインポート時間の増⼤ •  実は本プロジェクトではUnityCacheServerが導⼊されておらず、以前よりアセットのインポート時間が問題になっていた。社内的には、ほぼ全てのプロジェクトで導⼊されている •  今までプロジェクトでは以下の問題が検証できていなかったため、導⼊を⾒送っていた https://docs.unity3d.com/ja/current/Manual/CacheServer.html

Slide 68

Slide 68 text

68/79 どういうことなのか？ •  アセットインポート時にアセット操作を⾏う場合に意図しない動作となるケースがあり、それを指している？ •  アセットインポーターを変更しても、csのコンパイルが⾛るだけで、キャッシュ上のアセットは変更されない。アセットインポーターの変更が反映されていないアセットがキャッシュされているため、それが落ちてきてしまう •  マテリアル固有の問題ではなさそう。再インポートを明⽰的に⾏いキャッシュを更新することで解決が確認できた

Slide 69

Slide 69 text

69/79 UnityCacheServerの構成 •  UnityCacheServer⽤に専⽤のMacBookProを⽤意、キャッシュサイズを500GBまで保存できるように変更 •  モバイル環境では最低でもAndroidとiOSの２プラットフォームで開発が進むため、デフォルトの50GBでは全く⾜りない •  結果として、7000個のリソース追加の場合には、インポート時間が約30分から約7分に改善された！

Slide 70

Slide 70 text

70/79 リソース追加による管理コストの増⼤を避ける •  フォルダ単位で分離すると⼀覧性が失われ、差分の確認が⾏いにくくなったり、修正漏れが発⽣しやすくなる •  今回追加した全てのファイルの末尾に⼀律の単語をつけて管理

Slide 71

Slide 71 text

71/79 まとめ •  運営中のプロジェクトで⼤型のアップデートを成功させるためには、どう進めれば安定した運営を提供し続けられるのか、ということを念頭において開発を進めていく必要がある •  運営中のプロジェクトでは機能を開発して終了ではなく、開発したものが運営に対してどういう影響を与えるか、ということまで考える必要がある •  ほんの少しの懸念でも、運営に⼊っては取り返しのつかないことになる可能性があるので、開発の段階で全て潰す

Slide 72

Slide 72 text

まとめ

Slide 73

Slide 73 text

73/79 イメージエフェクトのクオリティアップ •  イメージエフェクトは⼤型アップデートに含むか採択しやすい。処理負荷にのみに着⽬することができる •  基本の頂点スペックには配慮が必要。追加するイメージエフェクトによって描画パスの数が変動するため •  全てを⾃作する必要はない。Unity機能をそのまま利⽤したり、 Unity機能をベースとすることで開発期間を短縮し、空いた時間を他の要素のクオリティアップに回す

Slide 74

Slide 74 text

74/79 キャラクターのクオリティアップ •  ライティングアルゴリズムの変更は、影響範囲について最⼤の配慮が必要。既存アセットの修正数によってはアルゴリズムの変更が困難となるため、そもそも適応できない可能性があった •  導⼊したアルゴリズムは⾮常に効果的であった。キャラクターやカメラの移動に応じた陰影の変化は視覚的に重要 •  アーティストへの配慮が必要。ワークフローが変化しDCCツール上でのプレビューの優先度が上がる

Slide 75

Slide 75 text

75/79 画⾯解像度 •  解像度変更は採択しやすい。処理負荷に影響するが、基本的にアセット修正は不要 •  パディングは統⼀ルールを設ける。マルチサンプルによるノイズは発⽣個所が予測できず、後追いの対応はコストが⾼い •  ジャギーの緩和⾃体は効果がある。パディングルールさえ統⼀されていれば作業コストなくスペックの選択肢にできる

Slide 76

Slide 76 text

76/79 ETC2 •  ETCはテクスチャ品質が低く、バンディング問題が発⽣しやすい。圧縮率での調整は⾮現実的 •  ETC2を採⽤するには動作保証する端末を適切に⾏う •  Unityにもバグは存在するが、広い⼼で受け⽌めよう

Slide 77

Slide 77 text

77/79 Unityと⼤型アップデート •  運営中のプロジェクトで⼤型のアップデートを成功させるためには、どう進めれば安定した運営を提供し続けられるのか、ということを念頭において開発を進めていく必要がある •  運営中のプロジェクトでは機能を開発して終了ではなく、開発したものが運営に対してどういう影響を与えるか、ということまで考える必要がある •  ほんの少しの懸念でも、運営に⼊っては取り返しのつかないことになる可能性があるので、開発の段階で全て潰す

Slide 78

Slide 78 text

78/79 まとめ •  ⼤型アップデートは⾮常に反響が⼤きく、やったかいがあった。運営を⾒越し⼊念な計画を⽴て、アーティストの作業コストも配慮してアップデート内容を決定したのが功を奏した •  ライティングアルゴリズムの変更は痛みを伴った。元データの構成によってはアセット修正が必要となるため、リリース前に可能な限り考慮を⾏うべき •  リリースから２年経過したが端末の性能向上がすさまじい。今後は動作スペックの選択肢をユーザーに提供することが必須になると予想する

Slide 79

Slide 79 text

79/79 講演は以上となります •  なにか質問があれば