Progress report: June '19

04/07/2019 19:05
More characters and scenes are getting their much desired updates. But we also have encountered a problem with our build.

The Angry fellow

Next stop in the long list of character animations: the angry fellow in the Tavern. This angry little man is found near a table talking to his drinking buddy, shouting curses at no one in particular. He is rather small, but all the more angry. Maybe a bit psycho even.

The ELder's Hut

The Elder's Hut got a complete makeover. We changed the scenery from a lush field to a sort of mystic pine forest, full of mushrooms and other hallucinogens. One last bit missing the smoke the fog which is still in progress. We are trying to find the best way to animate them. But I will tell you all about it when it is done. Until then, here's a picture of the Elder's new home.

Size does matter

When it comes to resources in your Unity build!

So here's what's happened. After I added the latest set of spritesheets to the project and tested it out, it all seemed fine in the editor. So I happily made a build and made it available for my teammates to check out. And then one of them said 'yeah... but this animation looks garbled...' WHAAAAAT? So I checked. And it was! It looked as if several other spritesheets were merged into one and the result was this Frankenstein's monster of various bits of spritesheets. From different characters too! So we had to do a little digging into what could have caused this.

We load and unload animations and sprite sheets dynamically from code, fully driven by our script system. In order to do that, we need to store all animation and sprite data in the Resources folder (Unity only lets assets in there to be dynamically loaded from code). Unity packs these resource assets to a single file in builds. It turns out Unity cannot handle larger than 4GB of resource data. Thorough googling and reading forums confirmed that Unity stores pack file sizes in 32bits.

We have started looking for alternative solutions and discovered Asset Bundles. Each asset can be marked as being part of an Asset Bundle and there can be any number of Asset Bundles in the project. This sounded like a simple (and the only) solution. We have split the resource folder in three asset bundles (animations, characters_1 and characters_2), added some code to load these bundles, changed the code to load from the bundles instead of using Resources.Load and built the bundles. The initial tests were promising, we got the build working, but this transition had an unfortunate side effect: loading all the asset bundles on startup takes time. Even in editor mode. It was a serious hit for iteration times, especially if we add the time needed to regenerate the Asset Bundles when something changes. So we thought, ok, why not keep using Resources in editor, and Asset Bundles in builds? Well, unfortunately there is no (easy) way to do this.

We started looking (again) for alternatives. Luckily people at Unity also realized this issue and started working on the next iteration of the Assset Bundles system: Addressables. It's still very much beta and at the moment comes as an external package, but the posts sounded promising and we had absolutely nothing to lose. We have installed the package and started (once again) changing the loader code and tagging assets as Addressables. Addressables are similar to Asset Bundles. Multiple addressable groups can be created and any asset can be drag-and-dropped to these groups. On top of that each asset can have labels which further helps loading a group of assets. And the best part is: there's no need to build the actual packs and load them in editor mode! The system has three different modes: it can work with the actual packed data, it can emulate virtual packs or can work directly with the files on disk. This means there's no performance impact during development. Startup time is immediate and there's no need to build packs. Awesomesauce. And the build works too! Unity builds multiple packs, so at the end we didn't even have to manually split our assets into multiple groups or packs. We ended up with two groups, one for the animations (because we do need all the animation files on startup), and another one for all the sprite sheet data (which is used automatically because Unity does handle dependencies between these packs and assets automatically).