- Home /
Why do Transform have hierarchies and not GameObjects?
I have a conceptual question, why does a Transform have a hierarchy (with children), but a GameObject doesn't? If I have a Capsule, with a Cube as a child -- so that when I drag the Capsule, the Cube tags along -- it seems more natural to think that the relationship is between Capsule and Cube (2 physical-ish objects), not Transform and Transform (2 mathematical concepts).
Any enlightenment would be greatly appreciated.
Answer by Statement · Mar 22, 2011 at 02:23 AM
The GameObject act mostly as a container for components (such as the transform, or a renderer). It is the components that give shape to the game behaviour, not the game objects themselves really. While Unity requires each game object to have a transform component for some reasons, imagine a game that used this architecture might not require it. It would be a strange design decision to have the game object know about parents and children if they aren't needed (I can imagine having a component based design for a text mud game where parenting stuff might not be that useful). Parenting belongs to the transform (the position etc of objects) since it uses this information to calculate the position from local coordinate systems. Think of it, it becomes almost about useless to parent things unless you consider their position.
A game object is about as void as it can get. It is just a container for components. It is the components that are attached to it that make them "physical". The transform describe where an object is. A renderer makes use of a mesh filter to render the mesh at the position derived from the transform. A collider component describes its collision properties and a rigidbody makes use of the collider and transform to generate physical movement. All of the components then work in harmony, doing their job and their job alone.
A lil off topic:
If you were to create your own very basic component model game from scratch you'd probably get to the same conclusions. I have toyed about trying to "improve" (Well, in ways I thought unity lacked) this architecture but I came to realize that things are the way they are for a good reason. For one, even such a silly thing that having public member variables camelCased instead of PascalCased proved to be a good approach since it resolves the ambiguity of accessing member variables vs accessing class variables. You also get to appreciate that the transform deal with the parenting code and not have it hard coded into the game object. But I agree it could just as well be included in the interface of the game object since you can't create a game object without a transform in the approach Unity favor. Unity was meant to be a 3d game engine so it's a quite central piece to have. But boy, would I want to trade it for a transform2d sometimes when making 2d games... :)
Thanks for your response, it has helped me better understand my question!
$$anonymous$$aybe it's just the name GameObject that is throwing me off. The closest analogy I can think of is a GUI, with views containing subviews, and each view having its own bounds (location, width and height) relative to its superview. Each view would know its parent, and its subviews.
But here, you have GameObjects (Views) and Transforms (Bounds), but it is the Transforms that know about their parent and children, not the GameObjects. To me that seems counterintuitive.
I think, in all essence a GameObject can be boiled down to a List or something similar. Sure, it adds a name, tag, layers also that are shared between all components that are on it. To me, a GameObject isn't really anything at all. It isn't even a point in space, let alone any physical form. It is a collection of components. They use the GameObject to look for other components in the same group. Perhaps the name GameObject throw many people off, but any of the components by themselves don't do much since they depend on each other. The GameObject is the hub that bind those together.
I guess the name is growing on me ... it is an interesting approach, to use a containment hierarchy rather than just subclass GameObject to get specialized features. I wonder why Unity took that approach?
Subclassing has many flaws which you'll know if you start to study software design. I won't go into the analogies but often the relationship between logics are has-a (composition) rather than is-a (subclassing). You'd be surprised how extremely flexible software you can achieve with composition over inheritence. If you want to get started thinking along these terms I can highly recommend the book Head First - Design Patterns, where they present not only patterns but a new way of thinking if you're doing heavy inheritance. This book has leveled me up by far more than any other book.
Just google "composition over inheritance" to find some interesting topics on the net. http://stackoverflow.com/questions/49002/prefer-composition-over-inheritance
Answer by yoyo · Mar 22, 2011 at 01:50 AM
A transform is a scale/rotate/translate operation. When one object is attached to another, it is "transformed" by its parent -- its own (local) scale/rotate/translate is combined with that of its parent. The chain of operations that transforms a specific object is actually the chain of transforms of its ancestors.
Your answer
Follow this Question
Related Questions
Parenting from code doesn't really change the hierarchy 1 Answer
Parent mesh problem 0 Answers
Translate.transform problems (collision/Rigibody) 0 Answers
"Transform" still trying to access after Destroy 0 Answers
What is the order of execution for the instantiated object's GetComponent.Script.DoSomething? 1 Answer