While it is impossible to provide a comprehensive taxonomy of all the different ways to organize assets in projects, Organizing Addressable Assets outlines several considerations to consider when planning your organizational strategy.
When considering how to manage your assets, you should also understand how Addressables interact with your project assets.
Addressable groups are your primary organizational unit for managing addressable assets. An important consideration when using Addressables is the option to package groups into AssetBundles .
In addition to group settings, you can use the following to control how Addressables work in your project:
- Addressable Asset Settings : Project-level settings
- Configuration file : Defines a collection of build path settings, and you can switch between them depending on the purpose of your build. (Primarily of interest if you plan on distributing content remotely.)
- Tags : Edit the addressable asset tags used in the project.
- Play Mode Script : Choose how the Addressables system loads assets when entering play mode in the editor.
AssetReferences provide a UI-friendly way to work with addressable assets. You can include AssetReference fields in MonoBehaviour and ScriptableObject classes, and then assign assets to them in the editor using drag-and-drop or the object picker dialog.
The Addressables system provides the following additional tools to aid development:
- Analysis Tools : Provides various analysis rules that you can run to verify that you have organized your assets the way you want, including reports on how Addressables has packaged your assets into packages.
- Event Viewer : Provides a profile view showing when your assets are loaded and released. Use Event Viewer to verify that you are releasing assets and monitor peak memory usage.
- Hosting Service : Provides a simple asset server that you can use to host locally developed remote assets.
- Build Layout Report : Provides a description of the AssetBundles generated by the build.
- Build Profile Log : Provides a log profile of the build process itself so you can see which parts are taking the longest.
Organization Addressable Assets
There is no single best way to organize your assets; it depends on the specific requirements of each project. Aspects to consider when planning how to manage assets in a project include:
- Logical organization: Keeping assets in logical categories makes it easier to understand your organization and spot items that don't fit.
- Runtime performance: If your bundles become very large, or if you have a very large number of bundles, performance bottlenecks may occur.
- Runtime memory management: Grouping assets that are used together helps reduce peak memory requirements.
- Scale: Certain methods of organizing assets may work for small games but not large ones, and vice versa.
- Platform characteristics: The characteristics and requirements of the platform are important considerations in how to organize assets. Some examples:
- Platforms with abundant virtual memory can handle large bundles better than platforms with limited virtual memory.
- Some platforms do not support downloading content, completely precluding remote distribution of assets.
- Some platforms do not support AssetBundle caching, so it is more efficient to place assets in local bundles whenever possible.
- Distribution: Whether you distribute your content remotely or not, it at least means you have to separate remote content from local content.
- How often your assets should be updated: Separate assets that you expect to update frequently from those that you plan to update infrequently.
- Version Control: The more people working on the same assets and groups of assets, the more likely there are version control conflicts in the project.
common strategy
Typical strategies include:
- Concurrent use: Group together assets that you load at the same time, e.g. all assets at a given level. This strategy is usually the most efficient in the long run and can help reduce memory usage spikes in your project.
- Logical Entity: Group together assets that belong to the same logical entity. For example, UI layout assets, textures, sound effects. Or character models and animations.
- Type: Groups assets of the same type together. For example, music files, textures.
Depending on the needs of your project, one of these strategies may make more sense than the other. For example, in a game with multiple levels, it may be most efficient to organize by concurrent usage from an item management and runtime memory performance perspective. At the same time, you may use different strategies for different types of assets. For example, your menu screen UI assets might all be grouped together in a level-based game, but otherwise have their level data grouped separately. You can also package groups containing assets of a certain level into packages containing assets of a specific type.
For more information, see Preparing Assets for AssetBundles.
Safely edit loaded assets
You can safely edit loaded assets if:
- Assets are loaded from asset bundles.
- The app runs in the player, not the editor.
- When you enable the Use Existing Build (requires built groups) option in Play Mode Scripts .
In these cases, the asset exists as a copy in active memory. Changes made to these copied assets will not affect the saved asset bundle on disk, and any changes will not persist between sessions.
For other cases, including when you enable the Use Asset Database (Fastest) or Simulation Group (Advanced) properties in the Play Mode settings , Unity loads assets directly from the project file. This means that Unity will save any modifications to assets to the project asset file at runtime, and those changes will persist between sessions.
If you want to make runtime changes to an asset, Unity recommends that you create a new instance of the GameObject you want to modify, and use a copy for any runtime changes. This removes the risk that you might accidentally modify the original asset file. The following code sample demonstrates creating a new copy of a loaded asset:
var op = Addressables.LoadAssetAsync<GameObject>("myKey");
yield return op;
if (op.Result != null)
{
GameObject inst = UnityEngine.Object.Instantiate(op.Result);
// can now use and safely make edits to inst, without the source Project Asset being changed.
}
If you use the above method to use a copy of Asset, you need to pay attention to the following points:
- When releasing an asset, you must use the original asset or AsyncOperationHandle, not the current instance of the asset.
- When you instantiate an asset that references another asset in this way, Unity does not create a new instance of the referenced asset. References to newly instantiated copies target the original project asset.
- Unity calls the MonoBehaviour methods Start(), OnEnable(), and OnDisable() on the new instance.