When you declare a public field in a script that you attach to an game object, this field is displayed in the inspector, and you have the option to “drag” some object/component to this field (if the field is of the appropriate type). How does this work and how could I replicate this behavior if I wanted to do it without the editor?
Suppose we’re in a scene which contains objects with specific names (those that we can see in the scene hierarchy). Whenever one these objects is created in the hierarchy, maybe its given some sort of unique code (not necessarily corresponding to its name in the hierarchy), and this object is declared as a field in the “scene” object declaration? Scene being some sort of basic object that holds a reference to all the game objects in the scene.
If I could figure out the name of the objects as variables in the “scene”, I could directly do certain things, like set their fields, etc. But how would I find out this name?
To find a game object in the scene you have multiple options :
GameObject.Find(gameObjectName);
GameObject.FindGameObjectWithTag(tagName);
GameObject.FindObjectOfType(type); (type being a component type, i.e. BoxColider, RigidBody and your own custom MonoBehaviours).
But, using these methods is assumed to be a bad practice, can quickly become a mess and it’s pretty hard to maintain, plus it’s really slow as these methods are looping through all gameobjects that are in the scene.
When you drag and drop a component inside a field, the field holds a reference adress to what the object is, and it is serialized. If you want to do that at runtime with code (without the serialization this time), you can use the GetComponent method.
Thanks. I don’t really understand in what sense it is serialized - what exactly does this mean?
Couldn’t I somehow get the reference address to the object? If I know the object exists because it’s in the hierarchy, surely there must be a way to figure out the address of the object, without having to go through all the objects in the scene, no?
I’m not entirely sure to understand what serialization really is (maybe someone else can explain, or you can search for that on google) but somehow the serialized informations are stored somewhere and they can be accessed.
Best explanation
I’m not sure to know why you would even want to have those addresses though. Unity does the job himself, there’s no need to know exactly how all that works. You will never make a game if you try to understand every bit of Unity before starting
If you want a specific object to be referenced for use at runtime, you can just have that reference stored inside a list, serialized or not serialized doesn’t matter.
I’m mostly just curious about this, for no useful reason. It just seems like something basic and crucial that underlies a lot of what happens, and so it feels like something I should (and also want to) understand.
I got interested, because I wanted to make a custom delegate reference in Class1 game object A to a method of Class2 game object B (the method was not contained in the same script as the one in which I had the delegate instance). However, a public delegate field doesn’t allow you to “drag and drop” like say a public game object field does. I know I can get this functionality with a UnityEvent, but that felt a bit redundant, because I knew that a delegate would be enough and it seemed like a reasonable choice.
I also realize I could set the delegate by adding a reference to the Class2 object in Class1, and then set the delegate to be B.method - but this forces me to declare a specific Class reference in Class1, for any Class (here for Class2 particular), meaning I would have to annoyingly keep adding references of specific field types in the script, depending on what class the method is, ending up with the Class1 declaration containing a lot of fields for references. Maybe this could be done if I could somehow reference an “arbitrary component”, but I don’t know how to do that.
And so I got interested in how I could find the address of some method, which got me thinking “hold on, I don’t even know how to get the address of an object, let’s start with that first”, and so I made this thread and my previous thread
Really, I don’t think you should bother with that. Why would you need to have all objects stored inside one class ? You wouldn’t know which object is what unless doing many checks. And what about all those objects that won’t be used via scripts (and there usually is bunch of them) ?
I think you should just think as Objects and Prefabs, as Unity wants us to do. Have simple objects that works by themselves only, and interact between objects via messages or events or whatever but hard references.
