Two lines of code work. Want to understand the difference.

Hello

In Unity Junior Programmer Pathway, on Lesson 5.4, there is a step where we add

Code (CSharp):

1.     public GameObject titleScreen;
2.  
3.     public void StartGame()
4.     {
5.         titleScreen.gameObject.SetActive(false);
6.     }

I noticed that the Visual Studio's suggestions seemed to want to skip ahead to SetActive without gameObject, so I tested it to see what happened.

Basically, these two lines of code appear to work exactly the same:

Code (CSharp):

1.         titleScreen.gameObject.SetActive(false);
2.         titleScreen.SetActive(false);

Is there some subtle difference that isn't manifesting in this situation? Or is the gameObject an explicit declaration that is unnecessary because we declared the variable titleScreen? Just trying to understand the subtleties of syntax. Thanks in advance.

 

Please use code tags: https://forum.unity.com/threads/using-code-tags-properly.143875/

 

titleScreen is already a GameObject, so .gameObject is not needed.

 

Thanks that's what I was thinking. Much appreciated.

 

I don't know what "Unity Junior Programmer Pathway" is but I hope you're not paying money for it if it does that with no explanation.

And like Kurt said please use code tags, it's much easier to read.

 

I wasn't aware that GameObject has a gameObject property which refers to itself. I don't see it in the scripting reference. Usually you'd use that property in a script to refer to the GameObject which the script is attached to. But apparently this is actually valid code:

Code (csharp):

1. Collider c = gameObject.gameObject.gameObject.gameObject.gameObject.gameObject.gameObject.gameObject.gameObject.gameObject.gameObject.gameObject.gameObject.gameObject.gameObject.gameObject.GetComponent<Collider>();

Well that gave me a laugh.

 

I noticed that too a while back, the .transform also has that.
you can also go

Code (CSharp):

1. transform.gameObject.transform.gameObject.gameObject.transform

and etc.

 

At least I've actually used transform.gameObject before

 

Well transform.gameObject and gameObject.transform are actually a useful thing, hehe, but the side effect is transform.transform and gameObject.gameObject
because they're both components and every component has a .transform and .gameObject, or something like that

 

It's GameObjects all the way down until you reach the first turtle.

Then it's turtles all the rest of the way down.

 

No, they are both unnecessary ^^. Keep in mind that you are actually using

Code (CSharp):

1. this.transform.gameObject
2. this.gameObject.transform

Since "this" always refers to the Component / MonoBehaviour you're currently on, both make no sense since you can directly do:

Code (CSharp):

1. this.gameObject
2. this.transform

 

It’s from Unity Learn...

 

What about when you have a reference to a gameObject or a transform and you're not on the monobehaviour that sits on said object?


edit: also, this is because a monobehaviour is a component too so you're still using the component .transform and .gameObject i mentioned earlier.

 

tsk tsk tsk.. they really need to step their game up when it comes to teaching.

 

Teaching is hard in the broad sense, especially when the domain of knowledge is massive (C#, the Unity API, and interactive graphics programming in general).

It's even harder when the target audience skill levels run from "Yeah, I've heard of computer games before..." all the way to "I wrote my own game engine entirely in ARM64 assembly language."

I'm sure they got a budget with an intent to spend the money to improve uptake of their engine and widen the market of people who could fill jobs and be productive in Unity, and to that end bravo, because Unity is still the #1 best game engine ever. Fight me bro!!

 

Oh don't get me wrong, I know it's hard to teach and the problem too is that a lot of people don't actually wanna learn like you're suppose to, they just wanna be shown the magic button that creates the game.

But you gotta agree with me that both the learning resources they offer and the docs are not up to par with most competition on this scale, I don't have any examples at hand but I have a lot of time where I look at the docs and I think "Who the hell wrote this page? not only is this not the right information this is also not good practice and actually confusing".

If you wanna take this outside i'll find some examples

 

Come on Joe that's not maintainable! At least let us configure it easily!

Code (CSharp):

1. int depth = 25;
2. GameObject go = gameObject;
3. for (int i = 0; i < depth; i++) {
4.   go = go.gameObject;
5. }
6.  
7. Collider c = go.GetComponent<Collider>();

 

Consider
transform.GetChild();
Why should this be transform and not gameObject?
Transform is a component, but it's on all gameObjects. BUT, as a component, it's *not* the gameObject. But we sometimes use it that way. Legacy support maybe?
I'd much rather it was consistent...

 

I'm not sure I understand what you mean..

Parent-child relations are handled in the transform component, which all game object must have, other component(game object included) don't have .parent for example, this is part of the transforms job

 

Just seems like the parent-child stuff should referenced via gameObject, as it's the "whole object", not a component of it. So basically what you see in the Hierarchy.
Though with the relative positioning/scaling etc I guess the transform makes sense too.

 

It's actually really good, considering that it's free and intended to get more people into developing with Unity. Through all of my experiences with Unity, I'd say it's the thing they've done best with their entire software suite and experience. You should check out Unity Learn. I'd recommend it to anyone as an example of course content done right.

That said, the software itself has a lot of issues that really undermine everything the Learn team does to try to entice new users.

 

To be fair..."this" is not needed either.
gameObject
transform

both refer to the object the script is on.