Havok Collisions

 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