This is not a problem or anything, but I was wondering about some best practices around my code. I started really storing the stuff my soldier is going to use and their respective type. Eg.: I need the location of and object I would get it’s transform. Do I need to access some value on other script? Great, store it’s script on a new ScriptType anotherScript and then reach it through a GetValue().
This is, a whole bunch of times, I need other values from the same object. On the same example as above, since I need both the location of such object and his script to get the value, I’m storing the whole GameObject and accessing it’s transform or the GetComponent() when needed.
I’ve been doing this for a while now, to a point where I rarely store a transform, or a script, I just get the whole GameObject. Is this a problem? Performance wise, best practice wise?
Following the same matter, I’m passing whole GameObjects when needed, and then extracting the values I need from it. In short, rather than getting the object and then storing only it’s script, I usually just store the whole object, since chances are I will get other information from it and the script won’t have then.
is there any problem in the long run? Does this go against any pattern? If so, is there any workaround or I should keep declaring specific variables?
@ : I do store the value of GetValue() if i’m going to use it more than a couple of times, like inside a loop or the update block, but other than that, even if it is a common function to be called, I just do the GetComponent().GetValue().
In terms of performance: not a huge hit. GetComponent is not slow, and you’ve said that you’re caching the results where necessary. Whether you’re saving a reference to a GameObject or a component, it’s just a reference – you’re not passing copies of the whole GameObject around, so you won’t run into a memory issue by doing this either.
In terms of robustness: slightly risky. Declaring your intended type rather than GameObject acts as a kind of type safety. You can forget to set the field in the inspector whether you use GameObject or MyType, but if you forget to add MyType to GameObject, this will not be obvious to you when looking at the inspector. You’re inheriting some of the problems that string keying has by making this a universal practice.
In terms of patterns: you do you. I don’t think this will break the bank either way. When getting many components from the same object it makes more sense to get the common parent. Personally I would not do this universally – I value visual cleanliness in my scripts, and having GetComponent<> peppered through all of my scripts would give me a hernia.
In this example, I would probably declare ScriptType whatever and access the transform via whatever.transform. I don’t know how to characterize my approach, but I really don’t find myself in these kind of situations, where I’m feeling the need to declare multiple variables to talk to the same object.
Wow, Madgvox, you got exactly my concerns. I wasn’t sure if I was clear enough:
This is extremely satisfying to read, even though I knew I wouldn’t be creating a new object, I was thinking the bigger the GameObject, the more data I would be passing between scripts. Since it is only the reference, it only says where the object is on the memory, and then get information when needed.
I’ve been there. I was checking Tags and went through some trouble only to find I was “asking” the wrong object. It was a while and I can’t remember, but I’m trying to be more clear on what I’m getting from each object. Totally noted and I will think better which information I need from each object.
How about this?
if (mySelectedCoverLocation.GetComponent<CoverLocationController>().GetLocationSide().Equals(myLaneGO.GetComponent<LaneController>.GetCoverFarBackUpLane()))
Joke! This was a test only and is now commented. Haha
Hum… I don’t know but it doesn’t look usual that a script has a transform.position, since the script is a component and the transform also is one. It’s like getting the color of a car, and assuming the motor also is of that color. The color and the motor are components from the car. Weird example but it’s the one I thought now.
Scripts don’t have a transform, the GameObject has one. All scripts inherit from Monobehaviour, which inherits from Component. Component has a transform property. Since scripts are required to always be associated with a GameObject, this property allows any script to easily access its GameObject’s transform.
Hm… Since it is always associated from a Game Object, logically, the script will be somewhere in the scene, thus, it’s Game Object also means its location.
Yes, exactly. Every gameobject has a Transform component which defines the object’s position in the scene. Also even though components do not contain other components, the Component class also has a GetComponent method which is essentially a shortcut for gameObject.GetComponent. This always works since a Component can not live without a GameObject. For the same reason every Component has a transform property which gets the Transform component on the same GameObject of that Component.