I encapsulated Physics and Graphics with ECS successfully.
Here is a simplified version :-
Physics Rigid Body = Physic_MassAndInertia + Physic_Transform + Physic_Shape
Graphic Polygon Body = Graphic_Transform + Graphic_Mesh
I usually set their transform via :-
findService<Service_PhysicTransform>()->setPosition(physicEntity);
findService<Service_GraphicTransform>()->setPosition(graphicEntity);
It works so nice, and there is no problem in practice, because I always know its "type" (physic/graphic).
However, I notice that Physic_Transform and Graphic_Transfrom are very similar and duplicate.
For the sake of good practice and maintainability, I consider to group them into Generic_Transform.
findService<Service_Transform>()->setPosition(anyEntity); //cool
However, there is a little difficulty. The physic transformation is quite complex for a child inside a compound body.
Assume that a physic body B is a child of a compound body C. In this case, B's transformation component currently has no meaning (by design).
If I want to set the child transformation setTransformation(B,(x,y,45deg)), my current physic engine will not set the B's transformation directly - it will set C's transformation that make B's position match (x,y,45deg).
Thus, it is not so practical to group them, except I code it like (ugly and worse performance):-
class Service_Transform{
public: void setPosition(Entity B,Vec2 pos){
bool checkIsPhysic = .... //check if B is physic
if(checkIsPhysic){//physic
Entity compound = .... //find C
ComponentPtr<Transform> cCompound = compound.get<Transform>();
cCompound->pos=pos*someValue; //calculate some transformation for C
}else{//graphic
ComponentPtr<Transform> cTransform=B.get<Transform>();
cTransform->pos=pos;
}
}
}
Should I group them into 1 type of component?
I probably should not group them because its meaning and related implementation are very different, but I feel guilty ... I may miss something.
Advice about other things are also appreciated. Thanks.
Edit: Hmm... I start to think that grouping component is OK, but I should still use 2 function (from different service/system).
↧