2018.10.24追記
この記事は当時AssetBundleやりたくなさすぎて割と雰囲気で書いたものなので、AssetBundleに困っている方たちはこちらの記事を読むことをオススメします。
この記事を書いた当初は自分もAddressable Asset Systemに期待していましたが、現状先行きがいまいち見えないので、もうしばらくはこの状況が続きそうな予感です。
はじめに
「Unity2018.2からAddressable Assets Systemが来るけど、俺達は一体これからどうすればいいんだ…？」
という事で、今回はAddressable Assets Systemの登場を踏まえた、今後のAssetBundle問題への対処法について考察してみたいと思います。
あくまで個人の見解であり、自身がUnityの中の人という訳でもなく、Addressable Assets Systemの開発状況や今後の展望について実際の所は何も知らないため、その辺はご了承頂けると…！
関連記事
Addressable Assets Systemについては、別記事にて詳細に解説しています。
Addressable Assets Systemの今後
Addressable Assets Systemは現在preview段階で、正式リリースは恐らく2018.2の正式リリース（今年夏予定）と同時期になるかと思います。
無論、正式リリースされたからと言ってすぐに100%安心安全に快適に使えるなんて事は世の中には無いので、採用事例なども出て熟れてくるまでさらに半年〜1年ほどは掛かると予想しています。
AssetBundleManagerは非推奨となる
フォーラムにこんなスレッドがありました。
AssetBundle Manager deprecated? - Unity Forum
Yes, this package is deprecated. The code is still available as reference on BitBucket, if you wish to use it as a template for your own system. https://bitbucket.org/Unity-Technologies/assetbundledemo
2018.2 will introduce the Addressables system, which supersedes the Asset Bundle Demo project. It has a similar "virtual" mode for loading bundled assets in the Editor, but in a much more elegant and robust way.
- AssetBundleManagerは非推奨になった
- BitBucketにあるから使いたいなら参考にしても構わない
- 2018.2からはAddressables systemに取って代わる
という事です。また、BitBucketの方を見ると、READMEにこのような追記がありました。
NOTE: This project is no longer actively maintained by Unity.
You are free to use the code as-is or modify as needed in accordance with the provided license
for your own purposes, but there is no guarantee of performance or functionality, and no support will be provided.
まあ要は自己責任で使ってね、という事ですね。
どうすればいいか
既に運用中のプロジェクトについて
既に運用中のプロジェクトについては、Addressable Assets Systemに無理して移行する必要性は無いと思います。
AssetBundleそのものが変わった訳ではないので、オレオレAssetBundleManager的な物を既に実装していても、今までの仕組みはこれまで通り使えるはずです。
とは言え、今後数年運用し続けるのであれば、いつかは移行したほうが良いタイミングが来ると思われます。
移行するとすれば、既存のシステムのロード処理部分だけをResourceManagerに置き換える形が良いと思います。文字列をResouceLocationに変換してResourceManagerに渡す機構を実装すれば置き換え可能です。
開発中のプロジェクトについて
開発中のプロジェクトにおいてはなかなか判断が難しい所です。幾つかのパターンに分けて考えてみます。
Unity2017で行くプロジェクトについて
まず前提として、Unity2018.2以前を採用する予定のプロジェクトであれば、そもそもAddressablesが使えるのが2018.2以降なので、今まで通り行くしかありませんね！
実際大規模な所ではまだまだ2017どころか5.x系が現役なんて所も多いと思うので、全然有り得るパターンだと思います。（私も今まさにiPhoneX対応に向けて5.3→2017への地獄のアップデート作業が降ってきて辛い）
Unity2018で行くプロジェクトについて
まだまだ開発中でリリースが1年後とかのプロジェクトの場合、Unity2018を採択するパターンもあるかと思います。
この場合は非常に悩みどころで、明確な答えは存在しませんが、大きく分けて以下の対処法になるでしょう。
これまで通り行く
これまでの仕組みが使えなくなる訳ではないので、既に自社で抱えているオレオレAssetBundleManager的な物があれば、それを使いまわすのは割と有り得る選択肢だと思います。
Addressable Assets SystemとオレオレAssetBundleManagerを比べてみて、移行するメリットが大きくなければ、やはり無理して移行する必要性は高くは無いと思います。
なによりもまだpreview版の段階なので、現時点では正直まだ使いづらい所やバグも多く、実用できるかというと微妙な所です。
少なくとも正式リリースとなるまではこれまで通りやって、様子を見て移行作業を行うのが最適解なのではないかなと思います。
俺はAddressable Assets Systemで行く
「それでも俺はAddressable Assets Systemで行きたい…というか社内の共有資産にもAssetBundleManagerは無いし、これから作るって時にせっかくUnity公式が対応してくれるんだからこれに乗っかりたい…というかぶっちゃけ実装面倒だしやりたくない」という人、結構居るんじゃないでしょうか。まあ私の事なんですが…
実際、今からオレオレAssetBundleManager作るのはかなりの確率で将来的に負債になると思うので、個人的にはナシだなと思っています。どうしてもやらなきゃならない状況なら、頑張って会社・上司を説得しましょう。既成の物を使うにしても、Addressable Assets Systemが来てしまうと今後メンテナンスされる未来は見えないので、長い目で見るとUnity公式でメンテされるシステムに乗っかるほうが絶対に良いです。（いやまあUNETとかいう悲しい事例もあるのですが…）
作りきりのアプリなら別にいいと思いますが、今後もAssetBundle更新して運用していくのなら、公式に乗っかるのが良いと思います。標準こそが正義。
が、やはり現状でAddressable Assets Systemに全部賭けるのもまあまあ博打感はあります。パフォーマンス検証でも触れましたが、実際運用に入ってみて見つかる問題はあるでしょうし、まだpreview版で運用面でのワークフロー周りは未実装っぽい所が多く、未だ不透明な部分があります。今後も積極的に情報を追い続ける必要があるでしょう。
個人的には、AddressablesのバックエンドとなるResourceManagerの仕組み自体はコケることは無いと思っています。ResourceManager本体には具体的な実装はほとんど含まれておらず、DIでかなりカスタマイズできる仕組みになっていて、「オレオレAssetBundleManager作るなら大体こういう設計になるよね」というのが上手く抽象化されているフレームワーク的な感じになっています。
なので、Addressablesの状況を追いつつ、ResourceManagerの上に独自のアドレス解決システム（オレオレAddressables？）を作るのは結構アリなんじゃないかと思っています。ResourceManagerに乗せておけば後からAddressablesに移行するのもそんなに苦労はしなさそうですし。
まとめ
- まだしばらくはこれまで通り行くのが良さそう
- 様子見て移行するのが賢い
- 過渡期特有の痛みはまだまだ発生しそう
- ResourceManagerの上に独自システム乗せるのはアリだと思う
ということで、もうとにかく正式リリースが待ち遠しい！という気持ちしかないのですが、それはそれとして仕事というのは無情にも降ってくるので、冷静にどうするかというのは各自判断するしか無いのでしょう。
過渡期特有の痛みはどうしても発生すると思うので、そこはこうやって積極的にアウトプットしつつ痛みを分かち合いたいですね…！