アセットワークフロー
アセットとは、ゲームやアプリケーションを作成するために、Unity プロジェクトで使用するアイテムのことです。アセットは、3D モデル、テクスチャ、スプライト、サウンドエフェクト、音楽など、プロジェクトの視覚的または聴覚的要素を表します。アセットはまた、カラーグラデーション、アニメーションマスク、任意のテキストや数値データなど、より抽象的なアイテムも表します。
アセットは、3D モデル、オーディオファイル、画像など、Unity の外部で作成されたファイルから取得される場合もあります。Unity で ProBuilder メッシュ、アニメーターコントローラー、オーディオミキサー、レンダーテクスチャなどのアセットタイプを作成できます。
インポート、作成、ビルド、配信、ロード
上の図は、Unity でアセットを扱う際の典型的なワークフローを示しています。各コラムは以下の説明のように独立したステップを表しています。
- アセットを Unity エディターに インポート します。
- Unity エディターとそのアセットを使って、コンテンツを 作成 します。
- アプリケーションやゲームファイル、そして任意でその付属のコンテンツバンドルを ビルド します。
- ビルドしたファイルを 配布 し、ユーザーがパブリッシャーやアプリストア経由でアクセスできるようにします。
- ユーザーの動作や、コンテンツのグループ化とバンドルの方法によって、必要に応じてランタイムにさらに更新を ロード します。
インポート
インポートとは、ソースファイルを Unity エディターで作業できるようにする処理です。ファイルをプロジェクトの Assets フォルダーに保存またはコピーすると、Unity はそのファイルをインポートし、エディターで作業できるようになります。
アセットを Unity にインポートする際には、ファイルがプロジェクトのどこに保存されているか、アセットの種類ごとに Import Settings を調整する方法、メタファイルは何のためにあるか、アセットデータベースがインポートされたデータをどのように保存するかなど、基本的な知識を身につけておくことが重要です。これらのトピックの詳細については、アセットのインポート を参照してください。
Unity Accelerator を使用することで、チームでの作業時に Unity のアセット処理を高速化することができます。
作成
アセットをプロジェクトにインポートしたら、ゲームやアプリケーションの作成を開始できます。一般的には、アセットをゲームオブジェクトとして シーン に配置し、ユーザーとそれらの相互作用を制御する スクリプト を追加します。
プロジェクトの開発規模が大きくなると、アセットをグループに分ける必要が出てきます。これにより、ランタイムに選択した追加コンテンツを段階的にダウンロードできます。
作成段階で、アセットを別々の バンドル にグループ化する方法についての戦略を決定し、それらをロードするタイミングを選択するコードを実装することができます。
アセットをバンドルにグループ化することで、最初のダウンロードのサイズを小さくし、一部のアセットを後でランタイムにロードできます。これにより、ゲームやアプリケーションのダウンロードサイズとメモリ使用量を最適化することができます。Unity の Addressables システムを使用することを推奨します。
ビルド
ビルドとは、完成したプロジェクトをバイナリファイルにエクスポートし、それを配布して好きなプラットフォームで実行できるようにする処理のことです。例えば、Windows 用にビルドする場合、Unity は .EXE ファイルとそれに付随するいくつかのデータファイルを生成し、それらを配布します。
Addressable やアセットバンドルを使ってアセットを別のダウンロード可能なバンドルにまとめている場合は、配信のためにそれらのバンドルファイルもビルドする必要があります。
自身のコンピューターでプロジェクトをビルドすることが可能です。または、Unity の Cloud Build サービス を利用して、Unity プロジェクト用の自動ビルド生成と継続的インテグレーションを利用できます。
配信
ゲームやアプリケーションとそのコンテンツバンドルをビルドしたら、ユーザーがそれにアクセスする方法が必要です。配信方法の選択は、ターゲットとするプラットフォームによって異なります。
例えば、モバイルプラットフォームには独自のアプリストアがあります。専門のパブリッシャーを利用することもできますし、自分のサーバーでホスティングすることもできます。
Unity は、独自の Cloud Content Delivery サービスを提供しており、ゲームやアプリケーションとそのコンテンツをホストしてユーザーに配信することができ、Unity の開発プラットフォームに完全に統合されています。これにより、時間を大幅に節約することができ、コンテンツが豊富なライブゲームや、定期的にコンテンツの更新が必要なアプリケーションに大いに活用できます。
ロード
ユーザーがゲームやアプリケーションをロードして使用する際に、ロード処理とその体験は、設定したルールやプログラミング、およびアセットのグループ化やバンドルの方法によって決まります。
ここで説明した技術やサービスを組み合わせれば、最初のダウンロードを迅速に行い、プロジェクトの存続期間を通して、継続的なアップデートや追加コンテンツを提供できます。
アーティストワークフローの利点
Unity のアセットワークフローには、Unity エディターで直接編集やデザインを簡単に行うことができるツールや機能があります。
- さまざまな ファイル形式 に対応しています。
- Unity とサードパーティツールの間で すばやく往復 します。
- プリセット を使って、アセットの種類に応じてカスタムのデフォルト設定を適用できます。
- Addressable と Cloud Content Delivery を使用してライブコンテンツをシームレスに更新します。
プログラマーワークフローの利点
- カスタマイズされたコンテンツパイプラインが可能です。例えば、Unity がアセットをインポートする際に処理するスクリプトを書いたり、独自のルールに基づいて Unity が自動的に適用するプリセットを制御したりすることができます。
- スクリプティングによる ソースアセットの修正 が可能です。マテリアル、メッシュ、物理などのソースアセットをゲームコードで調整することができます。
- Addressable アセットシステム を使用してメモリを節約します。このシステムは、複雑なプロジェクトのコンテンツ管理を簡素化し、自動メモリ管理とプロファイリングツールを提供します。
- アセットをターゲットプラットフォームに合わせて最適化します。マルチプラットフォームのプロジェクトでは、何百種類ものテクスチャがあり、それぞれのプラットフォームに合わせて異なる解像度でパッケージ化する必要があります。Unityでは、各ターゲットプラットフォーム用にビルドする際に、アセットのパッケージ化、サイズ変更、再圧縮を自動的に行います。
ワークフローに関するヒント
Unity でアセットを使うには、さまざまな方法があります。どの方法がプロジェクトに適しているかは、チームの規模、プロジェクトの規模、ターゲットとするプラットフォーム、それらのプラットフォームでのメモリの使用状況、パブリッシュ後にアップデートやパッチ、DLC をリリースしたいかどうかなどの要因によって異なります。
例えば、チームで作業をする場合、キャッシュサーバー をバージョンコントロールシステムと一緒に使用して、Unity のインポート結果をキャッシュすることで、チーム全体の作業時間を短縮することができます。
別々のバンドルとして公開したい膨大な数のアセットを使っている場合、それらのアセットグループを別のプロジェクトに分けると便利です。そのようにすると、チームのメンバーがそれらのバンドルを使うときに、1 つの巨大なプロジェクトをロードする必要がなくなります。
プラットフォームに関するヒント
すべてのアセットを 1 つのプロジェクトにまとめておくと、ビルドを実行すると、アセットは現在選択されているプラットフォームに適した形式で、自動的にビルドされます。しかし、アセットを複数のプロジェクトに分割して、バンドルを別々にビルドする場合は、サポートするプラットフォームごとにビルドを作成する必要があります。詳しくは、Addressables ドキュメント Building Addressable assets を参照してください。
また、プラットフォームの特性によって、ランタイムアセットの整理方法の制限や可能性が決まります。例えば、スタンドアロン型のプラットフォーム (PC や macOS) では、仮想メモリによってほとんど制限のないメモリプールが提供されます。そのため、Resources フォルダー や大きなアセットバンドルを使用しても、通常はメモリの問題は発生しません。逆に、モバイルデバイスやコンソールプラットフォームでは、通常、仮想メモリは限られているか、存在しません。そのため、これらのプラットフォーム向けに作られたアプリケーションは、アセットのロードおよびアンロードをより効率的に管理する必要があります。
また、プラットフォームにおけるユーザーの期待値も重要な要素です。例えば、モバイルプラットフォームでは、最初のダウンロードとインストールのプロセスが長いと、プレイヤーがアプリケーションをプレイする前に放棄してしまう可能性があります。このような理由から、モバイルアプリケーションでは、最初のビルドでは最小限のアセットしか含まれておらず、ユーザーが初めてアプリケーションを実行したときに、残りのアセットをリモートサーバーからダウンロードするのが一般的です。