To keep this post as short as possible, I am using a composite design for all game objects, which all are either an instance of GameObject or of a direct descendant. I'm working on integrating box2d into my game currently, but projectiles have been stumping me a bit. Right now, projectiles are an instance of BaseProjectile which extends GameObject, and then an instance of ProjectilePhysicsComponent gets attached to them. When the game loads, I pre-cache x amount for each weapon depending on the rate of fire. This way, projectiles get treated like particles and are simply recycled once 'dead'. However, just the idea that a projectile is a game object, just feels off to me... It may make sense to call a rocket a game object, but simple "dumb" bullets that do little else but spawn at X location and move at a set velocity...but then, they do need to tell the colliding object about the collision (such as telling them how much damage should potentially be applied). I guess in the end, both the game object and base projectile classes, are relatively small objects.. but I'd still like to hear you're guys input on this. How are projectiles defined in your games?

Edit: as a side note, let's say my current design is fine.. I need a way to sync the states between the game object and physics body, but I don't want the physics component to have a bunch of methods such as "onFire", "onExpire" etc. Maybe the projectile class itself should know about the physics body? Hmm. Maybe it should be an exception to the composition pattern and not contain any components at all, other than maybe for drawing. Hmm.. definitely need some feedback here please!!

To keep this post as short as possible, I am using a composite design for all game objects, which all are either an instance of GameObject or of a direct descendant. I'm working on integrating box2d into my game currently, but projectiles have been stumping me a bit. Right now, projectiles are an instance of BaseProjectile which extends GameObject, and then an instance of ProjectilePhysicsComponent gets attached to them. When the game loads, I pre-cache x amount for each weapon depending on the rate of fire. This way, projectiles get treated like particles and are simply recycled once 'dead'. However, just the idea that a projectile is a game object, just feels off to me... It may make sense to call a rocket a game object, but simple "dumb" bullets that do little else but spawn at X location and move at a set velocity...but then, they do need to tell the colliding object about the collision (such as telling them how much damage should potentially be applied). I guess in the end, both the game object and base projectile classes, are relatively small objects.. but I'd still like to hear you're guys input on this. How are projectiles defined in your games?

Edit: as a side note, let's say my current design is fine.. I need a way to sync the states between the game object and physics body, but I don't want the physics component to have a bunch of methods such as "onFire", "onExpire" etc. Maybe the projectile class itself should know about the physics body? Hmm. Maybe it should be an exception to the composition pattern and not contain any components at all, other than maybe for drawing. Hmm.. definitely need some feedback here please!!

Take a look at this: http://cowboyprogramming.com/2007/01/05/evolve-your-heirachy/

It certainly helped me make some similar decisions for the game I am working on.