Transform components in ECS

Question

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?

Answer 1

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.

I can't think of any particularly strong reason to have separate 2D and 3D transforms. No engine I've used in any significant capacity has done that. 2D is a clean subset of 3D so you can readily reuse the 3D transform for 2D purposes. The few possible reasons I can think of for separating these are vastly outweighed by the complexity of an engine needing to support both.