I want to learn how to create good object-oriented (OO) design practice for collision between two objects situation in game development.
Let's say I have a SpaceShip class and a Meteor class. When Meteor collide with the SpaceShip, the SpaceShip will be destroyed.
The question: What class should I put the method to check if there is collision between meteor and spaceship as well as the collision resolution method (destroy the spaceship)? Is it at SpaceShip class or Meteor class? Or maybe I should put at another class, ie. GameArea or GameController class?
Note: for the sake of simplicity, assume the Meteor and SpaceShip is in form of image resource. I'm used to use Java language, but other language is okay too.
A hitbox is an invisible shape commonly used in video games for real-time collision detection; it is a type of bounding box.
Why Is It Helpful? As stated earlier, OOP is helpful because it helps create maintainable code - code that is understandable, adaptable, and extendable. It also helps create reusable code by following the DRY (Don't Repeat Yourself) method: write the code once and then reuse it, rather than copying and pasting.
Axis-Aligned Bounding Box One of the simpler forms of collision detection is between two rectangles that are axis aligned — meaning no rotation. The algorithm works by ensuring there is no gap between any of the 4 sides of the rectangles. Any gap means a collision does not exist.
Continuous collision detection techniques attempt to find when two bodies collided between the previous and the current step of the simulation. They compute the time of impact, so we can then go back in time and process the collision at that point.
It's more natural to think that collision detection is a responsibility which does not belong to Spaceship or Meteor classes. Especially when this gets complicated with multiple collision possibilities in different directions. If you put this logic in both these classes they will need to have references to lots of other objects that are around them which wouldn't be appropriate.
You could have this on a separate class such as CollisionDetector which keeps track of coordinates of all objects in game space and detect collisions. Collision prevention also appears to be a separate responsibility that should be in a different class in my opinion. You could have a separate class CollisionResolver for this. Depending on the requirements, CollisionDetector could talk to CollisionResolver.
CollisionResolver may need to be able to talk to Spaceships, for purposes such as advising them to change direction, or to command firing missiles towards the Meteor.
CollisionDetector and CollisionResolver could sit within the GameSpace/*GameController*. etc..
This would promote Single Responsibility Principle so each component would be doing only one focussed task.
Collision detection, in my opinion, is not part of an object... it should be defined as something else - some physics manager, etc. That way your objects will be independent on the collision algorithms.
Another thing is that in games usually object consists of several layers (components): Graphics Layer, Physics Layer, Logic Layer. That way physics manager manages only physics component of given objects.
class GameObject
{
RenderComponent m_renderComponent;
LogicComponent m_aiComponent;
PhysicsComponent m_physicsComponent;
};
Well, I usually create a (sometimes generic) GameObject
class or interface that has a collides method. For example:
template< typename T = int > class GameObject
{
public:
bool collides(const GameObject& obj);
};
// usage
GameObject<int> my_obj, your_obj;
if(my_obj.collides(your_obj)) { ... };
Another thing I sometimes (but rarely) do is to create a separate GamePhysics
class:
template< typename T > class GamePhysics
{
public:
/* you may make this static or the class a singleton */
void detect_collision(const T& obj, const T& obj2);
};
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With