April Update: Added numerous improvements to the Inspector view on the ABBuildConfig, exhaustive bundle logging now can be enabled or disabled, and filename-based filtering according to string "Ends-With", "Contains" or "Exact Match". So you can now organize your bundles in logical ways and not worry about including large assets that 3rd party packages generate being swept into final bundles. Fixed a bug where invalid assets (due to missing scripts) would cause null object exceptions, and also fixed an issue where the target bundle file wouldn't overwrite properly. Fixed a bug where tight iteration on assets might not detect a modified asset and would not put it in the override bundle. Finally, added support for new flags and platforms up to what is supported in 2019.3, and removed those that won't build anymore in various versions between 2017.4 and 2019.3.
November Update: Added fine-grained cyclical dependency detection to help people sort out which assets are causing problems in different bundles. This particular improvement makes it really easy to solve problems even when you have a large project and are trying to organize quickly.
August Update: Now runs in Unity 2017.4 onward.
After much experimentation and refinement, I am pleased to announce the best Unity asset for managing player and data builds, all in one package, on the Asset Store. I built it for my own projects, because Unity really does expect you to write a bunch of code before you can usefully produce multi-platform builds, especially if you want to use asset bundles.
What did I try to accomplish?
Mainly, I started with trying to get Jenkins to run a build of a single platform and produce a Player. The amount of effort required to do this well was non-trivial. Not only that, but I've seen several build systems at different companies and all of them required code changes just to change a build setting. I didn't want any of that. So, I built a system that uses a ScriptableObject to hold settings. Then I added a nicer custom Inspector to make it easier to edit. Before long, I added multiple platforms with independent settings blocks. And more became more, and so on...
And then I wanted Asset Bundles.
Also, I desperately wanted to be able to have a tight download for mobile, and let the game grab assets from the web automatically. And work for multiple platforms. And for multiple versions of built players, simultaneously. Some games are tolerant of older clients, some are not. I didn't want to require upgrading the player just because the data changed. So, I created a simple system for producing asset bundles that was easier than the mess Unity gives you. There's no tagging of assets, and no duplicating data to help resolve cyclical dependencies, and no need for an asset bundle browser... why? Because the file system should literally be your asset bundle organization. Operating Systems already have excellent tools for moving files around, just use them. In the event of a cyclical dependency, my build system tells you what the assets are that can't resolve, so you can move them someplace more central and shared. But you really don't have to worry about what order bundles are loaded in--AutoBuilder does that for you.
What's so unique?
The thing I think sets AutoBuilder apart from the pack is it comes out of the box with a workflow that encourages using asset bundles in the Editor. Normally this is prohibitive, because building bundles takes a longish time, and you don't want artists constantly waiting on that to resolve before checking their work. So instead, I built an override bundle system. This is critically amazing, because it is really fast to detect all modified assets, and sweeps them all into a special asset bundle that is built really quickly and is the first place the runtime looks for loading things. This means you can iterate quickly on textures or terrain or prefabs or whatever, and you click a button and you're ready to run with full asset bundles right in the edtior. No special loading mechanisms, and no performance hit for running in the editor. Test the actual asynchronous loading code that your built player depends on all the time instead of just when producing builds, where debugging is easy and iteration time is quick.
What else comes in the package?
I wanted there to be a simple way to launch the game that always works, always ensures that the matching set of data is loaded for the executable, and manages the cache so old data is removed when no longer needed. So there's a launch scene included that does all this for you, while showing an example progress bar that moves smoothly while downloading, displays some text progress, and just works right out of the box. All you have to do is skin the artwork and fill out the name of the next scene to load when all the bundles are downloaded, and it just lauches your scene when it's ready.
Also, there's full CDN support and flow-control support for A/B testing. The very first thing that happens when the loading scene starts up is a URL is requested that delivers a .json formatted file. This can be a simple file hosted on a web server, or it can be a .php or .js that generates a file based on whatever criteria you choose. Part of the payload that it sends down is the address of where to pull the bundles from, which is usually a CDN (like CloudFlare or Akamai), but in the event the CDN is down or changes, you just change the .json file and repoint all the existing clients someplace else. This means you can react quickly without having to rebuild your game and distribute it--which is not really possible on many platforms, anyway. Apply, Sony, Microsoft, and Nintendo all take more than a few minutes to push builds to gamers.
Sounds complicated. How hard is it to use?
To write something like AutoBuilder, yes, it is. But using it is a snap! You don't need to write any build system code at all. If you are using asset bundles already, this is just a different way to produce them, but the end result is all your bundles are initialized by the time your first scene launches. Impact to your game is negligible, but the benefits are huge.
There's a menu that gives you the three important options:
- Build All Enabled Platforms
- Build for the Editor
- Build an Update for the Editor
The top one builds every platform you want to build, which you can control (entirely through mouse clicks) in the BuildConfig settings object.
The second one builds whatever "current platform" is set to and drops the bundles in your local runtime folder, so when you hit play in the Editor, it uses those bundles. (Note, current platform is so you can test win32 vs. win64 vs. Windows Store, or Linux32 vs. Linux64, or whatever, without leaving the Editor.)
The third one builds the override bundle that figures out anything you have changed since you built the full bundle set.
It's worth pointing out that if you are working on a recent build that has already been published to the web, hitting run in the Editor will automatically pull those bundles down, so you don't have to build them yourself. Then building the override is really fast, and you skip the annoying big builds. This is a huge reason to have a build machine, because it can automatically build and publish bundles for you, and you never have to wait. Which, by the way, AutoBuilder makes really easy.
Curious? Ask questions. I'm happy to answer them. This is the best solution out there. Give it a try, and please leave a review if you like it!