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

2018/05/09 Unite Tokyo 2018

Transcript

2. 2/79 アジェンダ •  本講演では、モバイルアプリの⼤型アップデート実現に必要と なる効果的な３Dグラフィック表現の事例、アップデート成功の ための考え⽅とUnityを⽤いた開発⼿法について、弊社での適応 事例を元に解説します •  開発においては、アップデート規模と実現難易度が⽐例する傾 向があります。⼤型アップデートではユーザーの新しい体験に つながる新機能を追加したい。運営中アプリは機能追加を必要 最低限にしたい
3. 3/79 ⾃⼰紹介 •  ⾦井 ⼤ •  Cygames Research/シニアゲームエン ジニア •  ゲーム開発を軸にVR、ゲームエンジン、 グラフィックスなど、幅広い分野の研究 開発に従事。 •  本件で紹介する⼤型アップデート施策で は、3Dグラフィックス関連のマネジメン トとアーキテクト、実装を担当
4. 4/79 アジェンダ • コンテンツと⼤型アップデート施策の概要について • ⼤型アップデートで⾏われた3Dグラフィックスの クオリティアップの詳細について • 運営中コンテンツの⼤型アップデートを成功させるため の考え⽅、Unityを使った開発の進め⽅について
5. コンテンツと⼤型アップデート施策の 概要について
6. 6/79 弊社での適応事例の紹介 •  2015年にリリースのゲームコンテンツ •  Unityで60fpsを担保しつつ3Dグラフィックス表現しているのが ⼤きな特徴。キャラクター種類数は200体以上 •  2017年6⽉に⼤型アップデートを適応。運営チームとは別に アップデートチームを結成し、三か⽉で開発を⾏う 2015年 アプリのリリース 2017年 ⼤型アップデート アップデートチームにて 三か⽉間で開発
7. 7/79 Speaker Deckに資料があります •  Unite2016で講演した内容とほぼ重複する内容です •  Unity 3D 考え⽅ でググると出てきます https://speakerdeck.com/cygames/unity-sumahode3dgemukai-fa-zui-shi-hua-surutamefalsekao-efang
8. 8/79 なぜ⼤型アップデートを⾏うのか •  3Dグラフィックスの品質を底上げをする必要があった •  リリースから２年以上が経過している •  3Dグラフィックスを⽤いたアプリも増えました •  リリース前から「⾼品質版を⽤意したいね」という話はあり、 「必要になったらやりましょう」としていた •  時は来た
9. 9/79 ⼤型アップデートで⾏われた事 •  グラフィックスの⾼品質版を追加 •  2D版と3D版を含め、ゲーム中の品質設定の選択肢が６段階に ３D ⾼品質(アップデートで追加) ３D 標準 ３D 軽量 ２D ⾼品質(アップデートで追加) ２D 標準 ２D 軽量
10. 10/79 ⼤型アップデートによる品質選択の変化 •  従来は標準版が最⾼スペックであったが、アップデートにより ミドルレンジに降格 ⾼品質版 標準版 軽量版 ハイエンド端末でのみ体験できる ⾼品質な画⾯を提供 ミドルレンジ端末で⾼品質な画⾯を提供、 60fpsをキープ 幅広い動作保証のため限界まで スペックを落としつつ60fpsをキープ
11. ⼤型アップデートで⾏われた3Dグラフィッ クスのクオリティアップの詳細について
12. 12/79 3Dグラフィックスの⾼品質化で⾏ったこと •  イメージエフェクトのクオリティアップ •  プロジェクションシャドウ •  ミラー •  ライトシャフト、その他多数 •  キャラクターのクオリティアップ •  シェーダーの拡張（リム、スペキュラ、環境マップ •  キャラのスペック向上（1500tri程度） •  キャラの法線データを⼆重化 •  専⽤アセットバンドルの構築 •  画⾯解像度 •  フレームバッファの⾼解像度切り替え •  MSAAの導⼊ •  ETC2フォーマットの導⼊ •  OpenGLES 3.0への対応 •  Unityのバージョンアップ
13. イメージエフェクトのクオリティアップ
14. 14/79 イメージエフェクトのクオリティアップ •  シェーダーの対応が中⼼となるため、プログラマ⼯数が発⽣す るが、既存アセットの修正量は少ない •  種類によっては描画パスが増え頂点処理コストが上昇するが、 基本はフラグメント処理コストが上昇する 処理負荷を基準に判断できるため、採択が簡単。 運営中のアップデートに適している
15. 15/79 軽量版のパイプライン •  UnityのレンダリングはCameraを基準に制御される •  軽量版での3Dレンダリングは、全てForwardBase中で⾏われて いる 15 Camera ForwardBase
16. 16/79 標準版のパイプライン •  標準版ではBloomとDOF(被写界深度)が動作、ForwardBaseに 加えてShadowCasterによるUpdateDepthTexture処理と、 ImageEffect処理が追加される •  UpdateDepthTextureにより描画頂点数は2倍弱に増える 16 Camera UpdateDepthTexture ForwardBase ImageEffect
17. 17/79 ⾼品質版のパイプライン •  プロジェクションシャドウ、ミラー処理等でカメラが増え、対 となるForwardBaseとImageEffectが追加される Camera UpdateDepthTexture ForwardBase ImageEffect Camera (Mirror) ForwardBase ImageEffect Camera (ProjectionShadow) ForwardBase ImageEffect
18. 18/79 プロジェクションシャドウ •  Unity標準のソフトシャドウはモバイルで利⽤できないため、 ⾃前で実装する •  ライトスペースのカメラを⽤意してシャドウマップをレンダリ ング、特定のモデルに対してプロジェクションする •  描画パスが増えるので、影を落とすモデルをLayerで管理する ハードシャドウは ジャギーが⽬⽴つ ソフトシャドウにより 柔らかい光源を表現
19. 19/79 •  ミラー⽤カメラを⽤意して鏡⾯レンダリング、特定のモデルに 対してプロジェクションし、地⾯への映り込みをリアルタイム 処理する •  UnityのReplaced Shadersを利⽤して、ミラーパスでの描画に 利⽤するシェーダーの品質を制御する ミラー Tags { “Mirror"=“Chara" } Character.shader （Mirrorタグを持たない） Object.shader Tags { “Mirror"=“Chara" } Mirrored.shader Replace Camera.SetReplacementShader( Mirrored, ”Mirror” )
20. 20/79 ライトシャフト •  深度値を参照しブラーをかけ、放射状に散乱する光を再現する。 イメージエフェクトのみで完結し、光源の表現を豊かにできる •  UnityのLegacy Image EffectにあるSunShaftsをベースにし、 サンプル数やブラーのかけ⽅をカスタマイズ 深度バッファを元にブラー処理 結果をフレームバッファへ
21. 21/79 レンズフレア •  Unity標準のレンズフレアにて対応。コリジョン機能が必要とな るため⾃前で実装するのは⾮現実的 •  光源が隠れた際にフレアが正しく消えないと不⾃然に⾒える。 コライダーの設定にはアセット作成の⼯数が発⽣するため、作 業⼯数が課題となる •  キャラクターは⼈型しかないので、ひな型を作って量産化、問 題があるデータを順次修正して対応 Unity標準機能でも ⼀定品質を担保可能
22. 22/79 ティルトシフト •  画⾯の上下、左右などをボカす機能。ImageEffectのみでかなり 柔軟な表現が可能 •  DOFとは異なり深度値情報が不要なため、頂点負荷にやさしい •  Legacy Image Effectをベースにカスタマイズ
23. 23/79 まとめ •  イメージエフェクトは⼤型アップデートに含むか採択しやすい。 処理負荷にのみに着⽬することができる •  基本の頂点スペックには配慮が必要。追加するイメージエフェ クトによって描画パスの数が変動するため •  全てを⾃作する必要はない。Unity機能をそのまま利⽤したり、 Unity機能をベースとすることで開発期間を短縮し、空いた時間 を他の要素のクオリティアップに回す
24. キャラクターのクオリティアップ
25. 25/79 ライティングアルゴリズム変更の課題 •  前提として、シェーダーは全て⾃社で作成している。標準版ま では軽量化のためライティングを⾏っておらず、diffuseテクス チャに陰影を描き込んでいた •  ライティングを強化し、キャラクターの動きに応じた陰影の変 化や、スペキュラーやリム、環境マップなどの表現を⼊れたい •  しかしながら、テクスチャやシェーダーを変更せず表現をリッ チにするのは限界がある
26. 26/79 アセット修正の課題 •  本事例では、200体以上のキャラクターアセットが存在してお り、極⼒⼿を⼊れたくない。既存アセットの修正には作業コス トと管理コストが発⽣する •  シェーダー修正はプログラマーが⾏うため、適切に⾏えばア セット修正よりも格段に修正コストが低くなる 既存アセットの修正と増加量が最⼩限となるよう、 ライティングアルゴリズムを修正する必要がある
27. 27/79 ライティングアルゴリズムの変更 •  検証の結果、キャラクターに以下を導⼊する •  リム •  環境マップ •  スペキュラー •  以下は検証を⾏ったが、対応を⾒送る •  ノーマルマップ •  トゥーンレンダリング  https://docs.unity3d.com/ja/current/Manual/StandardShaderMaterialParameterSpecular.html
28. 28/79 ライティングアルゴリズムの変更 •  リム、スペキュラ、環境マップの対応は、キャラクターや カメラ移動に応じた変化により⾮常に効果が⾼い。 diffuseテクスチャに描き込んだ陰影の修正も最低限となりそう •  ノーマルマップはデータ作成にあたりUVの⼤幅な修正が必要と なり、フラグメント負荷も予想しずらいため、対応を⾒送り •  トゥーンレンダリングについてはテクスチャ陰影とのバッティ ングする要素が多く対応を⾒送り
29. 29/79 •  リム、環境マップ、スペキュラーの強度を制御するための パラメーターテクスチャを導⼊。専⽤のテクスチャを⽤意し、 RGBチャンネルで強度を制御する 制御マップの導⼊ 制御マップ R G B 特定箇所のみ環境マップを有効化するといった⽤途には 頂点単位の制御では不⼗分であり、制御マップが必須となる
30. 30/79 正しいライティングを⾏うための課題 •  正しい法線情報を保持する必要がある。 •  標準版まではライティングしておらず法線情報を持っていない。 正確には、アウトライン⽤に調整された法線を保持している •  リムや環境マップ計算には、正しい法線情報が必要となるが、 Unityのメッシュデータは２つ以上の法線情報を保持できないた め、ライティング時に問題となる アウトライン幅等の調整をメッシュの法線で ⾏っているため、正しい法線情報が⽋落している
31. 31/79 正しいライティングを⾏うための課題 •  Unityはスキニング結果が頂点シェーダーに渡ってくるため、 UV2に法線を⼊れてもスキニングされた法線を算出できない •  tangentに法線を持たせればスキニングの問題は解決するが、 法線を埋め込む⽅法が⾒当たらない。MayaからのFBX出⼒時に tangentへアクセスできない Vertex Normal Tangent UV0 頂点シェーダー スキニング される スキニング されない
32. 32/79 •  AssetImport時に処理すれば解決できる •  UV2とUV3に法線情報を⼊れたFBXを別途⽤意し、UnityのFBX インポート時にUV2とUV3をtangentへ移動させる 対になる２つのFBXを AssetImport時に処理し、 tangentに法線を⼊れる ２つの法線情報を保持させる⽅法 従来のFBX 正しいNormalを 保持したFBX スキニング処理された ２つの法線を持つ Meshとなる
33. 33/79 オーサリングの課題と解決 •  今まではMaya上の⾒た⽬がUnityと概ね⼀致していたが、 ライティングアルゴリズム変更により⼀致しなくなった。 •  リムやスペキュラ、環境マップをUnityでしか確認できないのは アーティストからすると⾮効率。200体以上のデータ確認と今後 のデータ作成を踏まえた対策が必要 •  Mayaでプレビューできるのが直観的。CGFXでも動作するよう シェーダーを組み直し、イテレーション速度と品質を担保する
34. 34/79 まとめ •  ライティングアルゴリズムの変更は、影響範囲について最⼤の 配慮が必要。既存アセットの修正数によってはアルゴリズムの 変更が困難となるため、そもそも適応できない可能性があった •  導⼊したアルゴリズムは⾮常に効果的であった。キャラクター やカメラの移動に応じた陰影の変化は視覚的に重要 •  アーティストへの配慮が必要。ワークフローが変化しDCCツー ル上でのプレビューの優先度が上がる
35. 画⾯解像度
36. 36/79 フレームバッファの⾼解像度化とMSAA •  ⾼品質版では解像度が選択可能となった。従来の標準版はジャ ギーが⽬⽴っており、特にiPhone6Plusなど横1920以上の端末 では顕著になっていた •  標準解像度ではMSAAx4を適応 •  ⾼解像度ではドットバイドットになるよう配慮。将来的な端末 の⾼解像度化を考慮して、iPad Pro想定の上限値を設定している 解像度 MSAA 標準設定 横1280で固定 MSAAx4 ⾼解像度設定 横2732が上限 無効
37. 37/79 MSAA導⼊時の注意点 •  マルチサンプルによりテクスチャのサンプリング範囲が広がり、 UVレイアウトによっては、テクスチャにノイズが表⽰される 意図しない近傍ピクセルが 表⽰されてしまう このテクスチャを 左半分だけ貼っても
38. 38/79 MSAA導⼊時の注意点 •  テクスチャを修正することで対応 •  背景はノイズが⽬⽴つ箇所のみパディングを４ドットに拡張 （従来は２ドット確保） •  キャラクターについてはUV外にピクセルを拡⼤。 3D-Coatを⽤いテクスチャのパディング幅を４に調整すること で対応
39. 39/79 まとめ •  解像度変更は採択しやすい。処理負荷に影響するが、基本的に アセット修正は不要 •  パディングは統⼀ルールを設ける。マルチサンプルによるノイ ズは発⽣個所が予測できず、後追いの対応はコストが⾼い •  ジャギーの緩和⾃体は効果がある。パディングルールさえ統⼀ されていれば作業コストなくスペックの選択肢にできる
40. ETC2フォーマットの導⼊
41. 41/79 なぜETC2フォーマットが必要なのか？ •  Androidプラットフォームにおけるテクスチャ圧縮時に発⽣する バンディング問題を解決したい •  実は「圧縮テクスチャの品質を改善したい」という声が ⼤型アップデート前より強く上がっていた •  ⾼品質版対応に伴い３Dグラフィックスの品質が向上したため、 バンディング問題を解決する必要が出てきた
42. 42/79 バンディングの例 •  繊細な表現に問題が発⽣する。キャラクターの表情など ETC ETC2 ETC ETC2 トーンカーブを調整した結果 元画像
43. 43/79 バンディングの現実的な解決⼿法 •  ETC2は圧縮時間と品質をバランスよく担保することができる •  ETCでも圧縮品質をBestにすることによりバンディングをある 程度除去できるが、圧縮時間に40秒かかり現実的ではない。対 象のテクスチャは1000枚以上存在するため、開発の速度に⼤き なインパクトを与える ETCフォーマット ETC2フォーマット 圧縮品質 Normal Best Normal Best バンディング × 〇 〇 〇 圧縮時間 約0.5秒 約40秒 約0.5秒 約70秒
44. 44/79 なぜETC2を使っていなかった？ •  OpenGLES 2.0ではETC2は拡張扱いであり、未サポート端末 ではメモリ使⽤量が６倍となり、アプリ⾃体が動作しなくなる リスクが⾼い（テクスチャがフルカラー展開されるため） •  Unityのテクスチャは１プラットフォーム中で複数フォーマット を保持することができないため、テクスチャ⾃体をETC/ETC2⽤ に複数保持しておく必要がある •  UnityにはETC2サポートを問い合わせるインターフェースが存 在するが、Unity5.1.2ではバグにより正しく判定されないため、 例外対応を⾏うことができない
45. 45/79 ETC2フォーマットを導⼊するために •  前提としてUnityのバージョンアップが必須となる •  キャラクターのみETC2を利⽤、AssetBundleを⾼品質版と標準 版とで２種類保持する •  標準版まではETCフォーマット、⾼品質版はETC2を利⽤するよ うに対応する キャラクターの品質は上がるが、 対応に必要となるコストは⼤きい
46. 46/79 まとめ •  ETCはテクスチャ品質が低く、バンディング問題が発⽣しやすい。 圧縮率での調整は⾮現実的 •  ETC2を採⽤するには動作保証する端末を適切に⾏う •  Unityにもバグは存在するが、広い⼼で受け⽌めよう
47. 運営中コンテンツの⼤型アップデートを成功 させるための考え⽅、Unityを使った開発の 進め⽅について
48. 48/79 ⾃⼰紹介 ・名前：稲⽥ 健⼈ ・職業：エンジニア ・⼤型ネイティブアプリで 新規開発からリリース、運⽤まで 全てに携わり、2D、3D関わらず ゲーム全般の開発に従事
49. 49/79 アジェンダ • Unityバージョンアップを成功させるための考え ⽅と開発の進め⽅ • アプリの⼤型アップデートを成功させるための考 え⽅と開発の進め⽅
50. Unityバージョンアップを成功させるた めの考え⽅と開発の進め⽅
51. 51/79 今回の⼤型アップデートでは •  今回の⼤型アップデートでは、Unityバージョンを5.1.2から 5.4.5へバージョンアップした •  以前よりUnityのバージョンアップが可能か検討を⾏っていたが、 バージョンアップ検証と安定運営との両⽴が難しく、先送りと なっていた •  ⼤型アップデートによるグラフィックスの品質向上に伴い、 ETC2フォーマットの採⽤が必要となったため、Unityバージョ ンを上げることになった
52. 52/79 Unityバージョンアップを⾏うための考え⽅ •  どう進めれば安定した運営を提供し続けられるのか •  運営側の負担が最⼩限になるように5.4.5への移⾏作業は全て アップデートチームが⾏った •  アップデートでは既存の機能の検証やバージョン違いによる不 具合の修正、バージョン移⾏期間中のサポートなど多くの作業 が発⽣する。作業を分担して運営チームには運営の作業に集中 してもらう
53. 53/79 今回のバージョンアップの前提 •  このプロジェクトでは、リリースしてからの２年間、Unityバー ジョンを上げたことがない •  運営に⼊ったプロジェクトでのUnityバージョンアップのポリ シーは概ね２つのケースに分かれる •  基本は安定版を利⽤、バージョンアップやパッチ適応は最低限とする •  可能な限り最新バージョンに追従する •  安定版を利⽤すると機能追加に制限が⼊り、バグ対応が困難な ケースがある。最新バージョンへの追従は、特にメジャーバー ジョンの変更時にインパクトが⼤きい •  今回のプロジェクトでは前者のケース
54. 54/79 Unityアップデートをどのように進めるか？ •  プロジェクトには多数の運営スタッフが関わっており、安易な バージョンアップは危険。同プロジェクト内で新旧のリソース が混在してしまう、などの混乱が予想される •  どのバージョンに、チーム内のどの順番であげ、どのように混 乱を避けるか、と計画性をもって取り組む必要がある •  アップデートチームがまずバージョン選定を⾏う。本来であれ ば可能な限り複数バージョンを検証したいが、社内での運⽤実 績が多く、更にある程度検証済みの5.4.5p1を候補とする
55. 55/79 ブランチ運⽤の構成図 develop develop_rich Unity5.4.5 release feature 定期的にマージ 全ての作業が 終わったらマージ アップデート 運営
56. 56/79 コーディングのポリシー •  5.1.2と5.4.5のコードを混在させ、何時でもバージョン切り替 えができるように開発を進める •  ⼤型アップデートの作業中は機能実装のテンポが速く、新旧 バージョンで動作結果を⽐較したいケースが多々ある •  ２バージョンのみであれば、#ifでの分割も現実的と判断
57. 57/79 シェーダーのAutoUpgrade対応 •  同様の理由から、シェーダーもバージョン分岐させる •  注意点としてAutoUpgradeを無効化する。AutoUpgradeはコ メントも⾒境なく更新するため、#ifで分けたはずのコードが勝 ⼿にアップグレードされてしまう https://unity3d.com/jp/unity/whats-new/unity-5.4.0
58. 58/79 AssetBundleの互換性を保つ •  本プロジェクトではAssetBundleが意図しないシェーダーを含 むケースがあり、5.1.2でビルドしたAssetBundleが5.4.5では 利⽤できなくなっていた •  シェーダーに互換性がないのが原因。uniform名が変更されてい るため、5.1.2のシェーダーは5.4.5ではコンパイルエラーにな る •  互換性がないAssetBundleは、シェーダーを分離させて互換性 を持つように対応をした
59. 59/79 どうやってシェーダーを⾒つけるか？ •  チェックツールを作成してシェーダーを含んでいる AssetBundleを特定 •  単体テストできる環境を⽤意し、 AssetBundleのダウンロード とロードを⾏えばシェーダーが含まれるかは確認できる •  併せてmanifestを確認すれば構成は把握できる
60. 60/79 シェーダーをAssetBundleから分離する •  シェーダーをAssetBundle化すれば分離できる •  AssetBundle化したシェーダーはダウンロードしなければ影響 はない •  ビルド箇所に明⽰的にシェーダーを含むようにして修正
61. ⼤型アップデート成功のための考え⽅と 開発の進め⽅
62. 62/79 ⼤型アップデート成功のための考え⽅ •  ⼤型アップデートは機能を開発して終了ではなく、開発したも のが運営に対してどういう影響を与えるか、ということまで考 える必要がある •  今回の⼤型アップデートで増えたリソースの数は約7000件、増 えたAssetBundleの数は約2150件あるため、運営側への影響は ⾮常に⼤きい •  ほんの少しの懸念でも、運営に⼊っては取り返しのつかないこ とになる可能性があるので、開発の段階で全て潰す
63. 63/79 懸念される問題 • AssetBundleのビルド時間の増⼤ • Unity起動時のアセットインポート時間の増⼤ • 新規リソースの追加による管理コストの増⼤
64. 64/79 AssetBundleのビルド時間の増⼤ •  AssetBundle数が2000件以上増えたが、最終的にはビルド時間 は⼤きな問題とならなかった •  プロジェクト側が⽤意したビルドシステムが⾮常に有⽤だった •  プロジェクトでは並列ビルドシステムを使⽤していた
65. 65/79 AssetBundleの並列ビルドシステム •  異なるPC間でManifestを共有することで、ビルドを並列化でき る •  ビルドはアセットとManifestの差分を⾒て発⽣する。従って、 ビルド済みのManifestを共有すれば再ビルドは発⽣しない
66. 66/79 AssetBundleの並列ビルドシステム •  アセットをカテゴリごとに管理し、ビルド不要なカテゴリは事 前にManifestをコピーして必要なアセットのみをビルドする •  アップデートで増加したAssetBundleを新カテゴリとすること で、ビルドPCのスケールによるビルド時間の改善が可能
67. 67/79 アセットインポート時間の増⼤ •  実は本プロジェクトではUnityCacheServerが導⼊されておらず、 以前よりアセットのインポート時間が問題になっていた。社内 的には、ほぼ全てのプロジェクトで導⼊されている •  今までプロジェクトでは以下の問題が検証できていなかったた め、導⼊を⾒送っていた https://docs.unity3d.com/ja/current/Manual/CacheServer.html
68. 68/79 どういうことなのか？ •  アセットインポート時にアセット操作を⾏う場合に意図しない 動作となるケースがあり、それを指している？ •  アセットインポーターを変更しても、csのコンパイルが⾛るだ けで、キャッシュ上のアセットは変更されない。アセットイン ポーターの変更が反映されていないアセットがキャッシュされ ているため、それが落ちてきてしまう •  マテリアル固有の問題ではなさそう。再インポートを明⽰的に ⾏いキャッシュを更新することで解決が確認できた
69. 69/79 UnityCacheServerの構成 •  UnityCacheServer⽤に専⽤のMacBookProを⽤意、キャッシュ サイズを500GBまで保存できるように変更 •  モバイル環境では最低でもAndroidとiOSの２プラットフォーム で開発が進むため、デフォルトの50GBでは全く⾜りない •  結果として、7000個のリソース追加の場合には、インポート時 間が約30分から約7分に改善された！
70. 70/79 リソース追加による管理コストの増⼤を避ける •  フォルダ単位で分離すると⼀覧性が失われ、差分の確認が⾏い にくくなったり、修正漏れが発⽣しやすくなる •  今回追加した全てのファイルの末尾に⼀律の単語をつけて管理
71. 71/79 まとめ •  運営中のプロジェクトで⼤型のアップデートを成功させるため には、どう進めれば安定した運営を提供し続けられるのか、と いうことを念頭において開発を進めていく必要がある •  運営中のプロジェクトでは機能を開発して終了ではなく、開発 したものが運営に対してどういう影響を与えるか、ということ まで考える必要がある •  ほんの少しの懸念でも、運営に⼊っては取り返しのつかないこ とになる可能性があるので、開発の段階で全て潰す
72. まとめ
73. 73/79 イメージエフェクトのクオリティアップ •  イメージエフェクトは⼤型アップデートに含むか採択しやすい。 処理負荷にのみに着⽬することができる •  基本の頂点スペックには配慮が必要。追加するイメージエフェ クトによって描画パスの数が変動するため •  全てを⾃作する必要はない。Unity機能をそのまま利⽤したり、 Unity機能をベースとすることで開発期間を短縮し、空いた時間 を他の要素のクオリティアップに回す
74. 74/79 キャラクターのクオリティアップ •  ライティングアルゴリズムの変更は、影響範囲について最⼤の 配慮が必要。既存アセットの修正数によってはアルゴリズムの 変更が困難となるため、そもそも適応できない可能性があった •  導⼊したアルゴリズムは⾮常に効果的であった。キャラクター やカメラの移動に応じた陰影の変化は視覚的に重要 •  アーティストへの配慮が必要。ワークフローが変化しDCCツー ル上でのプレビューの優先度が上がる
75. 75/79 画⾯解像度 •  解像度変更は採択しやすい。処理負荷に影響するが、基本的に アセット修正は不要 •  パディングは統⼀ルールを設ける。マルチサンプルによるノイ ズは発⽣個所が予測できず、後追いの対応はコストが⾼い •  ジャギーの緩和⾃体は効果がある。パディングルールさえ統⼀ されていれば作業コストなくスペックの選択肢にできる
76. 76/79 ETC2 •  ETCはテクスチャ品質が低く、バンディング問題が発⽣しやすい。 圧縮率での調整は⾮現実的 •  ETC2を採⽤するには動作保証する端末を適切に⾏う •  Unityにもバグは存在するが、広い⼼で受け⽌めよう
77. 77/79 Unityと⼤型アップデート •  運営中のプロジェクトで⼤型のアップデートを成功させるため には、どう進めれば安定した運営を提供し続けられるのか、と いうことを念頭において開発を進めていく必要がある •  運営中のプロジェクトでは機能を開発して終了ではなく、開発 したものが運営に対してどういう影響を与えるか、ということ まで考える必要がある •  ほんの少しの懸念でも、運営に⼊っては取り返しのつかないこ とになる可能性があるので、開発の段階で全て潰す
78. 78/79 まとめ •  ⼤型アップデートは⾮常に反響が⼤きく、やったかいがあった。 運営を⾒越し⼊念な計画を⽴て、アーティストの作業コストも 配慮してアップデート内容を決定したのが功を奏した •  ライティングアルゴリズムの変更は痛みを伴った。元データの 構成によってはアセット修正が必要となるため、リリース前に 可能な限り考慮を⾏うべき •  リリースから２年経過したが端末の性能向上がすさまじい。今 後は動作スペックの選択肢をユーザーに提供することが必須に なると予想する
79. 79/79 講演は以上となります •  なにか質問があれば