Controlling content updates at runtime?

I have been integrating Addressables into a large project and have a business need to create content updates, make them available, but control which clients pull them. There doesn't appear to be a clean way to do this. Here is a content update flow, using remote source for bundles/catalogs:

1. Have an AA group and have it marked Static Content
2. Make a change to assets within that group
3. Run Prepare Content Update, select appropriate state file, accept the summary for content update
4. Run Build Content Update
5. Move catalog and new bundles to remote location (lets say s3 in this case)

At this point, all clients in the wild will - on initialization - compare catalog hashes, detect that it's changed, download new catalog and subsequently the content update, replacing the old content (I believe).

Is there any way to cleanly implement some kind of runtime code that allows for business logic to decide if it should pull down this new catalog? I suspect this would be a popular feature for many other game devs, allowing content updates to be tested in production by specific clients before being widely distributed, as well, as A/B testing etc...

 

Yes there is In the AdressableAssetSettings there is Player Version Override. Basically every client could have a different number, and when you want to build an update for a client, you change that number to his and vice versa. The client only looks for his player version ^^

 

I'll check that out, thanks. My gut says this will not solve my usecase. This will make it so a particular client fetches a catalog by the version id that is built into it. This does not allow any business logic to make a decision on downloading content update at runtime. For example, if you want to send new content to 5% of your users...

 

I’m not sure if the system has such feature, but sounds what you need is to override the addressables url at the runtime.

1. Client requests app server for addressables url.
2. App server returns whatever url that fits the biz logic. For example, send 5% user /update/next/, and the rest /update/current/.
3. Client side overrides default addressables url, and requests catalog...

 

Yep, you got it. Being able to select which catalog would be the most ideal. But short of that, I'd be ok with the ability to tell the client not to pull the latest catalog yet. Or even both.

 

another team in Unity is working on a new package to handle just these sorts of things. They should be releasing this package sometime next month, and in the coming months we'll be working on ways to show our two packages working together. It'll be called Unity Remote Config.
Keep an eye out on the forums, and in package manager for this new package.

 

Very cool. Thanks, Bill.