You do not need to have a different collision callback method for each type of collision.
You could implement one callback:
To treat different types of objects you can have collide-able objects implement an Interface
ICollide that has a function, collideWith(obj); and perhaps
getMass(); and possibly
Then each object checks the attributes of the object it collided with and responds appropriately. For instance a bullet may pass through a wooden wall, bounce off a metal sheet and knock off a tin can.
The insides of
collisionEvent(objA, objB); will look like:
objB.collideWith(objA); // You may need to elaborate depending on the game
Instead of having a switch statement, you could use 'low resolution attributes' to keep things simple.
For instance add a density to each collideable object. It could be a Enum to reflect the needs of the game.
- Lets take a solid metal sheet, it will have a density of High and a bullet will check against that and bounce off it.
- A wooden wall will have a density of Low and the bullet will pass through.
- A thick sturdy plaster wall will have a Medium density and the bullet
will get trapped inside it.
In reality I am pretty sure the bullet would pass through a plaster wall, that was just an example for a third option.
You will probably need a mass property if you have many objects of different sizes.
For instance, a tin can will be low density and have a low mass value, meaning it will bounce off when hit by a bullet and the bullet will continue in its trajectory.
Some items will need to be of a fragile variety such as glass, so you will destroy the item if it is hit by a bullet and animate this process.
All the properties I described exist in physics engine except fragility, however physic engines mostly assume objects cannot pass through one another. You could try and override that behavior programatically. Simply by not checking/acting on collisions between bullets and materials of low density.