Question Patch sizes

Unity has an enormous patch size problem.

If you build a game in the default way - place prefabs in scenes, link prefabs from MonoBehaviours, etc. - patch sizes for a shipped Unity game are many orders of magnitude larger than the change made.

If you build our current game, then open a single scene and duplicate a single prefab, the binary diff between the two builds are over 100 megabytes.

The reason for this is the very opaque, black boxy way data is packed for Unity - a bunch of these sharedassets files are created, and those seem to contain data in a somewhat random way - so changing just a single scene can end up changing a ton of them, making the diff very large.

This gets really bad for a bunch of reasons:
- At least one of the big consoles has a default patch limit of 500mb, which you have to apply to get to bypass.
- A lot of players in third world countries and the USA has slow connections, data limits, and other problems that makes large downloads a problem.
- Mobile app stores does have (I believe) limits on download sizes as well? I don't do mobile, but I've heard this being mentioned.

The workaround that exists for this, which is the one that the above mentioned console recommends for Unity games shipped on that platform, is to use Asset Bundles. If you have your scenes and your assets in bundles, changes only change the binary data in those bundles. Yay!

The only problem is that Asset Bundles (and Addressables) are designed to solve a very different set of problems - adding new data to your already shipped game, putting parts of the game up for download later, selling f2p skins, etc etc etc.

Using them when what you want to do is to just drag prefabs into a scene and then ship is very painful. It adds a ton of complexity for the level designers and pain for the programmers in order to solve the wrong problem.


Has there been any thought put into solving this? This is one of the largest pain points we have with Unity on the engineering side - if we want to use Unity in the way that's good and comfortable (no asset bundles), we have to take on the risk that we just don't get to ship patches on a platform. That's bad!

If the process of how Unity packs assets had been made into less of a black box, I could perhaps suggest some improvements, but right now all I know is that a change of ~25 lines in a unity scene file causes 100 megs of patch. A real patch with actual changes becomes a significant part of the entire download size of the game very fast.

Any help or insight?

 

This is a big problem for us and have been building everything to avoid it. Our current solution is to cut everything into small assetbundles: scenes, enemies, sprite atlases. When building our patches we even ignore changes to assetbundles that we know are not critical.

Seeing big AAA games like Call of Duty, Forza Horizon and Gears have issues with patch sizes (sometimes 100GB!), I don't think this is something that can be solved easily.

 

Also, in two console platforms the patches are always relative to the original game release, so if you don't get your asset packaging strategy 100% right from the start your patches will be forever huge.

It feels like the layout of the resource/shared assets files has been untouched since the early days of Unity. Recently Unity did add some extra alignment options to asset bundles that help with patching, but nothing for build scenes/resources.

There's also the fact that managing bundles adds a major development overhead. Yes, addressable assets simplify a lot of it, but managing addressable groups is still a major pain: pack assets into too few bundles and patch sizes suffer, pack them into too many bundles and load times go through the roof (because bundle loading is async but not actually parallel: bundles are loaded one at a time).

 

Being able to define an alignment value for for binary offset of data in scene/resources data would help a lot, since patching systems often work at a set "block" size and can identify moved blocks, reducing ripple effects of assets ordering or size changes at the cost of larger build sizes.

I feel the tooling offered by addressables lacking in many areas:

- There are no per-platform overrides (a feature the defunct Asset Graph package did very well).

- It's hard to visualize bundle dependencies in order to make grouping choices other than "dump all duplicated assets into a single large group".

- Not being able to unload individual assets (a fundamental limitation of asset bundles) creates a massive headache for games with seamless streaming (no loading screen to hide the long UnloadUnusedAssets pause).

Since assets will only unload when all references to the bundle they came from are released, it's very easy to get into a situation where many unreferenced assets stay in memory indefinitely unless you resort to "pack separately", which increased load times on last gen consoles by more than one order of magnitude last time I tried it.

We do a lot of porting and something we almost always have to do is take games that were made.for PC and didn't use bundles and refactor them to use addressables to conform with that one console platform. Loading times always become worse afterwards, without fail, and most time is spent trying to make it bearable.

 

Addressables are still horrible, and not the correct fit for the job.

I really don't like how they're essentially taking everything that is Unity - referencing stuff from stuff - and saying "no this is bad, do it differently! You shouldn't get to see your game in the scene view!"

As long as I cannot have a texture visible in the scene without having control over where that texture is stored relative to the scene, it's not a solution! Working on addressables is barking up the wrong tree.