During development of my project “Component Based Game Engine – Doom Style Game Integration”, one of my responsibilities was implementing the collision system; collision detection and handling.
The first step in this process was to identify the requirements and constraints that should be placed on the system. The engine was required to be as generic as possible. However, certain limitations could be made which would result in an engine that; although generic, could be used to create games of a certain style. These initial constraints enable me to define the core requirements of the system:
- Handle box and sphere collisions
- Check for collisions between entities within a certain area of the map
- React in a number of defined ways to a detected collision
From these core requirements, I was able to begin to structure the class in psuedocode. When considering the collision type, there was no reason that the collisions should be able to detect any collisions beyond box and sphere collisions. Below is examples of the collision detection implemented:
Sphere – Sphere collision detection:
Box-Box collision detection:
Box-Sphere collision detection:
The resulting detection was very accurate. The limitation of the box collision detection is that as its name suggests; Axis-Aligned-Bounding-Box, it is only effective when the box is axis aligned. This was sufficient for the engine, and given the constraints of the specification was a justifiable sacrifice. If the engine was scaled to deal with more complex collision data and map layouts an alternative method would be required.
The engine was component based. Therefore, it would not have made logical sense to combine the collision detection with the response. Collision response is traditionally game logic. To enable this a collision handler component was implemented, track when a collision occurred and store the object in which it collided with. This data was sufficient for implementing a number of different collision responses. The game we implemented this was used for: dealing damage; killing enemies; collecting coins and picking up power-ups. Improvements to the engine could be to define a number of common collision response algorithms within the engine code to improve the coding environment. However, the implementation was sufficient in this case.
Optimizations
An optimization of the collision detection system was a simple form of spatial partitioning. Only objects within a certain range of an object were detected. This range could be defined by the end user, and would reduce the amount of calculations involved in collision detection. This did not extend to multiple spatial layers rather treating the area as an infinite column, checking collisions with an object within a certain range. Other spacial partitioning methods were considered such as dynamic bounding volume trees, the implementation above was decided upon as adequate alternative.
The end user may wish for some entity types to be ignored by a collider e.g. an agent should not be collecting or testing for collisions with coins. The end user is given the option to provide a list of strings that refer to the labels of objects that they wish their collider to ignore. This further optimization made the engine more versatile.
There is a lot that could be discussed in regard to this aspect of the project. Hopefully this post has given some further insight into not only the implementation used, but also some of the processes used to reach this implementation. Further posts of a similar nature will follow to break down other key features that I created during my time of this project.
