Search Unity

  1. Unity 6 Preview is now available. To find out what's new, have a look at our Unity 6 Preview blog post.
    Dismiss Notice
  2. Unity is excited to announce that we will be collaborating with TheXPlace for a summer game jam from June 13 - June 19. Learn more.
    Dismiss Notice

CCD Addressable Setup

Discussion in 'Unity Cloud Content Delivery' started by CineTek, Feb 9, 2021.

  1. CineTek

    CineTek

    Joined:
    Jul 12, 2013
    Posts:
    98
    Hi there,
    We have been using UCB for a few years now but just switched to the Addressable System and Unity CCD for our current project:
    There seems to be a lot of outdated information going on in the official documentation pages and the lack of proper tutorials and/or guides/best practises does not help.
    So I just wanted to go over our expected setup quickly and see if anyone spots any obvious errors/potential issues on how we handle this.

    We are pretty much trying to replicate a similar slightly simplified workflow as shown here by the way:


    Unity Cloud Build
    Every platform has (at least) 2 build targets: Development and Production that build the player.
    - Development runs continuously on every push (GIT)
    - Production is "manually" triggered on very specific commits through Jenkins
    - Additionally each platform has a "Content-only" build target that is supposed to update the CDN data only

    Now with that being said, from what I understand it does not make sense to have "Content-only" build targets for the "development" as Cloud Build requires to re-build the Addressables every time there is a new build?
    ---> You can have multiple content-updates but only one build(?) <---- (taken from a different thread)


    CCD
    3+ Buckets for each platform (Development, Staging, Production)
    Content from dev moves into staging for QA and then into production "manually"

    It looks like all official Unity tutorials (plus all third-party ones) always use one huge shared bucket for all platforms so my question is:
    Do we *have* to use e.g. RemoteConfig on the client(s) to grab the correct bucket for each platform or is there another way I haven't seen yet that allows us to set this up in this specific way?
     
  2. CineTek

    CineTek

    Joined:
    Jul 12, 2013
    Posts:
    98
    Looks like... you CAN make a completely new build using "old" remote addressables...? I thought this behaviour was not supported?
    Could someone confirm/deny this please?
     
  3. dannyd

    dannyd

    Unity Technologies

    Joined:
    Jun 3, 2014
    Posts:
    787
    Hey, sorry I missed this post previously. For configuring the CCD side of things, we generally recommend creating buckets the way you describe (i.e. for each platform, creating separate buckets per environment). Alternatively, you could just rely on badges and create a single bucket per platform - up to you really to decide how complicated your workflow will be within each environment.

    As for the question about pointing to the correct bucket, this will depend on your binary build strategy. If you are creating a separate binary per-environment (i.e. separate binaries for staging vs. production) then you should be able to configure separate profiles that point to the correct buckets (or badges).

    If you need something more advanced, you might want to look at using the curly bracket notation when configuring the load path in Addressables
    (https://docs.unity3d.com/Packages/c.../manual/AddressableAssetsProfiles.html#syntax). This portion of the path is evaluated at runtime, so you can use whatever logic you want to determine the correct path (whether from your own backend, or some logic built into the app based on which environment the binary is supposed to be running for).

    And the follow-up question about new build / old content - I'll ask someone from the Addressables team to weigh in there. I'm not 100% sure on the answer and don't want to mislead you.
     
  4. CineTek

    CineTek

    Joined:
    Jul 12, 2013
    Posts:
    98
    Thanks this is very helpful already! This whole topic is very advanced for sure but sounds like we are on the right track. Having someone from the Addressables team confirm this would be super helpful, thanks!
     
  5. unity_bill

    unity_bill

    Joined:
    Apr 11, 2017
    Posts:
    1,053
    I'm not sure I totally understand the question, but I'll give what answer I can. Addressables content is built as a separate step from building the player. This build includes all local bundles, all remote bundles (if any), a local copy of the catalog, a remote copy (if enabled), and some core settings info. That core settings info knows things like where the remote catalog is.

    After you've built content, you can build the player all you want and it'll be fine. If what you are describing is:
    1. build content
    2. build player v1
    3. change content
    4. rebuild content, but don't upload
    5. build player v2 and hope it'll work with the original content
    This is a little more tricky. It could work. It depends on what all you changed. If the new content is the same as the old, you're fine. If the new content is different, you might be fine, or not. In this situation you'd have a player with new local content and old remote content. Are they compatible? Is the old catalog on the server going to understand the new local content?
    Maybe is the answer to all that. Setting up your group setting to not include hash of content will help (so bundles have the same name despite new content). Similarly avoiding hard dependencies between remote and local content will help. All in all, it could work, but is potentially fragile.

    Though again, I'm not 100% sure what you are asking, so I could be answering the wrong question.
     
  6. CineTek

    CineTek

    Joined:
    Jul 12, 2013
    Posts:
    98
    Thanks, this is actually what I wanted to know. It will come down to our internal architecture and further planning to see if it will work out like this.
    I read in some other thread that it does not work with new player but old content so thanks for confirming!
    I am definitely going to follow up in a bit with our new setup
     
  7. sskenth

    sskenth

    Joined:
    Sep 23, 2016
    Posts:
    54
    Hi I thought this was such an amazing video!

    I've been using CCD and loving it as well as addressables. At the moment I'm using 1 bucket, but I'd like to start using more buckets to help with testing before moving to production.
    I hadn't thought about changing the buckets URL using Remote config. That's a genius idea, I'd love to get a tutorial or some steps to understand how to achieve this. I'm not sure how to change the addressable config URL from the remote config data. That seems to be a missing step for me, which was not quite covered in the video.

    Any help would be really appreciated on connecting the remote config data to the addressables url at runtime and changing it depending on device/use ID idea to help test for different buckets for different users would be great.

    Thank you!
     
  8. ArturoNereuUnity

    ArturoNereuUnity

    Unity Technologies

    Joined:
    Sep 4, 2014
    Posts:
    17
    Hey sskenth, thanks for the nice comments.

    As for your question, I would suggest you taking a look at this thread: https://forum.unity.com/threads/change-remote-catalog-load-path-at-runtime.712052/

    Then having a remote config value holding the bucketID you want to use and then replace it in the .../buckets/{bucketID} .

    Hope it's clear. And good idea about working on tutorials for these type of uses cases. We'll look into that.
     
  9. sskenth

    sskenth

    Joined:
    Sep 23, 2016
    Posts:
    54
    Thanks for the reply. I managed to see that thread a few days ago. Also followed it and got it working.

    Works really well.

    If you could expand on it with further tutorials that involve badges for version etc that would be great.

    Thanks for all the information and hard work
     
  10. lordshadowist

    lordshadowist

    Joined:
    Aug 1, 2013
    Posts:
    3
    Can you give a list of steps to follow starting from scratch that allows us to upload a prefab to CCD and instantiate that prefab using the Addressables system in code?
     
  11. ArturoNereuUnity

    ArturoNereuUnity

    Unity Technologies

    Joined:
    Sep 4, 2014
    Posts:
    17
    We're wrapping up some content to show that workflow, I'll post the link to it once we have it out. Thank you for your interest!
     
  12. ArturoNereuUnity

    ArturoNereuUnity

    Unity Technologies

    Joined:
    Sep 4, 2014
    Posts:
    17
    Here's the video with the information I was talking about. Hope it's useful:
     
  13. lordshadowist

    lordshadowist

    Joined:
    Aug 1, 2013
    Posts:
    3
    Cool Thanks!
     
  14. NicolasBasilGerard

    NicolasBasilGerard

    Joined:
    Nov 3, 2020
    Posts:
    7
    Hello,
    I am setting CCD on our project to host our addressable bundles. One thing I'm a little confused about is that (assuming I use the same setup than this video) when I promote a dev release to production, although my production binary can find the catalog file in the bucket, the urls for the bundle themselves will still point to the development bucket. If I push a new release on production, at best I update all live bundles to the production one, at worst I break everything.
    What is the intended way to use the release promotion system with addressable? Getting curly braces values in the loading path that get set by remote config ?
     
  15. sebastienUnity3d

    sebastienUnity3d

    Unity Technologies

    Joined:
    Sep 23, 2020
    Posts:
    24
    Hi,

    Sorry for the delayed response. I hope I understand your question properly.

    A pattern that we have seen often with our developers is that their RemoteLoadPath in Unity Editor Addressables will have the production bucket value. They also add the badge name in the url that refers to the release that you want your clients to be assigned to.

    Example of the URL for RemoteLoadPath
    https://<projectID>.client-api.unity3dusercontent.com/client_api/v1/buckets/<production_bucket>/release_by_badge/<badge>/entry_by_path/content/?path=

    So when you promote a release from a dev bucket to the production one, the clients will get that production release.

    Remote config can be also help you if you want the bucket value and the badge name to be define at runtime.


    Hope it helps. Let me know if it doesn't.