I was thinking about this for the past week but every idea I have seem to have a big problem with it

First I thought about making every entity have a parent even if the parent is just an empty point in the origin, needless to say why was this a bad idea, it'd require extra 4 bytes (because of the parent ID) for every entity

Second I thought about making a parent component, But the problem with this is the amount of sub subroutines I'll have, take this example

for(every entity)
{
	if(entity.hasparent)
	{
		Draw(entity.position + entity.parent.position, entity.size);
	}else
	{
		Draw(entity.position, entity.size);
	}
}

it just feels like bad design and that's without including the really complex part of rotations

also what if the child is a parent of an another entity this way I'd need to get the position of its father and the father of its father

I feel extremely lost at this point, Do you know anything that can help me ?

alabdaly891 said:
First I thought about making every entity have a parent even if the parent is just an empty point in the origin

There are many kinds of “parent/child” relationships.

Here, you are talking specifically about a transform parent. The point of a transform parent is that, if you move/rotate the parent, the child goes with it – the child position is naturally expressed in the reference frame of the parent, so it is “local” to the parent.

I've seen a lot of scene graphs that have tried to jam this concept through everything, and ended up confusing relationship to the point where “when I place a coffee cup on a table, it inherits the wood grain of the table,” which makes no sense. Even inheriting the position from the table is quite tenuous if the position of the cup is physically simulated. The first cat that comes around will knock it off! So, there's a friction/gravity-based relationship between cup/table, but there's not really a position-parenting relationship.

The abstraction that ends up working okay in almost all scene graphs / engines I've seen, is that every object CAN have a parent, and that's probably just a pointer from the entity to another entity. You could also separate out “having position,” because maybe there are entities that don't have position, and thus every position-component CAN have a parent, which would be a position-component attached to some other entity. But, when there's no parent, the position is in global space.

Separating out parentage itself into another component just for that, makes no sense, because there will be many different kinds of parentage – your game is a graph, not a tree.

Also consider that not everything that has a position is an entity. Each bone in an animated character is not its own entity, but it is a possible attachment point for other entities. And each particle in a particle system is not an entity, but it is something that might want to collide against the world. If you want to attach swords to hand bones, it may be enough to say that a TransformComponent can have a parent, and a bone is a TransformComponent (perhaps a special BoneTransformComponent instance.) But if you also want to attach things to particles, you may need to go all fancy and say “things with position” which may not even be components, and then use some kind of flyweight/delegated approach to be able to have a “position” expressed as “the location of particle 138 in that particle system over there” without inserting itself on the inside of said particle system.