@Reichert
Yes, I tried and it works, but not in the way I would like it to have. I thought about writing about it several times now, but I wanted to talk first to one of the Assetbundle System engineers if my implementation of our system is using the AB system wrong or if we missed something.
tl:dr
I assume the AB system suggests to have a “preloading mechanism” which loads and verifies all assetbundles, before the actual game starts, rather than check on the fly if an assetbundle is up2date or not (which is what we are doing at the moment).
long story:
We use the assetbundles to load battleground (base) and assets (custom additions) when the player is entering a mission, as well as for static assets (UI atlasses, music,…). While the former is only loaded when used, the later is loaded when the player starts the game.
Now the biggest problem we face is, that the player has to get from somewhere outside that an assetbundle has been updated. We use a small textfile (well, kind of small, but still 300 kb for us) which contains all data we need to tell the client that the assetbundle is updated: CRC, hash value and a size for our loading screen display. The progress of downloading and updating looks like:
- player starts game, downloads “assetbundle_version.cfg”.
- game parses config and knows now the latest and correct CRCs, hash values and sizes for the assetbundles.
- game gets on the preloading screen, checks and downloads static assetbundles (UI atlas, music,…) if needed.
- player can login into game and decides what he would like to do.
- player wants to play a mission, enters the mission and comes to a loading screen.
- game checks which assetbundles are actual needed for that mission and tries to download the assetbundles (battleground, models, textures, materials,…) if needed (client knows the CRCs and hashvalues from the start of the game).
Now in the last step, we face our problem: if we update our assetbundles on our ftp while the player is playing, he could potentially download assetbundles with a different CRC than the client expects: the client downloaded the configuration file only at start of the game and we updated the assetbundles after that.
Now to fix that, we could download the configration file each time we want to check if we need to download assetbundles, but that would mean to download 300 kb each time the player wants to enter a mission (which happens quite often and is not suitable for a mobile game). Maybe we can change our WWW.LoadFromCacheOrDownload to not check the CRC and hashvalues later, after the game started.
In my conclusion, the current main problem in the assetbundle system is, that the hashvalues and CRCs are given in from outside. In a perfect world, we would simply tell the game to download an assetbundle from our ftp and it checks from a small download header if that is already the data the game knows and if it is not corrupted. No passing in an external configuration file.
Well, now I wrote the story before talking to the pros, but I’ll post a follow up to this 
Patrick