# Am I going to regret using a color based collision detection system?

I'm just getting started build my first game with XNA (I'm experienced with C# but not games).

I'm building a pretty simple top down 2d shooter. I read this tutorial on using a color based collision system and it sounded really cool to me. http://www.xnadevelopment.com/tutorials/theroadnottaken/theroadnottaken.shtml

It means I can quickly make levels just using any graphics program and not have to define my scenery (walls, trees etc) in terms of collision boxes etc right?

However I can see that going down this path means that perhaps the calculation for determining whether fast moving objects like bullets intersect walls etc becomes more difficult potentially because you cant' do basic geometry intersection type calcs.

Is that right? Am I going to regret going in this direction if my game gets more complex over time? Worth just investing in the creation of a level editor to define my scenery in terms of geometry?

Any advice for a noob very much appreciated!

You're spot on with your observations regarding the capabilities of a bitmap based collision approach.

This method provides a really easy way to edit your levels with any program that can output a bitmap (any image editing program). This system is also really flexible when you want to define different types of ground. Say green for mud, and red for a solid underground. You then easily query the current pixel and determine the type of underground the player stands on. Even ramps (gradients from ground type A to B) are possible without much problems.

Problems arise with collision detection. It's easy to detect an intersection with another object (just do a pixel-test), but it's hard (computationally expensive) to find out what orientation the object you collided with has. This is especially important when you need a surface normal to deflect objects correctly.

Also really fast moving objects can be an issue, especially if you have thin (eg. 1 pixel wide) objects to collide with. There's this question that covers this topic already.

In the end it all depends on what kind of game you want to create and what resolution (in terms of collision detection/resolving) you need. The bitmap based approach works best, when a large portion of your world is static. But it also allows you to implement stuff like destructible levels quite easily.

Since you didn't mention the type of game you want to create, it's now up to you to decide whether or not a bitmap-based collision approach would be beneficial for your game. Good luck.

• In my experience, the surface normal issue is pretty trivial compared to actually determining angular impulse following an impact, in a pixel-perfect collision detection system. Generally PPCD isn't used for games that require that sort of level of detail, though, probably because it makes things a lot harder than vector-based physics, in this regard. The other problem I experienced with this approach was the possibility of getting "stuck" when you rotate your character in certain positions in your level. Box2D and the like handle this by pushing centroids apart when they're too close. Commented Aug 26, 2011 at 8:57
• thanks very much! I don't plan to do any deflections so I think thats ok. I wasn't sure what to do with bullets travelling fast that may skip over walls in a single frame. Figuring out if they crossed a wall seems ok, just take a sample of the map image in a long thin rectangle that is the bullets path and look for wall colored pixels. But figuring out the first wall pixel it would have hit seems a bit harder. I think when the bullet firsts fires I'd raycast and take a number of sample pixels at short intervals along the ray looking for the first wall pixel and mark that as the impact point? Commented Aug 28, 2011 at 22:56
• @TerryB: I think the Bresenham line algorithm will work just fine here. Draw the line until you hit a wall pixel and that will be your point of collision. Commented Aug 28, 2011 at 23:08