Thanks for reading. I’ve been reading the manual over and over but still have a few questions about Addressables workflow, particularly around updates, and would appreciate any info!
Our current situation: We currently publish about a dozen “Fix My Car” games that are similar in concept but vary a lot in content. Let’s call the common game engine and programming that each game uses “CORE”, which is about 30MB in size. Let’s call the unique content of each game “DLC”, which are about 70MB in size and consist of hundreds of textures, sound files, etc. Currently for each game we build the CORE + DLC together and publish it to a unique store listing. It’s a lot of work keeping all listings updated. It uses Addressables but only locally (built with player).
All CORE assets are labelled “CORE”. All DLC1 assets are labelled “DLC1”, etc. When the user opens one of the DLCs I request all of that DLC’s assets by label to determine download size, then download them all by label.
Where we’d like to go: We’d like to take advantage of Addressables fully by building and publishing only the CORE game, with each DLC remotely downloaded via IAP. Only one listing to keep updated on the store instead of a dozen!
If I were to a change a file in one of the DLC groups, would the user have to download the entire DLC again, or would Addressables only download the difference? I understand that if I play with Content Update Restrictions that it may rebuild the bundle (“content build”) or build a new delta bundle (“content update build”), and in both cases I’d have to upload to remote again, but what impact would it have on the user?
In my current workflow I “Use Existing Build” as the Play Mode Script for testing my game in the Editor. Every time I change content I then run a quick script that: CleanPlayerContent() and BuildPlayerContent(). Is clearing the Player Content going to cause problems once I have bundles uploaded remotely? Does BuildPlayerContent always do a full “content build”, or does it do a “content update build” (depending on settings)?
I’ve noticed a lot of warnings about having to retain the “addressables_content_state.bin” file after every build. Is it truly necessary to retain this file after EVERY build, or will it keep being updated with every build I do? As per #2, I may clean and build many times before I actually want to publish anything to remote. Is this file only required if I want “content update builds”, as per #1?
How can I build all the CORE and all the DLC bundles but ensure that only the CORE bundle is included locally with the player, while excluding the DLCs from the player? I found an “Include in Build” option in Asset Group Schemas but that seems to toggle on/off building it entirely when I perform a build (see #2).
Hello, so let me see if I can answer a few of your questions. For starters, it is possible to have your built content separate from your various CORE apps and then download DLC into each of them from the same location. This manual page actually outlines how you can do that: Loading from Multiple Projects | Addressables | 1.19.19
For your other quesitons,
If you change a file, whatever AssetBundle that was previously built into gets totally rebuilt. Also, any AssetBundles that depend on that AssetBundle (not just the changed asset) have to be rebuilt. AssetBundles don’t support delta patching, so the whole bundle gets downloaded. If you’re not careful, this can lead to users having to download quite a bit after a content update. Here’s one page that talks a bit about different Group strategies and how that correlates with AssetBundles Packing groups into AssetBundles | Addressables | 1.19.19 All that to say, be mindful of how you organize your Groups, what assets depend on other assets, and what you change
Build Player Content is always going to do a full build. I’m thinking about this in the context of development iteration. We don’t automatically upload anything after a build, that’s why the Packing & Loading schema has the concept of build path vs. load path. So, if you’ve done a build, uploading some content, then done another build and enter playmode, you’re going to be pulling those remote bundles if that’s where a Groups load path was pointed to. The newly built bundles are going to need to be uploaded in order to reflect the changes in your game.
As a note on this, this is kind of what different Profiles are meant to address. If you had a “development” profile that had it’s build and load path set to a local folder for “remote” content, and then used the Editor Hosting service or some other hosting app to “locally host” that folder, it could make for a streamlined development. Then, when you’re releasing, just change the Profile to the correct one that populates the build and load paths with what you want for production before building your Addressables content
The bin file is only relevant if you plan on doing content update builds. But, mainly the file is there to try and help you make sure you’re not building changed assets that you really didn’t mean to change. If you do a full content build, that produces a new content catalog so your already deployed apps don’t know how to access the new remote catalog. It’ll require a new release of your CORE project. Or, you can leverage the Player Version Override setting in the AddressableAssetSettings to keep the catalog name consistent between builds. If you’re planning on releasing updates to DLC but don’t want to deploy a new build of the game, I’d say try doing the Content Update workflow.
A note about Content Update. We know that it’s a lot to manage and are actually going to be deploying some workflow changes in 1.20 (currently in our release pipeline) to help streamline the process. It still requires you to keep track of your content state bin file, but we make it easier to build and forget
I believe the content state bin file only gets created at the end of a full build using the Default Build Script. If I remember correctly, content update builds don’t create a new one.
For this you’re going to want to use the Local build path pair for the Build & Load Paths. The values in that path pair are treated somewhat specially. You can read about building for local content here: Making builds | Addressables | 1.19.19 but basically, if you use that default path on a group, anything that gets built to that folder in the Library/com.unity.addressables/aa/// gets copied to StreamingAssets at player build time. The default load path for that path pair resolves itself to the StreamingAssets path we built the bundles to at runtime
@davidla_unity , thank you very much for this detailed response, this helps me understand everything a lot more. I will have to adjust my Addressables strategy, especially in breaking out my large bundles into smaller ones so the user won’t have to download entire DLC bundles again if a single mp3 changes (assuming I use only “content builds” and not “update builds”).
There was one major surprise for me. It’s about your comment here:
Could I give you a scenario and then ask some clarification?
Assuming:
CORE is already published and people have downloaded it and some of the DLC bundles through it
One of the DLCs changes post-release, and a “content build” and not “update build” is performed
“Build Remote Catalog” is enabled, “Player Version Override” is not enabled (it timestamps the catalog)
The new DLC bundle and the remote catalog is uploaded to the same remote host as the current DLC bundles + catalogs
Clarification questions:
Current CORE users will NOT see the new remote catalog (it doesn’t search by timestamp?)
Therefore, current CORE users will not be aware of the new bundle (with new hash), and therefore not be prompted to download it when I request that DLC?
If the above scenario remained the same except that I enabled “Player Version Override” so that the remote catalog always had the same name and was replaced when I uploaded the new remote catalog, would existing CORE players now load the new remote catalog, and therefore “see” the new DLC bundle, and therefore be prompted to download it when I request that DLC content?
REALLY appreciate your help so far. You are the most helpful three-headed employee at Unity!
