The reasons behind Unity3D engine design (game object/transform component)

I'm trying to understand the reasoning behind Unity3D engine design and this is something I can't get my head around yet: why is transform data stored in a separate component, instead of being a part of GameObject, like name, layer masks and tags? It cannot be removed like all of the other components anyway, there are no alternatives and thus no need for it to be removed.

• To me this sounds like this sounds like architecture legacy. Maybe this transform component used to be a regular, optional, component, so you could have objects "out" of the Cartesian space. Then some implementation constraint (an optimization?) required that this component was always present, and it stayed this way. But that's just supposition, it would take an engineer from Unity to answer that question for real. – Laurent Couvidou Aug 31 '12 at 9:04

Only the Unity developers can give their true motivation for this design, but one argument in support of doing it this way is that there is an argument that each class in a software project should handle one and only one responsibility. The GameObject is a named collection of Components, and adding position/rotation/etc to that means it would have 2 responsibilities. The Transform component handles position and rotation and therefore shouldn't also be responsible for naming or aggregating other (potentially unrelated) components. So it makes sense for these 2 concepts to exist in 2 separate objects.

More generally, this question asks "if there is a 1 to 1 relationship between X and Y, why is Y not part of X or vice versa?" And the general answer is that software is easier to develop and maintain when broken up into smaller self-contained parts, even if 2 parts always work together in conjunction.

• I considered that too but they could've moved GameObject filtering (layers, tags) to a separate component because of the same reason - and yet they didn't. Furthermore, the transform component is tied too deep in the system by holding hierarchy data (parent, children etc.). – snake5 Aug 31 '12 at 10:20
• It could be argued that the layers and tags are a form of naming, should live alongside the name, and so are an intrinsic part of what constitutes a collection of components in the system. As for transforms holding the parenting, you have a point, but nobody claimed the Unity system is perfect. If it was my system, I'd keep Transforms separate, and relocate the parent/children to the GameObject. – Kylotan Aug 31 '12 at 11:10

Transform is a mandatory component in Unity.

The reason why a transform is a mandatory component is that game objects are located in a scene and therefor needs spatial information (position, orientation and scale) about that object. (This information is not always used, but keeping the transform component mandatory keeps things a bit more simple).

• The question isn't about what component based design is. It's about why "transform" isn't a component as well – bummzack Aug 31 '12 at 8:10
• But Transform is a component in Unity! docs.unity3d.com/Documentation/ScriptReference/Transform.html . The only strange thing about transform is that it is a mandatory Component for GameObject. – Mortennobel Aug 31 '12 at 8:17
• Well I guess then the question is about why you can't remove it? The OP wouldn't have tagged his question "component-based" if he wasn't familiar with the term. – bummzack Aug 31 '12 at 8:21
• You are right - thanks. I have updated the answer to better answer the question. – Mortennobel Aug 31 '12 at 8:29
• The question is about why transform data is a separate component (as opposed to plain data inside GameObject like name, layer masks, tags). I tried to make it more clear in the latest revision of my post. – snake5 Aug 31 '12 at 8:39

The TransformComponent is the most difficult Component to properly design in video game architecture. Almost every other Component needs to know about a given GameObject's position, rotation, or scale, so properly decoupling all of these interrelated systems is inherently difficult.

There will always be tradeoffs in architecture. By having TransformComponent be static (i.e. not dynamic), developers at Unity can write code under this assumption. I would assume this makes things much easier on their side without adding much of an inconvenience on our side. This is akin to an object-oriented paradigm, where GameObject would extend some abstract class, Transformable.