Can’t believe you have not put this function into the API. How many time do you need to get a child gameObject.
In actionscript or javascript you just reference it with a dot eg. parentObject.childObject
but there is no simple way in Unity.
Just add a function getChildObjectByName(string s) and then all will be forgiven. Take this chance while making Unity 4.6 and Unity 5 to make things nice again for developers.
It’d be nice, but you can easily do the same thing with a handy extension method:
using UnityEngine;
namespace ExtensionMethods
{
public static class MyExtensions
{
public static Transform GetChildByName(this Transform trans, string nameToSearchFor)
{
foreach( Transform child in trans ) {
if( child.gameObject.name == nameToSearchFor ) return child;
}
return null;
}
}
}
So why can’t Unity put that in? Then people would be able to pick up programming in Unity much quicker. Seems like such a simple thing for them to do. Instead of spending the first few hours getting frustrated and searching the forums to find the above code! Also they could optimise it much better than above.
Transform.Find already exists.
–Eric
Doh. 
Well a few things here…
One. How come two people above didn’t know about this? It should be in big letters on the first page of the Unity website as its so important.
Two. Why can’t there also be a helper function just on the gameObject instead of having to go through the transform.
Three. The word “Find” does not fill me with confidence that this is an optimized function. It suggests some sort of Google search on the child members. “Get” would better.
Four. How have I been using Unity foe two years without knowing about this function?
Five. Where is the tutorial to Unity that explains this that all new users of Unity have seen?
Six. How is someone supposed to guess that to find a child gameObject you have to call a function on a transform object to find gameObjects? It makes no sense whatsoever.
Thanks.
It really doesn’t seem like a big deal; if it was, there would be way more topics about this, but it’s a non-issue for most people. I suspect that most people just type “find” in the documentation search function, and there it is. It makes perfect sense that you’d use Transform.Find for children, since you use Transform.parent to set parents. All parent/child stuff is through transforms. Not GameObjects, which have no concept of parent/child.
–Eric
The reason why I say it doesn’t make sense is that the “name” applies to the gameObject presumably whereas Find you would presume would find child transforms not child gameObjects. But anyway.
But anyway, I think it is a big issue. Because the first thing you want to do when you learn Unity is you have a reference to an object and you want to find a reference to it’s child or parent. Most people learning Unity will spend about 1-2 hours figuring this out, searching forums. I guarantee it. These 1-2 hours will give people a negative first impression of Unity and make them think it is very complicated.
Whereas for example you learn Flash programming with Actionscript and you guess myParent.myChild or myParent[“myChild”] and it works! And your happy! And you have a good impression of Flash and how easy it is.
Give someone Unity for the first time and tell them get the child of this object and they won’t have a clue.
But… it’s easy to fix with two helper functions: gameObject.getParent() and gameObject.getChild(string). I just don’t get why Unity don’t put these in as standard? I mean instead to get a parent gameObject is myObject.transform.parent.gameObject which is just silly. Are you trying to wear out our fingers typing?
In my opinion it would make new users very much more likely to have an enjoyable first experience of Unity. Just trying to help.
To be fair, I’ve used Transform.Find before, but I haven’t in so long that I’d totally forgotten about it. Since the name of a GameObject is unreliable (could be changed), its utility in code is pretty niche.
Transform is clearly where all the hierarchical functions belong. I don’t know if duplicating functionality between GameObject and Transform is desirable. Why not just plop in your own little extension method as above? It solves your issue, and if the issue was really a problem for as many users as you suggest, then I feel like there’d be more complaints, in this thread or anywhere else.
Exactly my point. I’d say 99% of developers make an extension method to do this. So clearly it should be in the API to start with. Also to say a gameObject doesn’t have a parent is untrue. It’s parent is gameObject.transform.parent.gameObject. It’s just semantics to say otherwise. If we just DEFINE the parent of a gameObject to be gameObject.transform.parent.gameObject then that solves that issue.
Sometimes I don’t get the answers to these things. It’s like saying this skyscraper doesn’t need a lift/elevator it’s got stairs. Why duplicate the functionality? Well, to make life easier of course. Perhaps it would take away from the “purity” of the skyscraper also having an elevator but, you know, sometimes that’s a good thing.
So that’s my suggestion for Unity if they want to make life easier for developers. Please add these helper methods!
I can’t imagine why anyone would search for hours, when they could just type “unity find child by name” in google, and get an answer within seconds. As Marble said, if this was such a huge issue, why has it never come up before?
Making hacks to make things “easier” always backfires, and is never a good thing. It just makes things more confusing. For example, in Unity 5 they’re getting rid of the “elevators” that are the component shortcuts. Instead you can only use the “stairs” of GetComponent. Perhaps this appears slightly more difficult at first, but in reality it makes things more consistent and removes confusion (and helps improves some other functionality in the engine).
–Eric
I think the bigger question is why is parenting part of Transform in the first place? They should have made it gameObject.parent, gameObject.Find(), gameObject.GetChild(). Make parenting a GameObject concept, not Transform.
I didn’t find gameobject.transform.Find() logical either and expected a gameobject.Find(). Only on 2nd thought it makes sense that children can be attached to transforms only, and therefore you must grab this component first. But it isn’t clear on the first place.
It’s not that important. I’ve got a very large project codebase and I can think of maybe three places where I use it. Looking up objects by name is fragile; it’s much more reliable to look them up by component, or pre-wire them in the Inspector.
That would violate the SRP, and it’d be confusing to have a method dealing with children on GameObject when all the other parent/child stuff is in Transform.
But Transform.Find is some sort of Google search on the child members. It loops over all the children and compares the names. It’s not fast (compared to, say, pre-wiring things in the Inspector).
This seems to contradict your own first point?
Someone from the Learn team would have to answer this, but my guess is that we don’t teach it because it’s not a good approach compared to using GetComponent or inspector-wireup methods.
Well the consequences of the parent/child relationship only really affect the transform, no? As in, the fact that something is a child of something else means its position, rotation and scale will be affected by the parent, and that’s really all the relationship does.
You’ve just contradicted yourself here. If you type this into Google you get lots of posts in forums asking how to find the child by name!
I don’t see how adding gameObject.getParent() to return gameObject.transform.parent.gameObject is a hack? It’s a useful function. That’s what it is. And no, it would confuse no-one. As an example should we ban the word “nephew” as it duplicates the sentence “brother’s son”? Wouldn’t want to violate the SRP! OMG!
If people want it then it’s a good thing. (Like the start menu in windows although it duplicated functionality).
Anyway I’ve just realised that the Unity developers don’t read these threads only the moderators who are independent of Unity and so don’t report back to them. So essentially this is talking into thin air.
Actually one of the things which annoyed me right when learning the engine:
One the one hand they do like: “We are so user-friendly that we built in direct component accessors such as gameobject.audio, gameobject.animation etc.” and on the other hand they fail to implement much more useful accessors for e.g. finding object children.
And to be honest these “user-friendly” accessors confused me in the beginnings much more than a cleanly written-out “GetComponent(AudioSource)” statement. However all tutorials only used the accessors, and I asked myself multiple times “and the component accessor name should be guessed by chance, or what?”. It took some time to get around it, and it even buried the clean component-based structure of Unity. Things like this make one :facepalm and asking who is responsible for this? Of course dismissing such gimmicks would also dismiss a gimmick like gameobject.findChild().
But that’s the point: either you fill the engine with lots of these wanted convenience functions or you don’t. Obviously it’s better they don’t and keep it clean. I’m really glad, they changed it in Unity 5.
If you think it is a useful function, you can create your own extension method for it. Personally, I think it is not needed and as was already mentioned, searching a game object by name is rather fragile and not what I consider a good practice at all.
No contradiction…you get a few posts, from years ago. Clearly it’s not an issue for 99.9% of people.
–Eric
Everything in Unity is important to someone. I agree the Transform component takes extra precedence, but I remember when I started out with Unity years ago the first thing I read up on was on GameObjects and Transforms, and what they entail.
Because this could be extremely confusing. “Hmm, both a GameObject and a Transform can have a parent. Are they the same, or are they separate?” Unity is based around components → Parent/ child relationships belong to the Transform component → You can access an object’s parent or children through the Transform component. It really makes sense (within the Unity environment). Secondly, you can; just use @Marble 's extension method. =)
You don’t guess, you read the documentation. By that reasoning, I could ask:
Personally, I don’t like the ActionScript way, but I can image it being useful and fast, especially if you’re already familiar with it. But really, Flash isn’t Unity, and different environments call for different solutions.
Useful functions can still be hacks and vice versa, but that aside, it could definitely confuse some people.
Look at it this way. Say I have an AudioSource and I want to check if I can play the sound yet. I would need to type audioSource.clip.isReadyToPlay. However, an AudioSource can only ever have one AudioClip, so we could shorten that by duplicating the property so I can just type audioSource.isReadyToPlay. At first glance this might seem like a timesaver, but it has two unintended side-effects.
Now with a parent it gets even more confusing. Should a Rigidbody also hold a reference to the parent, as it’s also dependent on it? What about Colliders? Why A, but not B?
Except, as this thread shows, far from everyone wants this. =)
I think what’s confusing people is that the theoretical structure is this (no matter how it’s implemented under the hood):
parentObject <---------> parentTransform
| |
| |
childObject <---------> childTransform
The structure forms a square like this. (See “category theory”). Each object has a transform attached. And the parent of an object has the parent transform attached. Only 3 of the lines here have functions to get from one to the other.
The missing line is not “required” because by deleting this line you still have a structure you can navigate around. Even though you have to go through a convoluted route.
What has happened is Unity has exposed the implementation of the structure rather than the true mathematical structure. I like some above feel this is an error of judgement.
To say that gameObjects don’t have child objects is absurd seeing as this is how they are shown in the tree structure in the IDE.
I know why they did this, because it is quicker when combining transformations together. But I think it was a mistake to force this implementation on the developer without adding helper functions to complete the “fourth line” in this diagram.
(Wow, the things I spend time arguing about! 
)