Excluding addressable assets from specific platforms

How would I go about excluding assets from being included in certain platforms?

For example, I've got PS4, Xbox and Switch controller button prompts. On PC, I want to include all of these sprites, since the player can use any controller to play the game. But on Switch, I want to only include the Switch button prompt sprites and none of the other ones.

 

Currently it throw everything in StreamingAssets/com.unity.addressables/Android(for example)/ and StreamingAssets is not smart, it includes everything. I saw this feature request with 500+ votes https://feedback.unity3d.com/suggestions/platform-dependent-streamingassets-folders

 

I suppose it'd be possible to write some script that edits the content of StreamingAssets depending on your build target, and manage it manually that way? Really messy though

 

How would you like to mark each asset which platform it should go to? Asset's label matching BuildTargetGroup.ToString() ?

In that case I have some idea, either we have to make a special subclass of AddressableAssetGroup with GatherAllAssets override to check for the label (If not matching the current build settings, do not include in the gather)
Pros : integrates seamlessly with any build mode.
Cons : 1. Your special subclass is baked into a file since it is a scriptable object file, what if Unity changed the base type and removed this virtual GatherAllAssets method? 2. The right click > create group menu is hard coded to create AddressableAssetGroup and there is no way to override. You have to write a special menu to CreateAsset + other registration. (Duplicate the code in AddressableAssetSettings.CreateGroup)

Or we have to make a special build mode (Packed Platform Dependent Mode?) But the logic that leads to calling GatherAllAssets is not easily overridable by subclassing, you probably need to copy all code and change just that bit. Cons : If Unity changed packed mode script (likely) then your script is outdated. EDIT : Both BuildScriptPackedMode and BuildScriptBase are internal class, we cannot even extend them.

Or utilize group schema (Platform Dependent Schema?) and add it to any existing group to add new functionality. But currently the code that reads a schema is the build script code, then we are back to the same problem, we cannot extend them.

Or finally, easy but hacky way is to just go in BuildScriptPackedMode.cs and then at ProcessGroup method edit the List<AddressableAssetEntry> just after the gather to exclude out what you don't want. Use the GUID inside with AssetDatabase.GetLabels vs EditorUserBuildSettings.activeBuildTarget

 

Perhaps this needs emphasised with a new post but it does seem unusual that so many classes have been made internal yet the documents suggest that developers could/should be creating their own build scripts (maybe it's a general rule for package code):

https://docs.unity3d.com/Packages/c...manual/AddressableAssetsDevelopmentCycle.html
"Users can create their own build scripts and add them to the Addressable Asset settings object through its inspector."

In my case I've made a copy of the addressables code plus the 3 other packages (cacheserver, resourcemanager, and scriptablebuildpipeline) that it depends upon into my project and then slotted any custom build scripts / schemas (copy&paste with modifications) into the relevant folders so they are a part of the same assembly. I've created a platform group schema that has checkboxes for platforms and then altered the custom build scripts to query the current platform and compare with the schema before doing any work to gather locations.

Yes, this will involve a rewrite as the addressables code is evolved, and yes I think platform filtering support would be a good idea out of the box. But it works well enough for now.

 

it sounds like you all have largely landed on the solution of "use labels, and a custom build script", and the realization that "custom build scripts are somewhat of a pain right now".

Both are correct. That is the right solution, and we are aware that it's a pain right now. We have locked away a lot of things as "internal" because they will be changing. Through the end of the year we are focusing on bug fixing, but early next year, our main focus will be revamping the build script system. We want this sort of workflow to be super straightforward, and we just aren't there yet.

-Bill

 

So as far as I understand if I want to have different content for different platforms I still have to do that by myself in a "labels + custom build script" way? Or am I missing something?

 

Interested in this too. Multiplataform can be a pain (ie: change sprite atlases manually for each platform)

 

I'm also trying to achieve this and don't really know what is the best solution.
I was thinking in having different Groups for each platform and with a custom build script include them on the build or not.

 

So did anyone come up with a proven solution of this problem?

 

I would also like to know if anyone come up with a proven solution?

 

I'm also looking for this..

 

Anybody?

 

Our solution is to use custom configs to prepare all addressable groups.

It is based on using tags (our custom list of strings) and we use one global config (EditorAssetTagConfig) and many local configs (for every addressable group EditorAssetConfig, similar to SpriteAtlas).

EditorAssetTagConfig (only one in project) has:
Current Config: choose config to use in current build
Tag Groups for all configs: each group is list of tags

EditorAssetConfig (config of one addressable group) has:
Group Name: addressable group name
Group config: parameters of addressable group (compression, use crc etc)
Tags: list of tags
Asset Entries: list of assets to add to addressable group (Address: address of asset to be used in game; we use strings, Data: asset reference)


So the addressables build for any platform or other custom build (for example you can use different tags for demo) looks like:
1) Choose Current Config in EditorAssetTagConfig
2) Set addressables in project (it is looking for all EditorAssetConfig objects in project and update all addressable groups based on tags, if all tags from any tag group in EditorAssetTagConfig are in EditorAssetConfig: create addressable group based on EditorAssetConfig config).
3) Build addressables


We used this solution in our game (PS4, XboxOne, NintendoSwitch, PS5, XboxSeries) and all platforms use one Unity project (no branching).