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

Filed under:
|
|

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

Related posts about XNA

Related posts about 2d