Help fundamentally understanding and using Addressables

[tawdry shard]

Hey everyone, I've spent the past 3-4 days trying to wrap my head around the Addressables system, and frankly I've made no progress. There's something I fundamentally do not understand about it, but from what I've read I basically have no choice but to use it.

I was hoping some people here could explain the system better and answer some questions I have.

Context

• Target platform is PC (Steam), and potentially consoles at a much much later point
• I discovered that Unity loads everything in a public variable in a scene into memory at once. While this seems very asinine I assume there's a reason the Unity Developers had to do it this way.
• I'm looking into Addressables solely to reduce the game size/memory/load time. I have very little understanding of the profiler.
• I will NOT be using any sort of remote assets or paths for my game.

Research

• I've read probably well over 100 different forum posts on Unity Forums and Reddit
• Watched all of the Unity presentations on Addressables I could find
• Watch any videos I could find on YouTube about Addressables
• Read the documentation over several times on different websites
• Read MANY Unity and 3rd party blogs and guides
• Looked through the Addressables samples

Despite all of this I have made zero progress in understanding Addressables, and my development progress has been completely destroyed.

Below I'm going to post several questions and problems I've encountered on Addressables, and if anyone could answer any of them, I would greatly appreciate it.

1: Purpose: Since I'm not planning on using any remote/cloud stuff for my game, is there any point in even using Addressables?

2: Memory: Do Addressabels actually save on memory or storage space? I don't like the idea of every ScriptableObject, sprite, AudioClip, and other assets being loaded in the background at all times.

3: Scenes: Can I simply make each scene Addressable, but active GameObjects and Prefabs can still use public references?

4: Prefab: If a prefab is Addressable, but one (or several) are already in the scene hiearchy by default, are they still loaded into memory right away. Does doing this negate the benefits of Addressables?

5: Public Vars: If I have a "EnemySpawner" prefab that is Addressable, but it has public references to "Enemy" (Spider, Zombie, etc). Are these enemy prefabs still being loaded into memory.

6: SO Database: Would it make sense to just put all spawnable-prefabs (Item, Enemy, Effects) into a ScriptableObject and make those Addressable? That would mean anytime I want to spawn something I have to iterate through the entire list and find it by name.

7: All Assets: Should I just make every asset an Addressable, and group them by type (Enemy, Item, Sprite, Material, Animation)? Seems thats the only possible way to prevent duplicates from showing up.

8: Multiple Scenes: If I put all my (addressable) scenes into the same group, will EVERY scene and all its dependencies be loaded into memory at the same time, since they're part of the same "Asset Bundle"

[silent cedar]

if you don't need the remote features, there's still some benefits. you'll need some way to load stuff at runtime eventually when your game gets big enough, as you found out directly referencing every asset from a scene is not the way! you have more control over the layout on disk than sticking stuff in the Resources folder (important for consoles/downloadable patch deltas and load times) and it gives you some decent tools for working with asset bundles

it's not really going to save memory, assets still take the same amount of space wherever you put them, but it gives you control of what compression to use per bundle and stuff like that

but compared to hard referencing everything yes haha, it will make it easier to avoid actually loading stuff until you need it

a bunch of your questions are about how asset dependencies work, idk if i can explain this better than the docs, but this is something you kind of have to decide for your own game - you have to plan out what the boundaries of each bundle will be and only use soft references when crossing those boundaries