From what you are saying, you may not be applying separation of concerns here. In classic inheritance OOP you are led to see behavior and properties as parts a of a whole, an “Object”.
I think a better name for “BombComponent” would instead be “ExplodesComponent”, by which I mean that this component is only concerned with providing information for the bullet to explode on impact through BulletSystem.bulletImpact().
The Bomb component should NOT be concerned whatsoever with the handling of a model or updating a projectile. For that purpose you should consider a ModelComponent and/or OnRenderStepped Component.
I think this could be a good watch to unlearn inheritance based thinking into more data-oriented ECS architectural thinking
That’s exactly what I’m talking about. If I’m updating the model within the ProjectileComponent (or where model getting updated) and adding different statements for each unique situation/type, it will lead to a lot of lines of code in the projectile system, especially with so many different bullet types (bomb, bullet, laser, etc.).
It is true that in this architecture situations where you have to use if else chains ocurr frequently, but with proper separation of concerns you shouldn’t have a long if else chain.
For example, if you already have a Hitscan component, then a Laser component would only need to contain fields relating to the color of the laser, that is then rendered/updated through a separate system that could be called RenderSystem that should be completely disconnected from the logic of BulletSystem. This system would then create a beam object and etc.
Same thing with projectiles, they should be handled by RenderSystem that may create/update a model only if they contain a ModelComponent, and so on.
Which limitations? It pretty much expands on the current inheritance system and adds more features, and it’s pretty stable so far. I don’t think you should judge it from the cover. Though ECS really might solve your problem better.
