Regarding best practices of asset management in built versions

I've been reading about how assets should be managed inside of a project, but I am unsure about a few things. As far as I've read, there are two main ways of managing assets in built versions, them being Resources and assigning things in the inspector.

However..

- Resources. According to unity best practices, one should not use this for the most part of it, so that's out for the time being. Link: https://learn.unity.com/tutorial/assets-resources-and-assetbundles#5c7f8528edbc2a002053b5a6

- Inspector assigning works, but unsure if this is really the best way to go with (potentially) a large number of things to assign?


Now onto what I am trying to do:

What I have is a number of different scriptable objects (Items, powerups, etc) that I would like to load into a list at runtime from a directory, and cache it for later usage.

For instance a shop would load items from the cached list that are then offered to the player to buy.


My question is, is this something that really should be worked through in inspector, even if the number of scriptable objects is expected to grow into hundreds?

Creating the cached list from directory sounds at the very least better in terms of management, but I am not sure what the options are for that. Should the advice regarding Resources be ignored and use it anyways, or is there a better way?

 

If you want to work in a style similar to Resources, you should check out Addressables. The main difference is that Addressables are always loaded asynchronously, which can take some working-around during initialization. Otherwise, it's similar: register your SO as Addressable, then load it by its address at runtime.

Hundreds of directly assigned references in the inspector isn't inherently a problem, though. It's slightly more vulnerable to complications if you rely on items having the same index in the list (for e.g. saving and loading purposes), but need to delete and assign new items between versions. If your SO's are very large then it could also take up a decent amount of memory, compared to ad-hoc loading of addressables. Otherwise, direct references are simple and reliable. If you don't need to stream your data, it's the solution I'd choose.

 

Just use

Resources.LoadAll<ClassName>

for ScriptableObjects.

 

The Resources folder is a tool like any other. It can be used wisely or poorly, and is very easy to abuse. But if you're going load all of your ScriptableObject assets when the game starts and keep them in memory, there's very little functional difference between Resources or a more complex solution. In this case, Resources is a simpler solution, so it's less code to puzzle through and maintain in the future, making your project easier to maintain.

 

Thanks for the answers.

That's what I was intending to use, but wanted to make sure I wasn't doing something that could become bad later on based on the warnings I had read earlier.

Somehow this had completely eluded me. Seems like there is certainly a use for the addressables regarding the larger assets specific only to certain scenes. Thanks for the pointer.

Understood. I had initially intended to use it for loading in assets automatically so that it would be easier to maintain, opposed to directly referencing them via inspector every time I added/removed a SO in the project, and was worrying if I had somehow missed some functional difference that I didn't know about. Seems like I just need to avoid abusing it in that case.

 

I mean at the end of the day you're going to have an object reference or an addressables asset reference (which loads an object reference), so it becomes a matter of when you want these objects to hit the user's memory.

Honestly if you want a collection of objects to be easily accessible you could easily use a scriptable object as a rudimentary database, and use some editor scripting to make easy to find everything of a certain type whilst in the edior.