Game Development Stack Exchange is a question and answer site for professional and independent game developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I am looking for a good method to determine which objects will be considered for collision with other objects.

My current idea is that each object has the following properties:

alwaysCollidesWith = [list of objects that will always trigger a collision check] neverCollidesWith = [lost of objects that will never be considered] teamCollidesWith = [list of objects that will be checked, provided they belong to a different team]

For example: -projectiles never have to be checked for collisions with other projectiles -players are always checked for collisions with players, regardless of team -projectiles are only considered for collisions if they collide with another teams players

Does anyone see any weaknesses with this approach? Can anyone recommend a better approach?

share|improve this question
I think another way of doing it is to just have an identifier for each object saying what collision channel it is in and have another field/property that has a list of identifiers for which this object will collide with. You could use an integer/long with some bit operators to just make this an integer for the identifier and another integer for the "list". – Michael Coleman Jan 13 '11 at 1:12
Also, I think it depends on how you want collisions to be resolved. Do you want to do some logic and then resolve the collision? Do you always want collisions resolved first? – Michael Coleman Jan 13 '11 at 1:13
@Omnion: how does that differ from my answer? I honestly can't see the difference. – egarcia Jan 13 '11 at 23:02
I don't remember there being an answer when I posted. My comments were based of Farseer (which is based of Box2D). I wasn't trying to copy you or anything of the sort. – Michael Coleman Jan 16 '11 at 15:17

The problem I see with your approach is that it doesn't scale very well. For every object, you are storing relations with all the objects that collide with it. If you only have 2 players and a 10 proyectiles, it will work ok. But when that number increases to, say, 20 players and 100 proyectiles, then the number of relations increases exponentially. It'll gradually run more slowly and consume more memory when the number of players increases.

You would be better off by organizing your objects into "groups". And then adding collision/non-collision relationships between each object and those groups. The memory consumption will be slower, and the checks will be faster.

Box2D has a fairly flexible system set up for that.

First, there's categories and masks:

  1. Shapes can have up to 16 "categories" (it's really a 16-bit mask). By default, they are on category "1"
  2. Shapes can also have a "mask" that defines with what categories they can collide. By default, they collide with category "1" only.

Then, there's also groups. A group is an integer.

  1. Two shapes with the same group will always collide, if the group is positive.
  2. Two shapes with the same group will never collide, if the group is negative.
  3. Group rules override mask and category rules.

With these two things, the question "do these two objects collide?", filtering is very fast (a bitmask operation and an integer comparison) and has a very small memory footprint (4 bytes per object).

In your example:

  • Players would have category 1, and mask {1,2} (so they collide with all projectiles by default)
  • Projectiles would have category 2, and mask {1} (they only collide with players)
  • Players and projectile of team 1 would all be in group -1, and team 2 would have the group -2. This way, friendly fire would not happen.

The most recent tutorial that I could find is from 2009 - here it is:

You can also browse the box2d manual - scroll down until it says "Filtering"

share|improve this answer
Collision channels are probably a better way to go, they save memory, are simpler, and are more scalable. – Michael Coleman Jan 13 '11 at 22:27
I'm curious. Care to elaborate? – egarcia Jan 13 '11 at 23:04

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.