Jump to content
  • Advertisement
Sign in to follow this  
raidzero

Collision Detection

This topic is 2600 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

So I've been working on this game for a while now and the next thing I would like to do is add collision to the game.
But in order to do that I need to understand what exactly is collision and how to implement it. My game is written in C# along with Xna and it's 2D tile-based game.

Are there different types of collision detection? I've heard of bounding box, how does that work?
I've read that you need to find the sides of images and see if those sides collide, is this right? How would it work for tiles?
Will it be easy to implement? Should I have done collision detection before adding sprite and tiles?

Share this post


Link to post
Share on other sites
Advertisement
I found the implementation of collision detection in a 3D engine somewhat challenging - initially I tried to use existing libraries, but in the end, it was something I ended up hand-coding. It took a little bit of tinkering and understanding but it isn't the most complex topic either. Should be simpler in a 2D environment too... but that depends on the environment!

Yes, there are different kinds of collision detection - bounding box collision detection essentially places an invisible box or other shape over the object you're testing for collisions (eg a box or sphere over a character) and then tests for collisions for that shape and not the actual object. In a 3D environment this is much simpler than testing against an object with complex geometry and can be aesthetically a better choice. You could apply the same principle in a 2D world.

To implement your collision detection, decide what it is you would like to test against. You could use a bounding box, or you could test against the actual pixels of your colliding objects- it actually depends on your game. For example, I would imagine that in an isometric engine, you shouldn't put a bounding box over a player character because your body would then be unable to stand against a wall, nor will you be able to run behind walls. Instead, you would probably need to use bounding boxes at the characters' feet and also at the bases of wall tiles rather than at their "height". Wow I'm struggling to phrase this. I'm only guessing here, but this is my hopefully logical assumption.

Another choice - and this is what I did - is to test using a movement vector. Whenever your colliding object moves, you create a vector using the current position and the new position being moved to (note, this is very slight! I'm talking about the movement update over one frame while holding a movement key down). Then, you test whether that vector crosses any world geometry (walls, trees, rocks, a llama, whatever), and it it does, you do not commit said move. What you essentially wind up doing is checking a move's validity just before making it.

Share this post


Link to post
Share on other sites
1) Are there different types of collision detection?
2) I've heard of bounding box, how does that work?
3) I've read that you need to find the sides of images and see if those sides collide, is this right?
4) How would it work for tiles?
5) Will it be easy to implement?
6) Should I have done collision detection before adding sprite and tiles?
1) We are probably failing at terminology here. There are indeed a few different types of CD (continuous / discrete, energy conserving y/n...) but they are probably not what you're thinking about. There are also those things called broadphase and narrowphase. You seem to be asking more about what volumes to use.
2) It works "reasonably well" in a lot of cases. Personally I think the day of OBB-only systems are long gone. Consider at least sphere as well. In general, there are a few "collision shapes" to consider nowadays.
3) Uhm, it seems you are a bit confused here. Images do not collide. Sprites using those images might collide. Checking the sides is only part of the problem, let's say it's a good start.
4) Likely very well.
5) Not really, but it depends on how much stuff you need to mangle. I'd still recommend to consider a physics API such as Box2D - you get rigid body dynamics "for free". Take J-dog's suggestion as an indicator of the complexity involved.
6) I think it's ok. Make sure to keep the CD representation separated from graphics representation.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!