I’ve seen a lot of tips here, but they all don’t fit.
[1] In some cases, there are examples of how to use drag and drop to access the prefab:
But what if we have 1000 unique prefabs? Any change will lead to a loss of connections.
[2] In other cases, it is suggested to use Resources.Load(path); Resources.Load<GameObject>("Cube")
But it doesn’t work for some reason for a basic Cube type object, which I made as prefab.
It looks like this method is only suitable for basic types like sprite.
So I’m wondering what method should I use to load a lot of objects(prefabs)? Before I can put them on stage using instantiate.
Any Prefab asset reference that is in one of your Scenes listed in Build Settings will already be loaded. There is no further need. Your first example shows a prefab reference to an asset called Cube.prefab somewhere in your Assets/ folder. You can use Instantiate(myRefToMyGameManagerInstance.prefab, ...).
Any Prefab asset that is NOT listed in any serialized references in any of the Scenes listed in Build Settings will need to be built into the final target by including them into a folder called (literally) Resources/. It could be Assets/Resources/ or Assets/MyGame/FinalLevel/BossMonster/Resources/ it just needs to have the exact word Resources in it. So for your Cube.prefab file, you want that to be somewhere in any one of those Resources/ folders.
Let’s say you put it in the folder Assets/MyGame/Resources/BuildingStuff/. Once you have a Prefab asset somewhere in a Resources folder, your call to Resources.Load<GameObject>("BuildingStuff/Cube") should work just fine. Do be careful when your project has multiple Resources folders, as it will be difficult to explain exactly which Cube.prefab you mean when there might be more than one.
Thank you very much! That was the problem.
I suspected that this was an abstract name referring to all the files in my project. But it turns out it was a literal folder. I am disappointed, because I spent half a day searching for this problem.
I agree, but those pages could very much make it clearer what a “Resources folder” is. The way that I originally absorbed this knowledge is seeing Unity Asset Store assets that included that folder, and how they broke if you renamed it. The hotlink in the phrase “Resources folder” even just goes to the Resources class, not a description of what a Resources folder is. Like, one sentence would do: a subdirectory with the literal name Resources.
I noticed that once you install the Addressables package, you get a nice window that shows you the Resources, the Build Scenes, and the Addressable Groups all in one place. Suddenly it’s easy to see that you have some obscure Asset Store asset still installed, and it’s adding megabytes of cruddy chiptune sound effects to your build.
as I said, I thought that everything I have in the project is already in this abstract folder as in the namespace.
It seems to me extremely ridiculous that you need to add an additional folder. Because of this, the hierarchy becomes unnecessarily cumbersome Assets/Prefabs/Resources/nameofresources/.
Aren’t all prefabs/materials meant to be resources? This is strange.
Because Unity strips away all unused assets during build, and it’s a very good feature. Imagine you have to remove all the unused assets from your project manually, after importing 10+ asset store packages, each one with thousands of assets… One of the assets package I added in my current project, called “Ultimate SFX & Music Bundle”, contains 10000 sound effects and 100+ music tracks, totaling nearly 10 GB of size. If not for this feature, I would have to either track every sound/music I use in my project, then go and remove all the unused ones (with the risk of removing ones that I’m using by mistake)… or just ship my game with an additional 9.8 GB of size of unused assets, just from this asset package alone.
Unity automatically knows which assets you’re using if they’re referenced in any game object of your scenes. For those who aren’t, you need to put them in “Resources” folder, or use Addressables/Asset Budles. A very small price to pay for such a great feature.
What do you mean by “abstract folder”? The docs clearly state it must be in a folder called Resources. You should be thankful for this because otherwise your entire project would be loaded into memory upfront.
To be fair as soon as your project stops being a tiny micro-project, you’ll find the Materials/Prefabs/Scenes etc file organisation paradigm becomes extremely cumbersome as well, and you’ll look to other ways to manage your project, such as organising via overarching systems, addressables groups, etc etc.
You can have more than one Resources folder, too, by the way.
So don’t be too tied to one way to organise your project.
It’s dependent on project complexity. I’ve had work projects with many folders directly under Assets thanks to needing third party assets as many of them expect to have their own and you often can’t move them to another folder to hide them without breaking the asset.
For projects that are going to have any longevity to them I create a folder with an underscore (eg _MyAssets) as the root that all of my assets live under. Because of how the sorting is handled the underscore forces the folder to the top of the list.
At least most of the time. Every once in a while you come across an asset with its own Resources folder including things that you don’t actually need.
Agreed. I don’t know how this global top level Scripts / Scenes / Materials / Textures / Prefabs madness ever got started. I think I blame AngryBots from Unity3.3 back in 2011 or so.
It wasn’t even a good idea in micro-projects. For micro-projects, just make a folder and throw it all in.
It’s like parking your car in the garage, taking all the tires off it and putting them in the tire garage, taking the engine out and putting it in the engine garage, then pulling all the seats out and putting them in the seats garage… it’s madness.
Organization is hard though… just like naming. Naming is hard. Really hard. Put effort into it but don’t drive yourself nuts. My tendency is to make a single folder per feature or area or whatever, with “all the stuff for this thing” in that folder. But even that has exceptions.
ALSO… it isn’t always the best idea to try and share everything. The more you share, the higher your chance of “whoopsing” it when you change something without realizing it changed other users, and potentially broke them.
