About 'Tidy Hierarchy = Tidy Mind'!

Unity Courses Talk
, ,
#1

In this video (objectives)...

  1. Parent our defenders and projectiles to a parent object to keep our hierarchy tidy.
  2. Check if game object already exists, if not then create a new one.

After watching (learning outcomes)...

Keep our hierarchy tidy by childing game objects when instantiated.

(Unique Video Reference: 52_GL_CUD)

We would love to know…

  • What you found good about this lecture?
  • What we could do better?

Remember that you can reply to this topic, or create a new topic. The easiest way to create a new topic is to follow the link in Resources. That way the topic will…

  • Be in the correct forum (for the course).
  • Be in the right sub-forum (for the section)
  • Have the correct lecture tag.

Enjoy your stay in our thriving community!

#2

Hey Rick, just a quick note on the casting to GameObject. It is not actually required in this case.

The signature of the Instantiate method is a follows:

public static T Instantiate<T>(T original, Vector3 position, Quaternion rotation)

The return type is generic and determined by the type of the first parameter. Since the prefab we are passing in is of type GameObject the return type will also be GameObject.

Thanks, really enjoying the course. :grinning:

2 Likes
#3

Thanks for this note!

1 Like
#4

Hi Rick, I tried to instantiate the projectile as a Projectile as in the DefenderSpawner script, but I got an error of reference conversion. I would like to know why in the case of the defender you can cast it as a defender and in the projectile case you have to use GameObject.

Thanks for the course!

#5

Hi Fernando,

To some degree the cast doesn’t make a lot of difference, in this specific scenario, for example, in the case of the defender you could cast it as a Defender because the object you were instantiating has a Defender script attached to it, you knew the/a type in advance. So you get an object of type Defender, but if you then wanted to access its GameObject you could use defender.gameObject for example.

In the case of the Projectile you could have done the same, e.g. cast it as a Projectile, as you know there is a Projectile script attached, and then if you needed to access the transform for example you could have used projectile.gameObject.transform.

If you cast as a GameObject then you don’t have access directly to the specific component, but you can access any of the components by using GetComponent<>, so in the case of the defender you could use object.GetComponent<Defender>() or, in the case of the projectile you could have used object.GetComponent<Projectile>() - in both cases object being the variable you declared to store the reference to the instantiated object.

The approach you use will often depend one what you want to do, for example, if you needed access to just the transform, casting as a GameObject will then require a little less code. If you just needed to access properties of the Projectile, then casting as a Projectile will then require a little less code.

Cast the object to the type that you need, or need most.

Hope this helps. :slight_smile:

1 Like
#6

Normaly, all Find methods must be avoid and GameObject.Find is the worse.
Here, you use it, on instanciate object, just for “Tidy Hierarchy”…

You have abused of Find Methods the whole section.
I hope you will teach better practice in the next section.

Privacy & Terms