Matt Bird writes all sorts of nonsense, but he enjoys writing tutorials for Unity.
Parent and child GameObjects are vital concepts to understand when programming a game in Unity. Virtually every game will rely on constant changes in parent-child interactions, so learning what these interactions do - and how to form them in the first place - is an important lesson for a new programmer. This article will explore the nature of child GameObjects in Unity and how to create them.
What Is a Child in Unity?
Unity is a program built on organized hierarchies, and children are GameObjects within the hierarchy. Children are contained within parents and are subject to the positioning, rotation, and scale of the parent, among other things. Once a child is created, that GameObject is in large part governed by its parent.
Take the picture below as an example. There are two cylindrical GameObjects. On the hierarchy to the left, the child is listed beneath the parent. The larger cylinder is the parent, while the smaller is the child.
Any changes made to the parent will be automatically passed on to the child. So if we mess with some of the settings . . . for example, the rotation, scale, and position . . .
. . . those changes will be reflected in the child as well. When the parent was resized and repositioned, the child followed suit - though it maintained the same positioning relative to the parent. The child is essentially a slave to the parent, and outside forces that affect the parent will also affect the child.
Parent GameObjects can have as many children as you want. It's possible for every GameObject in your game to be a child to a single parent GameObject, with branching parents moving down from there. Children can also be parents of their own accord, moving down as many branches of hierarchy as you like - though bear in mind that every child GameObject is subject to changes in their parents. If a parent is destroyed or deleted, every child beneath it goes too.
Parent GameObjects, by contrast, are not subject to changes in their children, and you can manipulate child objects without moving, reshaping, rescaling, or destroying their parent.
How Are Parents and Children Used in Unity?
There are many uses for the child and parent dynamic in Unity. Here are some of the more common ones:
- For simple organizational purposes. If your game has a UI, for example, you will probably stack all of that UI's elements together so they're easy to find. This also helps declutter Unity's hierarchy, as you can collapse the lists of child objects.
- For easy, mass-scale changes. Taking the UI from the last example, assume you decide that you want to make the whole thing a bit bigger. Or smaller. Or maybe you want to shift it around a bit. Or maybe disable it altogether in certain circumstances. By childing all of the UI's elements to a single parent, you can effect these changes easily by manipulating the parent rather than messing with the individual children.
- For keeping related objects together. Let's say that you have a character GameObject with changeable equipment. The equipment needs to go with the character when they move, and making every GameObject a child of the character's GameObject will keep them relative to the character as they shift around the screen. You'll also need to child GameObjects to the parent for animation purposes.
- For spawning new objects from specific locations. Assume that your character has a gun that fires bullets. Those bullets need to spawn from the gun or perhaps from an invisible GameObject at the end of the barrel. Childing the spawn point to your parent character will result in the bullets flying from their intended point, rather than some random spot on the screen. (Though bear in mind that said bullets should not be made children of the gun, as they will move wherever your character moves.)
Unless you're dealing with a very simple game, you will likely need to child GameObjects to a parent on a regular basis. So how is this done? There are a few different ways.
1. Drag and Drop
The simplest method of creating a child is to use Unity's hierarchy on the left side of the screen. Click on a GameObject and drag it to another GameObject. Doing this will create a tiered hierarchy, turning the dragged object into a child. Piece of cake. You can continue to add children to the original parent, or to the other children, as much as you like. Dragging the child to a blank space on the hierarchy will remove its child status.
This method is no use during runtime, of course, which means further childing will require a bit of a dive into C#.
2. Instantiate as Child
The second method for childing a GameObject requires a common Unity method known as Instantiation. When you Instantiate a GameObject you're creating an instance of it in the game, and in this case, placing the instance as a child of an existing parent object.
This time you want to use the Instantiate() method and set the parent's Transform as the parent, like so:
Here we have two GameObjects - the exampleParent (a pink block), already active in the game, and the exampleChild (a squat character), found in the project files - attached to an invisible GameObject. When the player hits the J key, the game will Instantiate a copy of the exampleChild GameObject at the same coordinates as the exampleParent's transform. So this . . .
. . . becomes this.
Every time you hit the J key in this example, it will add another instance of exampleChild to exampleParent, as a child, in the exact center of exampleParent's Transform. If the exact center isn't desirable, you can also throw in a Vector to change the child's initial coordinates, like so:
The '+2' thereby moves the new Instance of exampleChild off to the right of exampleParent. You can add similar calculations to the other numbers in the Vector for different results. (Though you absolutely should not use raw numbers for these sorts of calculations. Variables that you can change in the Inspector are the way to go.)
3. Set as Child
This last method assumes that you want to turn an existing object into a child of another object. It's nice and simple.
All you need to do is make sure the would-be child goes first in this method and the parent second. If this is done correctly, the first GameObject will be shifted under the second in the hierarchy. (You can use a similar method to remove a child from a GameObject, as well, though that's a more complicated process for another article.) This does not change the child's Transform, though any subsequent changes to the parent will affect the child.
It's worth noting that the parent-child relationship in this case only lasts during runtime. The parent will no longer have a child once you shut down the game and return to the Inspector.
Important Note About Children
Normally in Unity a GameObject's Transform reflects its World Position. If you change the object's x position from a 0 to a 1, therefore, it will move a little bit to the right. This is predictable enough and usually what you want when moving GameObjects around in the Inspector.
When you make a GameObject into a child, however, its stats in the Inspector change, reflecting its Local Position. Local Position uses the object's parent for determining numbers rather than that of the world at large. So if, for example, the parent was at an x coordinate of 2, and its child was also at an x coordinate of 2, they would not be in the same position.
Instead, the child would be to the right of the parent, two units away. Sounds simple enough, but you'd be surprised how easy it is to get confused when dealing with the position of children in relation to both their parents and the rest of the game world. Rotation is especially confusing in this regard.
Having trouble with coordinates on your children? One of the easiest ways to fix problems is to remove the child from its parent in the Inspector. This will change its Transform values back into its World Position and give you a better sense of where the child is in space. Mess with the values outside of the parent and then restore the pairing when you're satisfied with the results.
This content is accurate and true to the best of the author’s knowledge and is not meant to substitute for formal and individualized advice from a qualified professional.