Show Posts
1
Graphics / sf::Sprite in a component-based system
« on: May 10, 2014, 09:47:58 pm »
Hi,
first post. *waves*
I've been reading some blog-posts on how to implement component-based entity systems. I like the concept, especially since I toyed with a similar, though much more flawed, inheritance-based idea.
However, there's a slight problem I'm not sure how to deal with;
Every entity needs a position, but not every entity needs to be drawn/drawable. Therefore, I would like to encapsulate the latter into a component that I can add to an entity, should it have to be rendered. Sure, I could just add a Sprite to the component but as I said, the position should be defined in the entity. Adding a Sprite, therefore having two positions, seems redundant. In addition to that, I'd have to write extra code just to synchronize them. Add a physics component and it becomes even more messy, requiring the Sprite to know about the changes that just occured in the entity - only to keep itself in sync.
Any Ideas?
first post. *waves*
I've been reading some blog-posts on how to implement component-based entity systems. I like the concept, especially since I toyed with a similar, though much more flawed, inheritance-based idea.
However, there's a slight problem I'm not sure how to deal with;
Every entity needs a position, but not every entity needs to be drawn/drawable. Therefore, I would like to encapsulate the latter into a component that I can add to an entity, should it have to be rendered. Sure, I could just add a Sprite to the component but as I said, the position should be defined in the entity. Adding a Sprite, therefore having two positions, seems redundant. In addition to that, I'd have to write extra code just to synchronize them. Add a physics component and it becomes even more messy, requiring the Sprite to know about the changes that just occured in the entity - only to keep itself in sync.
Any Ideas?