I am in a bit of a confusing pickle here.
So I have an Inventory script, in an inventory GameObject that I stashed in a “Base Fundamentals” game object. My player has a controller that needs to access it, of type Inventory.
I would like on Start(), if null, to go into Base Fundamentals and get the inventory game object (as if you’d drag and drop it into the inspector).
I am not sure how to get around it.
[Tooltip(“Set Inventory Empty GameObject”)]
public Inventory Inventory;
Now i get the error “Cannot implicitly convert type GameObject to Inventory”. But I want to get the inventory from the game object… I don’t know what I am missing to convert it. Any suggestions?
So because I’m on a crusade against GameObject.Find (it’s awful):
If it’s the only one, you can use FindObjectOfType(), and it’ll find the Inventory script.
Or, you could make your Inventory script a singleton, and access it via Inventory.instance (from anywhere! Not just this one script). See the linked article above for a simple example.
Either of these are better than GameObject.Find, and personally I’d lean towards the second one (it’s faster). GO.F is slow and unreliable. Let’s say, in a few months, you absent-mindedly create an object and name it “Inventory” (even something as simple as the text label at the top of your inventory window)? Your script breaks. If you decide on a new naming convention later, renaming the Inventory object is that much more of a headache. And the above problems are amplified tenfold if you start collaborating with someone else on the project.
Also, it’s generally a bad idea to name a variable the same name as a class. The compiler will sometimes get confused as to which one you mean. This is generally solved by making the variable name lowercase or camelCase, while the class name remains PascalCase.
It is awful, but it is part of the learning curve. No matter if we like it or not. And I would rather allow people to find out themselves. They usually don’t listen to these things and more importantly they don’t understand (yet), what is the problem with it. They will find out when they arrive to the state where it makes sense to find out.
I am self-taught but I changed it to “FindObjectOfType” since it does seem like a better alternative. Thanks for the tip!
I keep seeing instancing here and there and apart from copies instance I don’t particularly see the appeal.
Do you have a resource (or the time) to explain it better?
Yeah, I wasn’t my choice, it came with an asset system I got and the inventory is named the same thing everywhere. It’s on my to-do list to make it more unique in the future but I never got around to it.
It means you need to use your classes in the UI section only for displaying things and you need to build more sections to handle data and another system which responsible to take the data from there and deliver it to the UI. But don’t worry about it for now. It’s more advanced stuff. You will get to there later. If you feel adventurous you can search for this on the internet, it’s called either MVC or MVVM pattern (the later is better for these use cases). But don’t let it intimidate you, these are nice to have advanced features and eventually you will get there at your pace.
Cool thanks!
I know about MVC/MVVM I just thought this was used for programs to support multiple threads without UI crashing. I never even considered this a possibility for Unity. I’ll look into it.
Don’t strive for pure MVVM, maybe for your UI (Menus) if you have complex ones. But abstracting Unity framework from your game mechanics domain is just counter productive.
But using game objects as data containers often lead to fragile design. It’s a balance to find the correct level of abstraction. But never rely on FindObjecet etc
Example from our game Inventory slot inherits gameobject because our game is VR and the stored item is visible in 3D space, but the actual container is a standard collection
but I changed it to “FindObjectOfType” since it does seem like a better alternative. Thanks for the tip!
