大規模ゲームのアートアセットプロジェクトの管理方法

今回の主な話題：大規模ゲームのアートアセットプロジェクトの管理方法、GooglePlayがAppを強制的に64ビットにする問題、散在するAssetBundleアセットの再パッケージ化に関する質問、UnityのApi Compatibility Level .net 4.xと.NETStandard2.0の違い、SRP BatcherがUnity2020バージョンOpenGLES3で失効する質問。

Asset

Q：プロジェクトの制作人数の増加により、様々なアートアセットの数も急増しています。さまざまな仕様やさまざまなアセットのインポートおよび検査ツールがあっても、一定期間実行した後も、プロジェクト内さまざまな破棄されたアセットがクレアされていない状況があって、アセットとパッケージのサイズの増加し続きを引き起こします。

例えば、

1、各種類のアセットが作成中に生成するいくつの中間ファイル；

2、元々使用されていたが、後でビジネス要件が変更されたために放棄されたアセット；

3、元々効果を見るためにゲームに入れるつもりでしたが、実際に実装されていないアセット。

皆さんがこの種の問題を対処する時の解決方法を知りたいです。

A1：問題主が提出して質問は、テクノロジーと関係なし、プロセスとは関係があります。

（1）監督作業の責任は、具体的に誰かが取るまで明確します。この世の中には、事前準備があれば万事が易くなりますが、なければ無駄になりやすいです。

すべてのプロジェクトには、パフォーマンス、アセットなどの問題を管理するために1人のPerformance Ownerが必要です。この人がいなければ、ツールと開発チームがどれほど強力であっても、何の意味もありません。この人は、プロジェクトのプロデューサーさん、メインプログラマーさん、QA LeaderまたはPM（一般的な小規模チームではこの役職はないかもしれません）が担当することができます。UWAが合作したチームの経験から見ると、QA LeaderがPerformance Ownerを担当するチームが多いです。

（2）監督プロセスは同期する必要がある

チームの中の誰かがアセット問題とパフォーマンス問題に責任を取る必要があり、そしてチームに「継続的な監視」と「継続的な改善」の習慣を身に付けるように強制するための固定プロセスを確立する必要があります。三日坊主の形で物事を成し遂げるのは難しいです。ゲーム開発にも同じです。ですから、監視することをチーム開発中の習慣になさせたいと、プロセスでコントロールし続き必要があります。プロセスが完備になれると、すべては順調になります。

上記の2点が達成されれば、問題主の質問は自然に解決されます。

A2: 監督責任者は通常PMです。なぜなら、一部のQAには常識や権利がないためです。PMがビジネスを理解するのが最善です。PMがない場合は、クライアントにメインプログラマーにこの権利を与えるのが最善です。バージョンロックは非常に必要であり、ほとんどの大手会社はこうやっています。

ツールを使用してアートデザイナーの操作を制限し、すべての誤りをエラーとして報告してから、明確にプロンプトをします。バージョンロックを使用してコミットノードを制限します。そして、規則を従わない人に立ち去ることを要求します。なぜエラーが報告されていることを問うことも許しません。もちろん、これはプロデューサーさんからサポートする必要があります。簡単に言えば、アートデザイナーもプランナーさんも、誰かがツールの使い方を知らず、学ぶことを望まず、協力する価値がありません。

Build

Q：Unityはアセンブリを介して対応するコードをロードでき、Google Playは64ビットAPPを強制しましたが、Assembly.Loadを介したコードのロードをサポートしなくなりましたか？

A：下図のように、UnityのMonoバージュンはまだARM64をサポートしていないため、Google Play（64ビット要件）にリリースできるためにIL2CPPを採用しなければなれません。IL2CPPはAssembly.Loadをサポートしていません。

こちらを参照することができます。

AssetBundle

Q：UnityのAssetBundleアセットが散在するAssetBundleアセットをZip（例えば、1つづつを300MBにする）にする必要がありますか？AssetBundleをパッケージする時に、圧縮形式を選択できるから、総サイズを減らすためではありません。AssetBundleが散在する場合、ダウンロードする時にパフォーマンスへの圧力はありませんか？皆さんは活用中にどのように対処しますか？（AssetBundleの数は10万以上で、総サイズは約4Gです。）

A1：大量の散在するファイルのダウンロードは、当然、1つの大きなファイルほど高速ではありません。Http接続にも時間とアセットが必要です。AssetBundleが実際には数KBしかない場合もあり、割に合わないです。Zipにして計算することはもっと便利で、圧縮せずにZipにすることを考慮できます。もちろん、フォーマットをカスタマイズして行うこともできますが、大きなファイルに合併すると更新するのは面倒になり、ある程度の管理と取り換えが必要です。

A2: つい最近、この機能を実現しました。複数のパッケージをZipにすることは、確かにダウンロード効率に役に立ちます（特に海外ネットワーク環境の場合）。

1、AssetBundleパッケージ化はまだ断片化のAssetBundleパッケージです。（AssetBundleは特殊効果やUIなどのモジュール区別を行います。）

2、ホットアップデートが必要な場合は、生成されたAssetBundleパッケージ情報を以前バージョンのAssetBundleパッケージと比較し、各モジュールの変更AssetBundleパッケージをZipパッケージにします。

3、ホットアップデート中に、更新の必要なAssetBundle情報（Zipマークがあり、アセットがZipパッケージに含まれていることを示します）を収集してダウンロードします。Zipマークのない場合、AssetBundleパッケージを直接ダウンロードします。これにより、複数のバージョンを超えるホットアップデート機能もサポートできます。

4、ダウンロードしたZipパッケージは、クライアント側でAssetBundleに解凍されます。

A3：1つの答えを追加します。

ハッシュの欠点はより集中しています。ダウンロードが遅く（cdnを使用すると、ossバックエンドのパフォーマンスを考慮する必要がありません）、ossへのアップロードもはるかに遅いです。

Zipの場合、パッケージ管理もダウンロードの冗長性も面倒なことであり、動的ダウンロードはさらに不可能です。ですから、ハッシュよりも高いossコストが発生する可能性があります。

A4: 初期開発に分散ファイルを使用し、ファイルが小さいならネットワークの送信再開問題も回避できます。後の期間で時間が余裕であれば、大きなパッケージに拡大する方式になさせます。バージョン番号に応じて増分更新パッケージを生成することもできます。

サーバーに置いても影響はあまりなく、定期的に清掃すれば大丈夫です。

A5: 前のプロジェクトでZipパッケージを採用しましたが、長時間運営すれば、冗長なアセットがますます増えていきます。ホットアップデートのアセットは完全性を保証するために、パッケージを変更しない限り削除することはできません。パッケージが頻繁に変更されている場合、Zip方式が最適です。

Editor

Q：UnityのApi Compatibility Level .net 4.xと.NETStandard2.0の違いは何ですか？

A：NET Standard 2.0は、プラットフォームのサポートが広く、互換性がより高いです。.NET Standard 2.0のAPIは.NET 4.xのサブセットであります。つまり、.NET 4.xがサポートしているAPIのほうがより多く、.NET Standard 2.0と互換性がありますが、一部のAPIは一部のプラットフォームで互換性がありません。

Unityはデフォルトで.NETStandard 2.0を選択します。クロスプラットフォームの互換性が欲しい場合には、Standard2.0を選択する必要があります。使用している外部ライブラリまたはスクリプトでコールされるAPIはStandard 2.0にサポートされていない場合、4.xに変更して試すことができます。

公式ドキュメントを参照してください。

https://docs.unity3d.com/Manual/dotnetProfileSupport.html