Initial Implementation
When we found out that we had to use The Havok Physics Engine for collisions,
we heard that we had to use the abstract class: hkpContactListener. From
here we fiddled around with it in the Havok Sdk, until we had the bare
bones of what we needed. For this to work we needed to initialize the
contact listener first, by giving it 2 rigid bodies which it must search
for a collision between, this would be an issue I’ll explain later.
Once that is done, the contact listener must be attached to one of the 2
rigid bodies in the initialize function.
How Havok handles it after that I do not know, however there
is one function I can call to check if the 2 rigid bodies have
collided. This function is the contactPointCallBack function, which is a
virtual function so we can redefine it. This way in our game we have it
so that we can set what the function does, which in our case sets a
Boolean value for hit to be true.
Issue
The
issue with this is that the only one object will know if it has
collided with the other. For example if the listener was attached to the
bullet, and the bullet collided with the enemy, only the bullet would
know that it had collided with the enemy. The initial response I had was
that I should just add another listener for the Enemy for that bullet,
but that would not have been preferred.
Figure L5
Looking
at my initial thought diagram (figure L5); this would be one heck of a
tangled messed if I did it that way. First, every enemy would have to
check every bullet and the same vice versa. This is highly problematic
because we wanted to have special attributes per bullet, so the bullet
and enemy would have to communicate at some point. Another issue is that
the when a new bullet is added, existing enemies will have to add
another listener for that bullet. Finally when the enemies/bullets
despawn, how do I know which ones to stop checking for in the opposite
class?
Solution
Thinking about these problems, I though the only solution is
some form of reference to the object it was searching for! To do this I
initially had to decide which object will be referred to and which
objected will have the listener. The answer was simple; the bullet
would have the listener, while enemies will be referred to. This is
because no new enemies will spawn within the lifespan of the bullet (3
seconds or hitting another object), unless its end of a round.
Doing this meant I had to modify the listener class to take
in a pointer to the enemy. This would modify the bullet manager to take
in the enemy vector, so that I can get the pointers of all the enemies
in the scene. Once that was done I had an array of bullet listeners, one
for each enemy, each initialized in their own function (figure L6). The
bullet will have to check the listener if it got hit, using a Boolean.
With this when there is a collision, we can now have the pointer to the
enemy call its hit response function, allow for more logical and easier
to read code! 
Figure 6
Figure 6