If you’re going with OOP then ask yourself about the IS A or the HAS A relationship.
For example, a Banana IS A Fruit, therefore extend the Fruit class to make a Banana class. A BananaTree HAS A Banana, therefore the BananaTree class will have the Banana class as a component.
So the question is, is the Knight a sprite or does a Knight have a sprite?
If the Knight is a sprite then extend the sprite class. If the Knight has a sprite then make the sprite a component of the Knight.
It sounds to me like you’re making a Character. A Knight is a Character and a Character has a Sprite. So, this is probably what you want:
`
class Character
{
Sprite *mSprite;
int mHitPoints;
int mHealth;
// Other things that a character might have or do.
};
class Knight : public Character
{
HeavyArmor mHeavyArmor;
// Other things that are specific or special about a Knight.
};
`
Then keep a pointer to all of your Characters in an array so you have immediate access to them and can reuse them if needed.
I always take the ‘Knight has a Sprite’ principal.
Knight would inherit from a ‘GameEntity’ class, which itself has a Sprite property.
That allows me to model my world (however I choose) and position Knights within it.
If a knight wears a helmet and carries a sword, then the Knight class might have two properties (more likely a collection property) of a Sword class and a Helmet class - each of which inherit from the GameEntity class.
A GameEntity is responsible for the modelling of a single ‘thing’ in the game (Knight, Helmet, Sword).
When I want to draw the entities, I use the Sprite contained within them.
Using this method keeps responsibility for the game separate from the displaying of the game - so SRP is alive and well, and somewhat follows the MVC pattern, wherein I Model the world, have a View of the world (containing sprites) and have a Controller to control the world.
Incidentally, I also steer clear of using PhysicsSprites for the same reason - I keep the physics logic at the model level, then render the model in the view.