# Transform components in ECS

Many game engines I've seen which are based on an Entity Component System. It has some kind of a Transform Component as a necessary component attached to all of their entities. While this does seem to make kind of sense considering an entity is only some kind of property bag and a collection of components and transformations are world space behavior (hence just part of the composition). I've noticed two other things which are very weird:

• Transform components are used to build up the hierarchy between entities as they have a parent entity as well as child entities

• Transform components are specialized for only a single kind of world space, e.g. 2D or 3D.

Examples:

• The Unity3D engine. Entity children and parents seem to be accessed through the Transform Component of each entity. Also, the Transform Component features coordinates in 3D vectors.

• The Xenko Game Engine (previously Paradox3D), which can bee seen on GitHub.

So, is this a common practice? Best/worst practice? What's the reason behind having:

1. a fixed Transform component,
2. making the Transform component only suitable for one world space
3. using the Transform component as an hierarchy graph?
• AFAIK this is pretty common. I haven't yet managed to figure out what kind of entity doesn't have a Transform component of some variety and it makes sense that it would be the transform which has children/parents, as that hierarchical relationship is spatially based (every transforms' global position is effected by the transforms of all of its parents). – Draco18s no longer trusts SE Jan 20 '16 at 21:42
• @Draco18s Wouldn't it make more sense to e.g. create an "EntityGroup" entity (or directly make grouping part of entites) and for transformations create a basic Entity2D and Entity3D which respects the world space? – artganify Jan 20 '16 at 21:52
• That depends on how you plan to handle scaling and rotation of parent/child groups. Consider: a top-most object with 30 degrees of rotation around Y, scaled (2,1,0.5) with a child scaled (1,3,2) and offset from the parent by (2,2,2) with a child of its own offset (-1,-1,-1). What is the global position of the second child? – Draco18s no longer trusts SE Jan 20 '16 at 21:55

The TransformComponent idiom is common in most component-based engines, not just ECS engines (note that with Unity there are no "Systems" related to MonoBehavior objects, so it's not really an ECS, at least in the C# portion).
A lot of engines literally do hardcode the existence of the TransformComponent and make the transform built in to the core GameObject ("Entity") objects. There is not a strong industry preference one way or the other in my experience; I've heard well-reasoned but non-definitive arguments for both approaches. True ECS architectures of course must have a separate TransformComponent as there isn't any actual Entity object in which to hardcode such a component.
Game object hierarchies do tend to be built into the concept of a TransformComponent. The primary gameplay use of the object hierarchy is specifically for the transform hierarchy. It's thus most convenient to reuse the idea of the transform hierarchy if you need object organization. This can seem wasteful in some engines where "global" objects are frequently used for non-spatial background systems (this is common in Unity for example) but isn't really a big deal.