1
\$\begingroup\$

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?
|improve this question
\$\endgroup\$
  • \$\begingroup\$ 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). \$\endgroup\$ – Draco18s Jan 20 '16 at 21:42
  • \$\begingroup\$ @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? \$\endgroup\$ – artganify Jan 20 '16 at 21:52
  • \$\begingroup\$ 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? \$\endgroup\$ – Draco18s Jan 20 '16 at 21:55
3
\$\begingroup\$

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.

|improve this answer
\$\endgroup\$
  • 2
    \$\begingroup\$ Unity is one example that separates, or at least specializes, 2D transforms vs 3D. The reason is that their RectTransform is designed for UI layout, and so has notions of anchoring and scaling relative to a parent (for flexible UI that adapts to different display/container resolutions) that don't have a common analogue in 3D. One can also use non-UI sprites to make a fully 2D game with the regular 3D transforms as you describe though - the UI specialized version is optional. \$\endgroup\$ – DMGregory♦ Jan 21 '16 at 0:24
  • \$\begingroup\$ @DMGregory: aah, good point. I didn't really think of that as a separate type of transform I guess. :) \$\endgroup\$ – Sean Middleditch Jan 21 '16 at 0:53

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.