[I understand that this this could be seen as a rather theoretical question, but I think it has real-application impact].
With a component-based design one wants to get rid of the long inheritance chains known in larger games ("deadly diamond of death"). So we create a
BaseComponent class that handles all the administrative chores (ID and type handling, possibly a generic list of properties, ...).
Now each actual
Componentshould inherit from that base [start of academic/dogmatic flair] and only that base [end].
Assume I have three components with different attributes:
Person: age, name, gender, isTired, isSick, ...
Guest: satisfaction, desires, ...
Employee: current duty, shift end, ...
Now in traditional OOP design,
Person would act as the base class for the other two. As I currently "forbid" that type of inheritance for the components in my project, everytime I am e.g. processing my employees and checking/updating their state attributes I have to either use some helper function to access the sibling component
Person (if it exists) or send a message out that hopefully
Person will be registered for and will process. Or I can simply assume that each
Employee always will have the component Person. But then I might as well let those two components inherit from
Person, so they for example both have the member functions to manipulate some specific properties.
Note: There will never be an
Entity that has the component
Employee, but not component
Person (same applies to
Guest). They are a fix requirement, which is why I am considering inheritance here at all.
Question: My question is now whether anyone can see any real-life problems that would be introduced by (re-)incorporating a bit of inheritance into my components other than to a degree violating the original base/dogmatic concept and the risk that (if used excessively) I would end up with the exact same problem the component-based design tried to solve in the first place?
Thread that ultimately led my to asking that question, showing such inheritance.