アセットバンドル機能を使用することで、例えば DLC 等の実装で必要な外部アセットの読み込みや、リソースの動的確保・解放、さらに暗号化や埋め込みによる保護など、より柔軟なアセット管理ができるようになります。
目次
- まえがき (対象読者など)
- 事前準備 (使用素材、プロジェクト環境など)
- アセットバンドルの生成方法
- アセットバンドルからのアセットの読み込み方法
- 参考:Steam で StreamingAssets を DLC 配信する方法
- おわりに
- 主な更新履歴
まえがき (対象読者など)
Unity では、原則、画像や音声ファイルなど (=アセット) を「あらかじめ」インポートしておかなければ、それらの素材を利用できるようになりません。しかし、これだと例えば DLC のように外部の画像・音声ファイルを追加で読み込む必要がある場合に困ります。
これを迂回するために用意されている機能が「アセットバンドル」(AssetBundle) で、「ストリーミングアセット」(StreamingAssets) と組み合わせて使われることが多い…ということは、アセットバンドルを利用したことのない開発者でもご存じかもしれません。
筆者もその 1 人でしたが、実際に自作ゲーム (光の絆の生徒達) で DLC を出すことにしたため、改めてアセットバンドル機能を調査し、利用することになりました。
しかし、公式ドキュメントに書かれている手順は一手間多いことに加え、(本記事執筆時点では) Google 検索上位の記事は中級者以上を想定したものが多いです。
そこで、これからアセットバンドルを使おうと考えている未経験者向けに、「すぐに動かすことのできる例」を重視した記事を執筆することにしました。
- アセットバンドルの暗号化については、話が長くなるため、別記事「Unity アセット暗号化 実例付き入門」として分けて執筆しました。
中級者以上が知りたいと思われる知識 (圧縮形式の違いや、ファイル以外からの読み込み方法など) は、Google 検索結果の上位に腐るほど有りますので、それらの記事に譲ります。
事前準備 (使用素材、プロジェクト環境など)
使用素材 (アセット)
別記事「Unity でプログラミングのみ (C# Script のみ) でゲームを作る方法」の 事前準備 - 使用素材のうち、画像系素材 (=ぴぽや倉庫様の素材のみ) を使用します。
素材の置き場所については、「次の次」で説明します。
(まずは次の「Unity プロジェクト環境」から先に準備して下さい)
Unity プロジェクト環境
別記事「Unity でプログラミングのみ (C# Script のみ) でゲームを作る方法」の C# Script の作成と Main Camera への割当まで済ませることで、本記事の C# Script を実行できる状態になります。
フォルダ・ファイルの作成および素材 (アセット) のインポート
上記「Unity プロジェクト環境」まで終わったら、Assets フォルダの直下に、以下のように 2 つのフォルダ (Editor, StreamingAssets) を作成します。
「使用素材 (アセット)」で言及した画像系素材 (2 ファイル) についても、Assets フォルダの直下に置きます。
また、たった今作成していただいた Editor フォルダの中に、さらに追加で C# Script を作成します。ファイル名は「Editor」(拡張子まで含めると Editor.cs) とします。
アセットバンドルの生成方法
公式ドキュメント記載の手順との違い
公式ドキュメントに書かれている手順を大まかに要約すると、以下のようになっています。
- アセットバンドルに含めたいアセットをマウス等で選択し、手作業でグループ化する。
- Editor フォルダ内にエディタースクリプトを作成する。
- 上記スクリプトの中に、アセットバンドル生成用の C# Scriptを書いて実行する。
しかし、実は手順 3. で作成する C# Script に、手順 1. のグループ化情報も一緒に記述可能です。つまり、公式ドキュメントの手順だとかえって面倒なのです。
手順 1. でわざわざ手作業するくらいなら、手順 3. の C# Script に一緒に書いてしまった方が楽ですし、自動化にもなります。そのためのスクリプトの例をこれから提示します。
アセットバンドルをビルドするためのエディタースクリプト (Editor.cs)
説明は後で行いますので、事前準備で作成した Editor.cs に以下のコードを丸ごと貼り付けて下さい。(下記のコード中に、既に上述の手順 1. と 3. の内容が両方記述されています)
using UnityEditor; public class Editor { [MenuItem("Assets/!!!!!!!!!! Build !!!!!!!!!!")] static void Build() { // ■ 1 ファイル 1 アセットバンドルの生成例 // (bundle11111, bundle22222) BuildPipeline.BuildAssetBundles("Assets/StreamingAssets", new AssetBundleBuild[] { new AssetBundleBuild() { assetBundleName = "bundle11111", assetNames = new[] { "Assets/pipo_battlebg001.png", }, }, new AssetBundleBuild() { assetBundleName = "bundle22222", assetNames = new[] { "Assets/pipo_sprites.png", }, }, }, BuildAssetBundleOptions.None, BuildTarget.StandaloneWindows64); // ■ 複数ファイル 1 アセットバンドルの生成例 // (bundle33333) BuildPipeline.BuildAssetBundles("Assets/StreamingAssets", new AssetBundleBuild[] { new AssetBundleBuild() { assetBundleName = "bundle33333", assetNames = new[] { "Assets/pipo_battlebg001.png", "Assets/pipo_sprites.png", }, }, }, BuildAssetBundleOptions.None, BuildTarget.StandaloneWindows64); } }
Windows 以外の PC で本コードを動かす場合の注意
実は、アセットバンドルのファイル形式はプラットフォーム依存です。
マルチプラットフォーム対応のゲームであれば、アセットバンドルのファイルをプラットフォーム別に用意する必要があります。
BuildTarget.StandaloneWindows64
Windows で Unity を使用している方であれば (現在の Windows は事実上すべて 64 bit になっているため) 上記のコードのままで問題ありませんが、Mac や Linux など Windows 以外の環境で Unity を使用している場合は、BuildTarget.StandaloneWindows64 の部分を適切と思われる値に書き換えて下さい。
エディタースクリプト (C# Script) の実行方法
通常の C# Script (NewBehaviourScript.cs など) とは異なり、エディタースクリプトは Unity Editor のメニュー上から実行するようになっています。
(Assets/Editor の中の C# Script は、すべてエディタースクリプトとして扱われます)
アセットバンドルの作成はエディタースクリプト専用機能 (=ゲーム本体には組み込めない機能) のため、通常の C# Script として実行するとエラーになります。
[MenuItem("Assets/!!!!!!!!!! Build !!!!!!!!!!")]
ソースコード中に上記の記述があることに気付いた方もいると思いますが、これが Unity Editor のメニュー上に追加する階層、メニュー名を指定するための記述です。なので、他の既存のメニューと被らなければ自由に設定して構いません。
実際に「Assets」メニューの中に同名のメニューができているはずですので、実行してみましょう。
実行後、プログレスバーなどが表示された後、StreamingAssets フォルダの中に以下のようなファイルが生成されるはずです。
ただし、実際に「アセットバンドル」として必要になるファイルは、ソースコード中でも指定している以下の 3 ファイルのみです。(例えば DLC としてユーザーに配信する際は、これらのファイルだけ配信すれば OK です)
今回の C# Script で行っているグループ化内容
今回の事例では、説明用に、あえて 2 種類の例を両方とも作成しています。
実際には、各アセットの使用目的に応じて、以下のように切り替えて運用するのがおすすめです。
- bundle11111 と bundle22222 が、1 ファイル 1 アセットバンドルの例です。例えば RPG のボスモンスター画像のように、特定の戦闘でしか使われない画像であれば、こちらのやり方にした方が、敵キャラクター毎の個別確保・解放が動的にできるので有利です。
- bundle33333 が、複数ファイル 1 アセットバンドルの例です。例えば味方キャラクター画像のように、ゲームプレイ中はほぼ常駐する画像であれば、こちらのやり方にした方がメモリーの一括管理ができる (=ゲームの起動・終了時に一括処理しやすい) ので楽です。
bundle11111、bundle22222、bundle33333 とソースコードの対応は次のとおりです。
つまり、グループ化のための情報 (どのアセットバンドルに、どのアセットを埋め込むか) を、配列変数として BuildAssetBundles() メソッドに渡せば OK です。
出力先の StreamingAssets フォルダについて
ご存じの方も多いかもしれませんが、StreamingAssets フォルダには以下のような特徴があります。
- 通常の画像・音声ファイル等を置いても、単なるファイルとしてしか認識されない。(画像、音声等の形式としては認識されない)
- Unity でゲームをビルド (例えば Windows 用に exe 形式でビルド) した場合も、オリジナルのファイルが StreamingAssets フォルダとともにそのままコピーされるだけ。
- ゲームをプレイするユーザー側で、StreamingAssets フォルダの中に自由にファイルを追加・編集してもらうことができる。
そのため、DLC のように後からファイルを追加する必要があるものや、多言語翻訳テキストのようにユーザーサイドで新言語対応してもらう場合などに、いちいちゲームをビルドしなおす必要がない (=プラグインや MOD のように自由に拡張できるようになる) という特性があります。
他にも、ゲームによってはセーブデータの保存先として利用される場合もあります。
(ただし、セーブデータのようにプログラム側で直接書き換えが必要になるものは Application.persistentDataPath の方に保存するのが推奨されています)
StreamingAssets とアセットバンドルの連携について
アセットバンドルも、DLC のような後付けプラグインを実現するために使われるので、通常はユーザーにダウンロードしてもらった DLC ファイル (実体はアセットバンドル) を、StreamingAssets フォルダの中に手動で追加してもらうか、Steam 等の配信プラットフォームの機能で StreamingAssets フォルダの中に追加ダウンロードさせる等の運用になります。
参考までに、Steam で StreamingAssets フォルダの内容を DLC として配信する方法も、本記事内で後述しています。
例:アセットバンドルのファイルを DLC として直接配信する場合
- エディタースクリプト用のプロジェクトは、ゲーム本体のプロジェクトとは別にしておき、アセットバンドルのビルド専用プロジェクト (=ユーザーには配信しない) とする。
- ゲーム本体の開発時は、StreamingAssets フォルダの中に適宜アセットバンドルのファイルを入れたり消したりすることで、DLC の有無を動作確認する。
- 本番 (配信用) のゲームを配信する際には、StreamingAssets フォルダの中身を空にしてビルドする。
アセットバンドルからのアセットの読み込み方法
ここまでの手順で、アセットバンドルの作り方や、その運用の仕方などは説明してきました。
しかし、実際にゲーム本体側でアセットバンドルの中から画像や効果音などを取り出すことができなければお話になりません。
そこで、次は、ゲーム本体に入れる C# Script の方 (本記事では NewBehaviourScript.cs の方) で、アセットバンドルから読み込む方法の例を説明していきます。
プロジェクトを分ける必要性について
先ほどの文章での説明のとおり、実運用上は、アセットバンドルのビルド用と、ゲーム本体用でプロジェクトを分けた方が安全です。
なぜなら、せっかく DLC としてアセットバンドルを別枠で配信したかったのに、バニラ (ゲーム本体) に紛れ込んでしまったという事故が起こりかねないからです。
(※ Unity に詳しくてアセットがどのように埋め込まれるかを熟知しているのなら別)
本記事では、説明用に同じプロジェクト内で「ビルド」と「読み込み」の両方を行っていますが、余裕のある方は以下のスクリプトを別プロジェクト (エディタースクリプトも、大本の画像ファイルも無い方) で動かしてみると勉強になると思います。
アセットバンドルを読み込んで使用するスクリプト
説明は後で行いますので、事前準備で作成した NewBehaviourScript.cs に以下のコードを丸ごと貼り付けて下さい。
using UnityEngine; public class NewBehaviourScript : MonoBehaviour { AssetBundle _bundle11111; AssetBundle _bundle22222; AssetBundle _bundle33333; void Start() { Camera.main.orthographicSize = 180; // ■ 1 ファイル 1 アセットバンドルの読出例 // (bundle11111, bundle22222) _bundle11111 = AssetBundle.LoadFromFile( Application.streamingAssetsPath + "/bundle11111"); Texture2D texture1 = _bundle11111.LoadAsset<Texture2D>( "Assets/pipo_battlebg001.png"); AddTextureToScene(texture1, -160, +90); _bundle22222 = AssetBundle.LoadFromFile( Application.streamingAssetsPath + "/bundle22222"); Texture2D texture2 = _bundle22222.LoadAsset<Texture2D>( "Assets/pipo_sprites.png"); AddTextureToScene(texture2, +160, +90); // ■ 複数ファイル 1 アセットバンドルの読出例 // (bundle33333) _bundle33333 = AssetBundle.LoadFromFile( Application.streamingAssetsPath + "/bundle33333"); Texture2D texture3 = _bundle33333.LoadAsset<Texture2D>( "Assets/pipo_battlebg001.png"); AddTextureToScene(texture3, -160, -90); Texture2D texture4 = _bundle33333.LoadAsset<Texture2D>( "Assets/pipo_sprites.png"); AddTextureToScene(texture4, +160, -90); } void AddTextureToScene(Texture2D texture, int x, int y) { Sprite sprite = Sprite.Create(texture, new Rect(0, 0, texture.width, texture.height), new Vector2(0.5f, 0.5f), 1); SpriteRenderer render = new GameObject().AddComponent<SpriteRenderer>(); render.sprite = sprite; render.transform.position = new Vector3(x, y); } void OnApplicationQuit() { _bundle11111.Unload(true); _bundle22222.Unload(true); _bundle33333.Unload(true); } }
実行結果の確認
上記は通常の C# Script (ゲーム本体に入れる処理であることを想定) なので、Play ボタン (再生マーク) から実行します。
以下のように、4 つのゲームオブジェクトが動的に生成され、画像が表示されれば成功です。
処理内容の説明
アセットバンドルの読み込みは、Resources.Load() などと同様に C# Script 経由で行う必要があります。
おおまかには、Resources.Load() の代わりに AssetBundle.LoadFromFile() と LoadAsset() に置き換えれば OK と理解すると良いでしょう。
LoadFromFile() と LoadAsset() の 2 つが必要な理由は、bundle33333 のように 1 つのアセットバンドルの中に複数のアセットが入っているケースもあるからです。
- (バンドルのオブジェクト名).LoadAsset() の部分が、Resources.Load() に対応していると解釈するとイメージしやすいでしょう。
ちなみに、アセットバンドルの読み込み方法は、LoadFromFile() 以外にも、LoadFromMemory()、LoadFromStream() など多岐に渡りますが、StreamingAssets フォルダから直接読み込む場合で、かつ暗号化などの特別な処理を必要としないのであれば、LoadFromFile() を使うのが最も簡単です。
- LoadFromMemory() については、別記事「Unity アセット暗号化 実例付き入門」に掲載の例で、実際に復号化時に使用していますので、興味のある方はそちらもご覧ください。
アセットバンドルの解放について
アセットバンドルは、Resources.Load() と異なり、読み込んだアセットをゲームの実行途中でも解放できる (つまりメモリを適宜節約できる) という特徴もあります。
今回の事例では、ゲームの終了時に明示的にメモリを解放するようにしていますが、メモリ消費量の大きなゲームでは、不必要になった画像などを適宜 Unload() を行うようにした方が、マシンスペックに優しいゲームになるでしょう。
void OnApplicationQuit() { _bundle11111.Unload(true); _bundle22222.Unload(true); _bundle33333.Unload(true); }
補足:Addressables とアセットバンドルの関係
Unity で、アセットバンドルの機能をベースに追加された比較的新しい仕組みに Addressables というものがあります。ある意味、アセットバンドルのラッパーです。
Addressables の利点の 1 つは、(見かけ上) アセットバンドルを作らなくても、個々のアセットを直接動的確保・解放できるようになることで、内部的にはアセットバンドルを裏で自動生成することで実現しています。
- 注意点として、昔から存在する Resources.Load() は「見かけ上」リソースを動的に読み込んでいるだけで、実際にはゲーム起動の時点で読み込まれているため、一部のケース (常駐させる必要のある画像を扱う場合など) を除いては Unity 公式も推奨していません。
なので、もしアセットバンドルの使用動機が、(DLC のような外部ファイルを読み込むことではなく) 単にアセットの動的確保・解放だけが目的あれば、Addressables の方が簡単ですし、Unity 公式も推奨しています。
今後予想される Addressables の潮流について
Addressables は Unity の中でも比較的新しい機能のため、バージョンを追うごとに機能が拡充されつつあります。
おそらく、今後は DLC のように外部ファイルを扱う必要が出てくるケースでも、Addressables を通して容易に実現できるようになっていくと筆者は予想します。
ただし、本記事執筆時点の最新 LTS 版 (Unity 2021) では、Addressables は発展途上で扱いづらい (特に細かい設定が必要なときに GUI に依存しており、筆者のようにプログラミング重視の開発者だとアセットバンドルの API を直接叩いた方が小回りが利く) という印象を受けるので、Addressable 自体が未完成と言っても過言ではないと思います。
しかし、そのうち Addressables も技術的に成熟していくでしょうし、Unity 公式もアセットバンドルを直接扱うよりも Addressables を介して扱うことを推奨する流れになりつつありますので、将来的には Addressables に移行していく流れになると筆者は感じています。
参考:Steam で StreamingAssets を DLC 配信する方法
本項は、少なくとも Steam でゲーム本体をリリースした経験のある方が対象です。
特に、Steamworks SDK の ContentBuilder をもちいて、ビルドスクリプト (*.vdf) の中身を記述し、ゲーム本体のデポをアップロードする手順を経験している前提で説明していきます。
事前準備:DLC を Steam で配信できるようにするための設定を行う
ゲーム本体に appID を割り当てる必要があるのと同様に、DLC にも appID が必要です。ゲーム本体ほどの物量はありませんが、ストアページやビルドの設定も必要です。
Steamworks 公式の DLC の説明ページに記載されているとおり、DLC を追加したいゲームの本体側で「関連する全てのパッケージ、DLC、体験版、ツール」を表示し、「新しいDLCを追加」ボタンをクリックすることで、DLC 用の appID が取得でき、DLC 用のストアページやビルドの設定が編集できる状態になります。
ストアページ、ビルド関連の設定に関しても、まずは上記リンクの公式説明を一読し、配信したい DLC に必要な設定をひととおり行いましょう。(ただし、ISteamApps::XXXXX, ISteamUtils::XXXXX 等の Steam API に関する説明は、とりあえず読み飛ばして OK)
- 上記の公式説明内にリンクが張られているビデオチュートリアル (YouTube) も、やや古い内容かつ「英語」ですが、Youtube の字幕生成、自動翻訳機能を活用すれば英語が苦手でも理解できると思いますので、視聴されることをおすすめします。
- 特に動画後半の DLC ストアページに関する説明は、公式ドキュメントの本文では説明が不足している箇所ですので、後半だけでも軽く見ておくことをおすすめします。
なお、DLC は、Steam Direct 料金の追加支払いは「不要」ですが、ストアページの審査だけは「必要」です (つまりパッケージ画像やスクリーンショット等も用意する必要があります) ので注意して下さい。幸い、ビルドの審査は不要なので、ストアページの審査さえ通過すればリリースできる状態になります。近日登場の 2 週間縛りも DLC には適用されません。
Steam API 呼び出しの必要性について
上記の公式ページの説明の中には、たびたび ISteamApps::XXXXX や ISteamUtils::XXXXX のような Steam API に関する説明も登場しますが、StreamingAssets フォルダの中身を DLC 購入者だけに公開・配信する目的であれば、Steam 側で自動的にダウンロードしてくれるので、これらの Steam API の呼び出しは不要 (つまり Steam 用に追加の C# コードを書かなくても実現可能) です。
なので、基本的には、公式ページの説明内にある API 関連の記述は読み飛ばしていただいて構いません。
しかし、最低限、できれば呼び出した方が良い「重要な API」が 1 つあります。
それは、ISteamApps::BIsDlcInstalled です。
この API は、DLC のライセンスを所持していなければ false を返してくれるので、DLC ファイル (=StreamingAssets フォルダの中身) の不正コピーを防ぐ意味でも重要です。
- 端的に言うと、この API を使用したチェックを行わなければ、DLC ファイルを他のフレンドにコピーして配布するだけで、その人も (正規に購入していないにも関わらず) Steam 上で DLC を使えるようになってしまいます。
- 加えて、Steam は DLC も含めて「返金」することが容易にできるため、DLC を返品した方のローカルドライブ上に DLC のファイルが削除されずに残ってしまった場合、引き続き DLC が使えてしまう、という問題も起こり得ます。
なので、プログラミングが苦手な方でも、最低限、この API だけは呼び出してライセンスチェック処理を入れることに挑戦していただくことをおすすめします。
- 別記事「Unity アセット暗号化 実例付き入門」に記載のとおり、DLC として配信するアセットバンドルそのものにも暗号化を施せば、さらに安全になります。
Unity から Steam API を呼び出す方法
Steam API は C++ 言語で提供されていることに対して、Unity 側の言語は C# です。
なので、例えば Steamworks.NET のようなサードパーティーの無償アセット (※ 厳密には Steam API の C# ラッパーライブラリー) を Unity のプロジェクトに導入して呼び出す必要があります。
- Steamworks 公式の API 概要説明においても、C# によるサードパーティーのソリューションの 1 つとして Steamworks.NET が紹介されています。
Unity への Steamworks.NET の導入方法は割愛いたします (※ 日本語による解説も Web 上にいくつか存在します) が、上記で説明した重要な API である ISteamApps::BIsDlcInstalled は、Steamworks.NET では SteamApps.BIsDlcInstalled(xxx) のように記述することで呼び出し可能です。(xxx には、前述の手順で取得した DLC の appID を指定)
ゲーム本体と DLC のフォルダ分け
このあたりも公式ドキュメントの DLC の説明に書かれているので、適宜目を通しながら本記事を読み進めていただきたいのですが、Steam 上の初期設定では、ゲーム「本体」側のビルド設定で DLC 用の「デポ」(Depot) を追加で作って管理する設定になっています。
- ビルド設定 (デポの設定を含む) をゲーム本体側と分離する設定もできますが、かえって同じような設定をゲーム本体側からコピーしてこなければいけなくなるので、今回のようにゲーム本体側の StreamingAssets フォルダ上に DLC ファイルを配信したいケースであれば、初期設定 (ベースゲーム上でデポを管理する設定) のまま変更しない方が無難です。
例えば、既に Steam でゲーム本体を配信したことのある方は、以下のスクリーンショットの「赤枠」側に相当するフォルダ (つまりゲーム本体の実行ファイル一式) は既に存在している状態になっており、通常は、これが 1 つの「デポ」(Depot) として Steam の「ビルド」タブ側に登録されている状態になっていると思います。
しかし、DLC は購入者だけに追加配信されるものですので、中身のフォルダ階層を統一しつつ、「本体用」と「DLC として追加するファイル」で配信するフォルダ (=Steam の「デポ」) を分けてアップロードする必要が出てきます。
- 上記の例では、ゲーム本体側のフォルダ名が content、DLC として追加で配信するフォルダ名が content_dlc となっていますが、これらは後述のビルドスクリプト (*.vdf) で変更できますので、好みに応じて変えていただいて構いません。
DLC として配信したいアセットバンドルのファイルは、StreamingAssets フォルダに入れて配信することになるため、上記スクリーンショットの「水色枠」側のように、ゲーム本体側と同一のフォルダ階層構造を掘って、DLC 関係のファイル「のみ」 (=アセットバンドル) を水色側に格納するようにします。
- 本体側の StreamingAssets フォルダ (=赤色側) は、DLC を適用しない「バニラ」状態で未使用であれば、本体側は削除してしまっても支障ありません。
ゲーム本体と DLC のデポを紐づけるビルドスクリプト (*.vdf) の例
上記のように、content フォルダと content_dlc フォルダに分けてアップロードしつつ、互いに紐づけたい場合のビルドスクリプト (*.vdf) の記述は、以下のようになります。「★」の付いている項目 (4 箇所) はアプリ毎に異なりますので、読者の方で変更してください。
- なお、本スクリプトの置き場所は、content, content_dlc フォルダが置かれている場所と同一階層となります。
- スクリプトの置き場所を変更したい場合は、ContentRoot に指定する相対パス (2 箇所) の記述も変更する必要があります。
- ビルドスクリプト (*.vdf) の文法・命令の詳細は、公式ドキュメントをご確認下さい。
"AppBuild" { "AppID" "(★ゲーム本体のappIDを指定)" "Desc" "(★ゲーム本体のタイトル名を指定)" "BuildOutput" "output\" "Preview" "0" "Depots" { "(★ゲーム本体のdepotIDを指定)" { "ContentRoot" "content\" "FileMapping" { "LocalPath" "*" "DepotPath" "." "recursive" "1" } } "(★DLCのdepotIDを指定)" { "ContentRoot" "content_dlc\" "FileMapping" { "LocalPath" "*" "DepotPath" "." "recursive" "1" } } } }
DLC ファイルのアップロード後に必要な設定
DLC ファイルのアップロード後、(DLC 購入済みの) ユーザーが自動的にダウンロードできる状態にするためには、ゲーム本体側で新規公開やバージョンアップを行ったときと同様、default ブランチに設定する必要があります。
アップロードが成功していれば、default ブランチの選択時に、本体と DLC の両方のビルド ID が含まれた項目が新たに選択できるようになっているはずですので、これを選択して default ブランチに設定しましょう。
DLC の公開前にテストを行いたい場合は…
default 以外の非公開ブランチを作ってテストする方法が公式で説明されていますので、このリンク先の説明を参照してテスト用のブランチを作って DLC の挙動をテストすることができます。
公式の DLC の説明の「テストの実施」の項にも、開発者自身に自動的に付与される DLC のライセンスを一時的に無効 (=未購入状態) にしてテストを行う方法が記載されていますので、「本当に DLC の購入者だけがダウンロードして使うことができるかどうか」をあらかじめテストしておいた方が無難でしょう。
おわりに
本記事では、アセットバンドルの具体的な使用例として、(主に DLC のように) 後付けの外部ファイルを読み込む想定の例を提示しました。
アセットバンドルを初めて使う開発者の方向けのとっかかりとしては最適な内容になったと思いますが、中上級者向けの細かい説明 (パラメーターの種類、他の読み込み方法など) は割愛していますので、より詳しい内容に関しては Web 上の他の記事に譲りたいと思います。
- アセットバンドルの暗号化については、別記事「Unity アセット暗号化 実例付き入門」で説明していますので、興味のある方はそちらもご覧ください。
本記事が、これから、DLC の実装など何らかの動機でアセットバンドルを使用したいと考えているゲーム作者の役に立っていただければ幸いです。
主な更新履歴
- 2024-05-30
- Steam で StreamingAssets を DLC 配信する方法を追記。
- 2023-04-29
- アセットバンドルの暗号化について、当該記事へのリンクも絡めて追記。
- 2023-04-25
- 初版