I'm working on a game and wanted to modify the behavior of a bullet when it hits an object. The bullet class inherits the GameObject class and my game engine iterates through a list GameObjects for collision detection. Basically I wanted to have an "upgraded" bullet that doesn't die when it collides with other objects, but instead keeps going and hitting others along the way. My collision detection loop calls GameObject's virtual function Collided below. So when a bullet collides, it runs this code:
1 2 3 4 5 6 7 8 9
void Bullet::Collided(GameObject *otherObject)
{
//bullet cannot hit an item / or border
if(otherObject->GetID() == ITEM || otherObject->GetID() == BORDER)
return;
SetAlive(false);
otherObject->HitBy(this);
}
I thought about just adding a new variable to the bullet class to indicate what kind of bullet it is (ie- basic, plow, scatter, etc), but I was given some advice a while back that suggests in OOP you should almost never have logic in your code that asks an object what type it is, instead use polymorphism. In order to do that I would have to have two classes that are both still bullets but behave slightly different. Is it really appropriate to go that route rather than just simply adding a new variable to the bullet class to drive the different behavior? Maybe there is an even better way than these?
you should almost never have logic in your code that asks an object what type it is
It is telling about programming type of object, not logical type.
For example adding piercing boolean variable to your class will not be bad (and in fact it might be one of the properties of bullet: bullet can be both piercing and explosie for example).
So your code can be like: SetAlive(piercing); //Will destroy bullet unless it is piercing