Parenting of SpaceComponent

[Noofbiz]

Suggested by @juztme87.

Make SpaceComponents have references to any parent / child components, like a Node. This would be useful for collision detection.

One question I have about implementation is how would it work in practice? Is the position relative to the parent, i.e if I have a parent positioned at (100, 100) and position the child at (100, 100) would the child appear on the screen at (200, 200)? Also, is there inheritance? Does the child by default have the same properties as the parent or does it default to zero?

[juztme87]

This issue is related to #556

Some example use cases:

1. A Tank has a Turret.
   This Turret needs to be able to rotate independently but the position and rotation should be relative to the parent.

2. A Unit has a health bar.
   The health bar is located 10px above the Unit.
   The position should be relative to the parent but the rotation should be fixed.
   (The position of the child shouldn't be affected by the Rotation of the parent)

Maybe there are some other use cases that require inheritance.

[jonbonazza]

@Noofbiz this is a fairly common paradigm in game engines and pretty much every major game engine has this concept. The way it works rather universally, is that child enities are transformed in relation to their parent entity. So as an example,
if EntityA was at position 100, 100 and Entity B was a child of EntityB and had position 100, 100, it would actually be rendered at global position 200, 200. Generally, most systems expose two types of T/R/S, a local one (100, 100 in this example) and a global one (200, 200 in this example). This is important because sometimes, it's necessary to know the relative or local position, while other times it's important to know the global or world position, depending on what you are trying to do.

[Noofbiz]

I agree, I'm only stuck on the implementation. We could either make space components themselves do this by unexporting Point and using Get/Set methods for position. This would allow us to do it all internally, but will change the API for space components quite a bit. Another solution would be to have a SpaceParentSystem or something that does it separately as its own system. This has the advantage of not needing to change the current API, but seems clunkier to me.

[jonbonazza]

I'd prefer the former approach personally, but as you said it does break backwards compatibility.

That said, there are a couple other backwards incompatible changes id like to make too, so maybe after 1.1 is out, we can get together and start thinking about 2.0

[diwant]

I'm implementing the latter. I can share the code as a gist or a PR.

[Asday]

as you said it does break backwards compatibility

I personally don't think this is a gigantic issue for a clean implementation of a core feature.

[Noofbiz]

A PR would be pretty great, and the changes shouldn't be too bad now with go modules. We can just make sure to release a version before so anyone who needs to can check out that one. And it'll definitely need be updated for version 2.0 anyway, and it is a pretty useful feature.

[diwant]

I've put up a PR here with my latest draft. The math is wrong and I am not seeing expected behavior for heirarchical transformations yet. Would love a second set of eyes on this, perhaps you can see what I'm missing?

#705

[diwant]

This gist shows how entities might be added to this TreeNodeSystem:
https://gist.github.com/diwant/11b05a3908028ed60377ec6a3ae2c025

In this example, if I run code to increase the LocRot value of the starHandle, it doesn't orbit the moon. It orbits a much larger circle than that, which is not the expected behavior (I'd like the star to orbit the moon.

[Noofbiz]

ecs.BasicEntity has a parent/child tree node now, and I've added a demo called parenting that shows how to do this for any component, not just space ^_^!