Trying to understand poly

[rudiHammad]

hello,
I've been reading the crash course: https://github.com/skypjack/entt/blob/master/docs/md/poly.md
I am having some trouble understanding it with so many new things (at least for me since I many use registry, tags and other basics)
So before diving in to the crash course I want to ask if I am over-complicating things for what I actually need.
Basically I want to have a base class calle GameBox

struct GameBoxComponent
{
public:
    float           width;
    float           height;
    Color4B         color;
    Vec2 offset;

    GameBoxComponent(
        Vec2 size,
        Vec2 offset = {0, 0},
        Color4B color = Color4B(255, 0, 0, 255), int globalZOrder = 1, bool isVisible = false)
    {
        this->width = size.width;
        this->height = size.height;
        this->color = color;
        this->offset = offset;
       // ... more cod
    }
};

And all I want is to have inheriting from if specific gameBox component types like: hitBox, healthBox, patrolBox.
So they all share widht, height, color, etc... and implement their own stuff.

Not the issue is that, unless I am doing something wrong, with a classic OOP inheritance, this would not work with the derived component:

 for (auto [entity, gameBox, transform] : registry.view<GameBoxComponent, TransformComponent>().each())
 {
        gameBox.sprite->setPosition(transform.position.x, transform.position.y);
        gameBox.sprite->setScale(transform.scale.x, transform.scale.y);
 }

What I would like is that all components inheriting from GameBoxComponent would be properly set without having to pass them all to the registry.view, since they all are a GameBoxComponent type.
To achieve that should I go through the poly crash course?

thanks

[skypjack]

This kind of inheritance is exactly what components aim to replace in your project.
Similarly, you don't want an update all box-like components system. It would quickly become a mess. Instead, you usually want a health system, a hit box system, a patrol box system and so on.
So, yeah, I think you're over-complicating it a little. And although I do love poly, I don't think that's what you want here. 🙂

[rudiHammad]

Yes, I do have those systems. I have a health system, a collision box system, an impact system, and they all communicate with each other
using the dispatcher and tags sometimes. The thing is that in my design, I have different type of game boxes. For instance, the box
that collides with the tile map isn't necessarily the same than the health box. And also, the patrol system uses a patrol box to detect the player which is large and looks ahead. And they are all used in the corresponding system.
As I mentioned, those game boxes are similar but not the same in size or functionality, that's why I was thinking that if they had they same
base class, it would be cleaner. I ended up simply creating a component for each game box. I had a bit of code duplicated, but it's working fine.

[skypjack]

Until you don't want to iterate them all at once throught their base class, that's perfectly fine then.
In my own projects I favor composition in this case actually. Something like:

struct hitbox {
    rect_type area;
    // other data
};

Where rect_type is your base class (more or less, you have more data, but you get what I mean).
It's a matter of tastes. A non-virtual base used to share the design of a piece of information is also ok.