search

Unity-Technologies / Addressables-Sample

Demo project using Addressables package
1.29k stars 298 forks source link

ADDR-1930 Google PAD Integration Sample #52

Closed kirstenpilla closed 3 years ago

kirstenpilla commented 3 years ago

Shows how to load assets from the 3 different delivery types (install-time, fast-follow, on-demand). In SampleScene there are 3 buttons for each delivery type. Clicking on the button will either load or unload a prefab.

Code:

README contains new instructions for this sample project.

How SampleScene looks like if all 3 assets are loaded: image

How the custom Schema appears in the Inspector: image

"Manage Asset Packs" will open the Custom Asset Pack Settings: image

kirstenpilla commented 3 years ago

Thanks @juliusunity for the in-depth feedback!

  • The sample packs 1 bundle per asset pack, however according to Play requirements, a single app can have only 50 asset packs at most. I don't know what is the philosophy of addressables regarding the amount of bundles per app, but I assume it is not limited, which might cause problems for the users. You should consider to add the functionality of having multiple bundles placed in a single asset pack.

Yeah you are right we don't enforce a bundle limit. I saw that the Google sample project recommended assigning 1 bundle to 1 asset pack, so I decided to follow that. I suppose we can map one asset pack to multiple bundles by writing to a file, and then at runtime read from it.

ghost commented 3 years ago

Thanks @juliusunity for the in-depth feedback!

  • The sample packs 1 bundle per asset pack, however according to Play requirements, a single app can have only 50 asset packs at most. I don't know what is the philosophy of addressables regarding the amount of bundles per app, but I assume it is not limited, which might cause problems for the users. You should consider to add the functionality of having multiple bundles placed in a single asset pack.

Yeah you are right we don't enforce a bundle limit. I saw that the Google sample project recommended assigning 1 bundle to 1 asset pack, so I decided to follow that. I suppose we can map one asset pack to multiple bundles by writing to a file, and then at runtime read from it.

Yeah, I think Google went with the simplest use-case, however from what I've seen in the past, some projects have hundreds of small asset bundles, so for them having an ability to pack multiple bundles into one asset pack would be crucial.

ghost commented 3 years ago

I had some additional thought over night and I think the best (and simplest) solution for the install-time delivered content would be to simply not create any custom install-time asset packs with bundles created by addressables. Instead those bundles which a user would like to be delivered at install-time could be placed in "Assets/StreamingAssets" directly. This way your loading code will always know where to find bundles for which our AndroidAssetPacks API does not return a valid status / path. You would simply get Application.streamingAssetsPath and concatenate it with the bundle name. Passing that path to UnityWebRequest would work just fine. This solution would be perfect because:

One drawback (or rather a thing to be aware of) is that if there are many other assets in the project, streaming assets might get packed with a fast-follow delivery type, however I don't think that would be a problem for this type of use-case. So I suggest to consider simply dropping bundles into Assets/StreamingAssets directory when users choose to have them install-time delivered.

Oh one more thing. In my previous comments for the README file I wrote that "split application binary" is not necessary for this sample. If you will decide to use streaming assets for "install-time asset packs" logic, then that option will be needed (specifically when the user chooses to deliver any bundles during the install time.

kirstenpilla commented 3 years ago

One drawback (or rather a thing to be aware of) is that if there are many other assets in the project, streaming assets might get packed with a fast-follow delivery type, however I don't think that would be a problem for this type of use-case. So I suggest to consider simply dropping bundles into Assets/StreamingAssets directory when users choose to have them install-time delivered.

Sounds good. Even if users do not choose to have install-time asset packs, Addressables will still have some files (catalog.json, settings.json) placed in Assets/StreamingAssets. So for our case we can never allow the streaming assets pack to be fast-follow delivery? Or in other words if the user exceeds the 1GB core Unity asset pack size threshold, they need to make sure that their streaming assets pack is always larger than the core data pack?

ghost commented 3 years ago

Sounds good. Even if users do not choose to have install-time asset packs, Addressables will still have some files (catalog.json, settings.json) placed in Assets/StreamingAssets. So for our case we can never allow the streaming assets pack to be fast-follow delivery? Or in other words if the user exceeds the 1GB core Unity asset pack size threshold, they need to make sure that their streaming assets pack is always larger than the core data pack?

Well, I don't know if recommending users to make sure that streaming assets pack is larger than the data pack is beneficial in any way. No matter which way the streaming assets pack is delivered, the Application.streamingAssetsPath will always return the correct path which you will be able to pass to UnityWebRequest, so there is no specific need for the customers to do project adaptations to ensure streaming assets pack ends up to be larger than data asset pack. The drawback I had in mind was that in Addressables settings users would chose "install-time" delivery, however the pack could end up with a "fast-follow" delivery, therefore technically ignoring the user's setting. But in my opinion it is not bad (especially if it will be properly documented, so users would know what to expect). As for Addressables configuration files - adding json files to streaming assets is totally fine, you will just have to ensure that AndroidAssetPacks.coreUnityAssetPacksDownloaded returns true before accessing those files and you will be always fine. I think the code in this project was doing exactly that - it was checking if that API returns true and in case it wasn't doing that, your code was downloading asset packs returned by AndroidAssetPacks.GetCoreUnityAssetPackNames. This is perfectly fine and will always work.

kirstenpilla commented 3 years ago

Spoke with Andy and this PR (#946) modifies the behavior of AddressablesPlayerBuildProcessor which this sample project relies on to assign content to the streaming assets pack. I added a custom processor (PlayAssetDeliveryBuildProcessor) as a workaround, but we will need know which Addressables package version includes that PR. Will need to wait for the PR to land before this sample project can be merged in unfortunately : (

mrcarriere commented 3 years ago

@kirstenpilla Is there an ETA on this? We're investigating our options right now, but it seems like this is going to block our distribution to Android.

kirstenpilla commented 3 years ago

@kirstenpilla Is there an ETA on this? We're investigating our options right now, but it seems like this is going to block our distribution to Android.

Hi! The PR is likely to merge in around 2+ weeks since it is dependent on the aforementioned PR. In the mean time this PR is in a pretty good state as-is with some minor changes as needed. You can probably just pull down the branch and work off that.

Nevermind just got the OK to merge it in. There may be a PR within 2+ from now that includes a minor change (modifies the USE_CUSTOM_PROCESSOR package version) that accommodates the aforementioned PR.

optimisez commented 3 years ago

Hi @kirstenpilla. Any plan to integrate this Google PAD feature directly into Addressables package in future?

Nardo23 commented 3 years ago

:0