Managing collision detection in games

Question

So my question isn\'t about the how-to of collision detection, but is more of a broad \'what code should own collision detection\'. I\'ve written some game in the past(relativel

Answer 1

this is a nice question. Personally, I would not complicate it so much by using "Managers". Let's say we have a GameEngine, which runs the game in its main loop. This main loop could consist of 3 steps: get the user input, update the state of all objects in the game (based on the user input) and finally draw everything again on the screen.

Everything about the collision detection is done in the second step - when updating the objects' state. Let's say all objects in the game are stored in a pool. This includes the player, the bullets, the enemies and even the world (if you'd like the world to be affected as well somehow). All the different objects could have some common properties - they could be Drawable, Movable, Collidable e.t.c. (think like implementing an interface or extending a base class to have these properties)

For each of these properties I would have a class that do something with all the objects in the pool. Like Mover.moveAll(objectsFromPool). This will move all objects, which are Movable. The same for collision detection -> after we've relocated the objects with the Mover, then we check for collision with CollisionDetector.cehckAll(objectsFromPool). This checkAll() method will do the actual collision detection between the objects themselves, knowing their coordinates. If an object is Collidable, the CollisionDetector will invoke its method onCollide(withOtherObject) and then the object itself reacts properly, depending what other object hit it. Let's say, if the player is touched by the enemy body, they will both step back for example. If a bullet is hits by another bullet - they will both be marked for deletion. If the enemy is hit by a bullet, then some damage will happen and the bullet will be marked for deletion. All these reactions should be in the corresponding objects themselves.The collision detector applies its algorithms to detect collision between any two objects and then invokes their onCollide(withOtherObjct) method. If an object is not Collidable, it will be simply ignored by the CollisionDetector (for examples rain particles or dust are not Collidable).

I hope I managed to express myself correct :)

Answer 2

Questions specific to game development are best suited to https://gamedev.stackexchange.com/ by the way.

So in the past I've had say an EnemyManager class

I consider any SomethingManager class to be a sign that your code isn't organised accurately yet. For the most part, objects should manage themselves. If they can't, that implies there is some external information about them, and that information probably has a representation more specific than 'manager'. 3 game-specific examples might be GameWorld, GameRegion, or GameLevel. Enemies exist within a world, or a region of the world, or a current game level, so have such an object maintain its list of enemies.

and likewise for the player projectiles had a PlayerProjectilesManager class

Projectiles too would live in some sort of game space, a world, region, or level.

By now, you can probably guess that one of the above objects can (and probably should) be responsible for owning all the above objects (perhaps indirectly, via a container class, but not via a heavyweight manager of any sort) and responsible for detecting collisions and resolving them.