Are addressables a good idea for projects without content updates?

Hi there! My situation is that I'm currently working on a game right now. It will be a game released once and without any content updates planned. However, for purposes of game localisation, I will need to load the localised resources during runtime (unless there is some better approach I'm not aware of).

I just discovered the Addressables system today, from what I've seen so far, it seems like it's targetting large games. However, the only other options for loading resources during runtime that I know are:

• Resources Folder, which is not recommended.
• AssetBundles, which are hard to use and platform-specific, and I would prefer a platform-independent solution.
• StreamingAssets Folder, which is used to store files that will read directly, but I'm not sure if it will work with the ScriptableObjects that I will need to load.

Now, going to the main question, given the context provided above. Are Addressables a good idea? Can they handle the generation of AssetBundles (or that other format I heard of in the 2018 talk in LA) per each platform from a single machine?

 

Because using addressables without content updates is relative an easy job. Comparing with rolling out your own solution, I think it's a good idea.

You can simply put each language specific content into a group, and load then on demand.

You need write a build script, and then switch platform manually to build for different platforms. It may feel a bit verbose, by doable with more efforts put on your CI side.

 

Yeah, but for the most nebulous reasons ever.

Using the Resources folder is fine for what you’re describing.

For something that simple and straightforward I don’t see how it is worth it to up the complexity of your code and building process and add more dependency to untested Unity systems, just so you can avoid the Resources folder, because... uhhh... because what?

 

Because you end up using a lot of RAM loading resources and all of their dependencies on startup. In some cases that is absolutely fine, in others it is not. For example, if you are storing localisation data and you have 20 languages and some of them are referencing massive multi-page atlases, it can be a problem. We run into that one recently and had to move localisation data to asset bundles (via the addressables system) to resolve it. There are other solutions, but that one worked for us because we already use addressables to manage our asset bundles.

It all depends on the needs of your project.

 

Not really though, people keep saying this, but from what I can tell this is simply false.

 

You are right that it is a bit more intricate than that, in that it will not magically load everything into memory (other than the type tree, which can take a while with a lot of objects) if you do nothing at all. However, when doing localisation it is common to load all objects of your localisation object type to find what languages are available, unless you have some sort of separate catalogue for them. Unless you have soft references to necessary assets in those, you are going to load a lot of stuff into memory.

I guess at this stage it is worth asking what the target platform is to find out whether it's worth worrying about.

 

Why do you need to find out? Don't you already know what kind of languages you are shipping?

In any case, I've been using Resources folder to store a variety of optional content and localisation text files for 5-6 years. Our game worked fine on an iPhone 3GS. If you're doing a reasonable use, Resources folder is just fine.

 

Because we don't tend to hardwire anything like that in code and leave it to the designers. We could have added a catalogue that they could use to list the languages in there but since we were using Addressables anyway, we transferred everything to there, which allows languages to be downloaded from a remote source as well.

But yeah, I do see your point of view and would be inclined to agree, resources folder use is fine for reasonable use.

 

In many cases Resources is just fine, but there exist scenarios where is is not feasible, even in the case of a release-and-forget game.

For example, there exist consoles where you are restricted from hitting the same ROM location too many times, and over reliance on Resources falls afoul of that.

Alternately, you might need to have a tiny file size for your game in order to avert download restrictions in mobile app stores.

As I see it, the safest bet is to start with the asset format that should be acceptable in all cases, so that you have the freedom to go where you need to be without issue later. If Resources are okay for 80% of situations and it’s all you know you are needlessly limited in your reach.

 

Hi there! Thank you for your info. I was so focused on the project that I forgot to check this We are targetting mainly Windows, and have considered to release it for the other two main Desktop platforms (Linux and Mac). So I guess we will be fine using the Resources folder. On a side note. Does anyone knows why there is a LocalizationAsset on the Scripting API but zero examples about it? https://docs.unity3d.com/2019.1/Documentation/ScriptReference/LocalizationAsset.html

I would prefer to avoid re-inventing the wheel if there's already a localization system available that we could adapt.

Edit: I found that class by accident when I was implementing my own localization classes.