Simple 2D collision detection for a platform game (easiest solution possible using tile engine)

Started by
28 comments, last by zuhane 8 years, 3 months ago

I feel like this may have gone full circle...

Could anyone offer any solutions to the original problem at hand?

Advertisement

I feel like this may have gone full circle...

Could anyone offer any solutions to the original problem at hand?

Did this link not answer your problems? Specifically:

"Because we don't want the player (or any other fast moving object) passing though platforms if they move too quickly, the fine grained collision detection system, or narrow phase, must be good enough to prevent this from happening."

My Gamedev Journal: 2D Game Making, the Easy Way

---(Old Blog, still has good info): 2dGameMaking
-----
"No one ever posts on that message board; it's too crowded." - Yoga Berra (sorta)

Have a look at the "Collision detection" section on the second part of the platformer tutorial from paul (prev post from BeerNutts).

There you have the simplest possible solution achieving a cheap continuous collision solution using a tilebased system.

The only thing you have to do is to calculate the closest point+distance on a minkowski-sum aabb (tile aabb extended by the player aabb).

Another approach is to calculate the time when a line segment from a tile hits the movement line of a player - also using minkowski sum.

This is fully explained in the collision series of handhand hero, see:

https://hero.handmadedev.org/videos/game-architecture/day043.html (The Equations of Motion)

Vectors)

https://hero.handmadedev.org/videos/game-architecture/day045.html (Geometric vs. Temporal Movement Search)

https://hero.handmadedev.org/videos/game-architecture/day048.html (Line Segment Intersection Collisions)

https://hero.handmadedev.org/videos/game-architecture/day050.html (Basic Minkowski-based Collision Detection)

Thanks for the replies!

So I've read over that wildbunny article quite a few times, and I simply just don't understand it. I understand the concept of speculative contacts,

and how I could possibly be moving so quickly that I completely skip a collision check, but I just don't understand how to put what he's said

into practice, and I definitely don't understand his code as a lot of it is down to assumption. It may seem more obvious if you have experience with

collision detection, but to me, it's very difficult to understand! :)

At the moment, I have a spatial hasher implemented as the furthest and most "abstracted" layer of collision detection.

Once objects are in the same "bucket" of the hasher, a simple loop is used to determine whether the

rectangles intersect. If they do, the code I posted in the original post is executed to adjust the objects

accordingly and move them to where they should be. This all seems to work as intended, but things

are falling through now and again.

Does this mean that it's the higher level check of whether the intersection is happening that should be changed, and not my actual

intersection code? Like, the actual loop that checks to see if the two rectangles intersect needs fixing, and not the actual code that

executes once this condition is met?

Also, is the act of determining whether this collision check should happen referred to as speculative contacts, or do speculative contacts

play an actual role in adjusting the position of the object once it's intersected a tile?

Zuhane, I would also advise you watch these 2 videos form the handmade heros segment, as he discusses possible tunneling as well as the Minkowski Sum for collision, and it makes a lot of sense.

https://hero.handmadedev.org/videos/game-architecture/day048.html (Line Segment Intersection Collisions)

https://hero.handmadedev.org/videos/game-architecture/day050.html (Basic Minkowski-based Collision Detection)

My Gamedev Journal: 2D Game Making, the Easy Way

---(Old Blog, still has good info): 2dGameMaking
-----
"No one ever posts on that message board; it's too crowded." - Yoga Berra (sorta)

Thanks again for the reply :D I'm not really proficient with C++, so I couldn't get much from those videos. I think

I'll just have to leave this problem and maybe make it into a "glitch feature", or alternatively just shoot myself lol.

I'm amazed there's nothing simpler out there, but I suppose that's just the way it is :(

Thanks again for the reply biggrin.png I'm not really proficient with C++, so I couldn't get much from those videos. I think

I'll just have to leave this problem and maybe make it into a "glitch feature", or alternatively just shoot myself lol.

I'm amazed there's nothing simpler out there, but I suppose that's just the way it is sad.png

I know that collisions maybe hard for someone, but its not that big of a deal.

It always boils down to some simple scalar/dot products and some very basic trigonometry and if you dont know this yet - just google "unit circle" + "vector length" + "vector projection" and you will get it. This was the key for me to start solving a lot of collision problems by myself - without any extraordinary math and if you have a specific question, just ask. There are tons of helpful people here.

A possibly simple solution might be to multisample (explained in a sec) objects that are smaller than some value, or their speed is greater than some value. Basically, you could multisample objects that have the potential to tunnel through objects, either just check if their dimension on an axis (or both) is smaller than some value, and then check smultiple positions of that object.

For example, in the bullet's case, when you test for collision, make multiple tests, but with the object having moved only the parital distance it moves in a frame, and check for collision. Repeat once or twice more (depending on size and speed), and you will have resolved your issue.

Maybe this is something you can play with at least, and see if it resolves your issue, then you can work out a solution.

Here's a great page on collisions BTW, it talks about tunneling in section 5 with a multisample mention as well.

My Gamedev Journal: 2D Game Making, the Easy Way

---(Old Blog, still has good info): 2dGameMaking
-----
"No one ever posts on that message board; it's too crowded." - Yoga Berra (sorta)

This is one of the best explanations of continuous collision detection using bounding boxes that I've seen:

You don't need to use 2 bounding boxes, nor do need to do the splitting into top/bottom and left/right boxes if you don't want, this technique works equally well with a single bounding box and I've used it to great effect in games that I've written.

Doing the same with a single bounding box is explained in this video, although it's explained mostly through code rather than diagrams:

In case the video isn't clear enough, the basic steps (regardless of how many bounding boxes you use) are as follows:

  • Calculate your desired move distance.
  • Choose an axis to resolve first (I tend to go with x)
  • Take your desired move distance in the chosen direction and extend the bounds of your bounding box by that much in that direction.
  • Get all of the tiles within your new bounding box.
  • Check for collision in the direction of travel against only the tiles within your new bounding box.
  • If there is no collision, move your full desired move distance.
  • If there is a collision, do whatever your collision behavior is (most likely, move as far as you can then stop)
  • Repeat for the other axis.

This has been the most arduous process imaginable haha! A huge problem regarding the game's development is that I started

adding loads of new features and complexities in before getting the collision detection working properly. After hours of rigorous testing,

I've deduced that it is indeed the speed of objects moving that is causing the clipping issue, and that smaller objects have less surface area

to check for collision, so in turn have to move even slower that large objects to successfully perform a test.

The hardest part of this problem wasn't figuring out WHAT to do to fix it, but WHY they were clipping in the first place, specifically. I made a few

assumptions before about my code, but it's definitely safe to say that it is the bullet-through-paper problem causing the issue! This feels

like progress, finally :D

I'm also massively hyped to check out this video, adt, as Cave Story is one of my favourite games of all time :D I'll be sure to reply once I've looked

into this further, and I'll most definitely post a solution once I find it myself, so that future readers may be able to fast-track some collision code :)

This topic is closed to new replies.

Advertisement