Sprite and Physics components or sub-components?
Posted
by
ashes999
on Game Development
See other posts from Game Development
or by ashes999
Published on 2012-12-14T12:52:26Z
Indexed on
2012/12/14
17:21 UTC
Read the original article
Hit count: 461
I'm taking my first dive into creating a very simple entity framework. The key concepts (classes) are:
Entity
(has 0+ components, can return components by type)SpriteEntity
(everything you need to draw on screen, including lighting info)PhysicsEntity
(velocity, acceleration, collision detection)
I started out with physics notions in my sprite component, and then later removed them to a sub-component. The separation of concerns makes sense; a sprite is enough information to draw anything (X, Y, width, height, lighting, etc.) and physics piggybacks (uses the parent sprite to get X/Y/W/H) while adding physics notions of velocity and collisions.
The problem is that I would like collisions to be on an entity level -- meaning "no matter what your representation is (be it sprites, text, or something else), collide against this entity." So I refactored and redirected collision handling from entities to sprite.physics
, while mapping and returning the right entity on physics collisions.
The problem is that writing code like this.GetComponent<SpriteComponent>().physics
is a violation of abstraction. Which made me think (this is the TLDR): should I keep physics as a separate component from sprites, or a sub-component, or something else? How should I share data and separate concerns?
© Game Development or respective owner