Best way to handle collisions

I am wondering what you guys do for handling collisions. For example, do you label each tile in your tileset and then loop through all the tiles to see if there was a collision with the player? Do you create an object layer and denote all the collision areas (then loop through all the collision areas)? Do you create a single polygon from all tiles with a “collision” identifier and see if the player’s position interacts with the polygon?

I think the most efficient way would be to union all tiles that touch one another with a “collision identifier”; so now you may have 10 polygons on a map. Then check if the player is within the extents of the polygon. If they are, then check if the player is within the polygon. Thoughts?

I usually go with speculative contacts which works really well, is really cheap and fairly straightforward to implement.
Explanation and implementation details can be found in this blog post by Paul Firth.

2 Likes

Probably by no means efficient, but for a 2D game I allow every entity to implement their own collision behavior through a lambda, and add a lambda for each type of collision that they want. By default there’s an “All” lambda that collides with everything, but they can override it by adding a lambda for the name of a specific entity they want to collide with and execute different code. This way I can add dynamic collision behavior to anything or make something that only collides/activates with some other specific thing. I haven’t done any kind of simple tile-based collision, probably won’t, I’ll just use invisible entities. Entities in my engine don’t run when they’re off-screen so I doubt there will ever be too many to cause performance issues (Or more accurately entities get politely told to not run, but they can override that too).

Another thing is, I made the Collision data a loadable component in my entities (it’s fast to fetch from the Components field in my Entity class because it’s a Dictionary(String,IComponent)). So theoretically I could have an Entity that has no Collision component but will still collide with everything because other things colliding with it can have their code push away the collision-less entity. That works easily for me since the collision detection code passes both colliding entities to the lambda.

1 Like

There are two data structures I use for making collision detection efficient in 2D.

QuadTrees which is a tree structure which puts everything into zones. Then you only check the zones the entity might be in. So you are not checking everything all the time. https://en.wikipedia.org/wiki/Quadtree

There is a open source QuadTree for XNA which I believe works in MG here: https://bitbucket.org/C3/quadtree/src/0808161c3f3416d51352e16c776f19dc4a748ed3/QuadTree.cs?at=default&fileviewer=file-view-default

The other is a Spatial Hash. Which puts stuff into zones like the QuadTree but not a tree structure. This is good if everything is a fixed size (like tiles). It isn’t as great if you have differently sized entities in because of the key generation required in the hash could impact the performance. QuadTrees handle different sized entities better in the long run IMO.

Again it is all taste and preference, plus each have efficiencies in certain situations. Here is a visualization of both:
http://zufallsgenerator.github.io/2014/01/26/visually-comparing-algorithms/

Personally I don’t check collisions unless it is needed. Only moveable entities check collisions and only if they decide to move. That way collision detection isn’t wasting the update().

I hope this helps.

-David

2 Likes

If you know where the player is and where the tileset starts and how wide and tall the tiles are you can use the player position and shape to make a list of all the tiles it might collide with and just check those ones.

2 Likes

This is something you should definitely do when you’re working with a tilemap. It’s basically a free spatial hash.
There’s a nice illustration in the blog post I linked earlier:

3 Likes