# Does it matter who does the collision detection?

I gave an answer to How to decide which GameObject should handle the collision?, and received a lot of negative feedback on it, claiming that it does not matter who does the collision detection. I am not understanding that stance.

For example:

There are 100 bullets and 1 player on the screen. Let's assume brute force collision detection and no optimization such as layers or references.

If the collision detection is done by the bullet, each bullet must detect for collision on 100 different objects. That's 100 x 100 detections, for 10000 detections total.

If the player does the detection, that's 100 detections total, one for each bullet.

Am I mistaken? If so, what am I missing?

• Your 10,000 collision checks enable bullets to detect each others, while the 100 ones only detect bullet/player collisions. – Quentin Aug 8 '16 at 22:22
• For what it's worth, the question you answered was about who should handle the collision. Not who should detect it. I suspect that may be part of why your answer was received the way it was. – user1430 Aug 8 '16 at 22:28
• Additionally, this assumes that you allow bullets to collide with one another. Most engines allow collision matrices, where you can set "player" and "bullet" to show collision, but not "bullet" and "bullet". – Jesse Williams Aug 8 '16 at 22:38
• Optimization: If object 1 checks for collision with object 2, object 2 doesn't need to check for collision with object 1 -> have objects only check collision with other objects with an number > their own. Which, for 1 player and 100 bullets, really only amounts to 5151 checks. – Vincent Vancalbergh Aug 9 '16 at 11:34
• The two examples show different situations. In the first there are only collisions between player and bullet. But in the second there are collisions of bullets against bullets too. The answers do not make sense to you because the question itself is inconsistent. – Emir Lima Aug 10 '16 at 14:28

It does not matter in general.

Your examples aren't exactly fair. Your "player does collision" check looks like this:

for each player:
for each bullet:
if player.intersects(bullet), report it


Your "bullet does collision" check looks like this:

for each bullet:
for each other object in the world:
if bullet.intersects(object), report it


Yes, in that case, the first example is definitely better. It will execute 100 times, whereas the second example executes 10,000 times. A more fair example would be for each bullet, for each player for the second case, which will also loop 100 times. If the first example is allowed to take advantage of the fact that system has individual lists of types and that bullets don't need to test against other bullets, why is the second not?

Most general-purpose collision systems don't operate like that because they don't have the foreknowledge of the system required by your first example, and because to build it out could be expensive in terms of memory, and not always a computational win. Doing so means you need to store collision properties in separate arrays for each type of object that can interact, or otherwise similarly manage and configure different blocks of collision data and iterate them possibly several times at different times in the update loop and it can quickly become a cumbersome and potentially cache-unfriendly mess. There are scenarios where such a specialized collision handling structure could be advantageous over other methods. But they are specialized scenarios.

In general collision handling works by looking at N objects and (modulo various optimizations for spatial organization, preventing duplicate checks in a given frame, et cetera), tests them all against each other, blindly firing out notifications to any interested party that "these two things hit each other, do something about it if you want."

Disclaimer: I just saw the answer you gave and I don't think it is a downvotes-deserving one to thaaaaat extent, although is just an opinion perhaps implementation-dependent

Your answer made focus on the iterations, perhaps assuming bruteforce and ignoring the pairs, which are usually made by the preexisting framework. The question seemed to be framework-agnostic and just asked in terms of software design.

To this extent, I'd like to add:

• If you use a preexisting framework, most of the times you don't know which mechanism it will be using.
• You did not focus on the just-created collision pairs, but instead focused on the amount of potential code execution. Said this, it is still irrelevant when to put the code based on that argument. Assume this:

1. Your code for handling the collision is DETECTED(foo:Foo, bar:Bar).
2. First scenario: you want Foo to trigger it when any bar:Bar hits the foo:Foo. There are 10 Foos and they hit bar:Bar at the same time. 55 collision pairs will be made, while only 10 will matter. DETECTED will be called 10 times. Does not matter if the foo called it each of the 10 times, or if each bar called it once.
3. Second scenario: you want Bar to trigger it when any foo:Foo hits the bar:Bar. There are 10 Bars and they hit foo:Foo at the same time. 55 collision pairs will be made, while only 10 will matter. DETECTED will be called 10 times. Does not matter if the bar called it each of the 10 times, or if each foo called it once.
4. Your approach puts several constraints on the level designs when more objects appear in the level.

So you acted as if the OP wanted to build a game from the very scratch, like also having to create their own particular framework (e.g. collision iteration mechanism). It is most likely not the case.

Again: Perhaps focusing on the software architecture aspect instead of the iteration internals was what the OP asked for.