Collision detection

[jag_e_nummer_ett]

So I've been struggling around with löve and so I made my first game; pong.

But I'm experiencing a problem:
I bet you all know how movement works in games, the graphic dosen't move, they jump.
For example: if they got let's say a speed of 10 they will "teleport" 10 pixels each tick.

But that causes a problem...

So my ball is bouncing around and my collision detection for the top and bottom surface is very simple

Code: Select all

-- My top walls ends at 5 pixles
if ball.y < 5 then
	ball.y = 5
	ball.yv = ball.yv * -1
	-- ball.yv = the balls y velocity / speed
end

But for the brackets it's a bit harder...
So I got it reverse it's direction if it's inside the area containing each bracket, similar to how I did the walls collision.

But if I got a high enough speed it will go right trough the bracket, without matching the condition for collision.
And I bet this is a common problem, for example if you got a gun and it's bullet got a massive speed then it will probably go trough everything.

So how would I make this work?
Do I check each pixel between it's "jump"? Or is there a simpler way?


The pong.love file: mediafire
You control the left bracket with W and S, and the right bracket with UP and DOWN.
Atm the right bracket is controlled by a very simple and bad "AI", you can change this in the brackets.lua file.

[veethree]

If you post your .love you could help us help you. For a game like pong the collision can be very simple.
For example on the left paddle, just check if the balls x is anywhere behind the paddle's x and it should work. And of course make sure to check the y also.

[jag_e_nummer_ett]

If you post your .love you could help us help you. For a game like pong the collision can be very simple.
For example on the left paddle, just check if the balls x is anywhere behind the paddle's x and it should work. And of course make sure to check the y also.

Well there is the problem...
Because the ball dosen't move in a strait horizontal line
←→
it can go in any possible direction.
↖↙→

So if the ball comes in from an angle and goes past the bracket it would still be saved because it checks the entire "shadow" of the bracket.

Code: Select all

         o
      ↙

      ()
      |
      |
      |
      ()

     o
  ↙
      ()
      |
      |
      |
      ()

!
o     ()
      |
      |
      |
      ()

      ()
      |
      |  o
      |    ↘
      ()

I hope you get what I mean from that small ASCII presentation...

Anyways for the record, I've added the .love file to the topic.
I'm not the best code; as I said, this is my first löve game.

[jag_e_nummer_ett]

Ah man, while looking at my code I am just thinking more and more on redoing it
I thought I knew Lua, but then löve put me back on the world

[Starry]

I have had this same issue, and seen it in finished games even ('N', early sonic games, etc)

the problem is to do with your game ticks and movement, if your character is moving +17 x and your tiles are 16 wide the issue becomes immediatly apparent, you stepped past it, like quantum tunneling...

I haven't personally solved this myself yet but google tells me increasing the frequency at which you measure for collisions might help. back in the day they limited sonics max speed to avoid this or something to that effect.

hope this helps to conceptualize why your bug is happening. (and hopefully spark ideas how to solve it in your code, which is the trickyer part.)

[veethree]

Once collision is detected (anywhere behind the paddle) can't you correct the position of the ball before deflecting it? That way it should bounce off properly.

[Plu]

One possible fix to the quantum tunneling effect might be to draw a few lines from the character's original position to the new one and see if those collide with any walls in between. That way you won't have to calculate any extra in-between frames. It'll work assuming the collisions are fairly broad (and not about hitting something with a single pixel and being blocked)

[jag_e_nummer_ett]

I am grateful for your help, and I've found some solutions:
This problem is called "Speculative Contacts".

I got 2 sites viewing a solution those are kinda different from each other.
(Both are from wildbunny.co.uk, but they are different)

http://www.wildbunny.co.uk/blog/2011/03 ... ch-part-1/
http://www.wildbunny.co.uk/blog/2011/12 ... detection/

But this is waaaaay too advanced for me, I think I'll either come up with some weird solution via rewriting my movement code for the ball, or I'll just leave it as it is.

Currently it works fine, except from when the ball comes in from a certain angle, in that case it goes right trough the paddle.

Thanks for the help! Sincerely, Jag.

[micha]

Here is a very simple fix:
You current collision check, only checks if the ball is on the left of the paddle. What you need, is to check, if the ball previously was on the right. Something like this:

Code: Select all

if ball.x < paddle.x and ball.oldx > paddle.x then
  ..
end

Next you check of the vertical collisioin (paddle has to be, where the ball is):

Code: Select all

if ball.x < paddle.x and ball.oldx > paddle.x and ball.y>paddle.y and ball.y<paddle.y+paddle.height then
  ..
end

(This code assume, the ball is only one point. If the ball has a width and height, you have to adapt the code accordingly.)

[jag_e_nummer_ett]

-snip-

Yea but that mostly checks if the ball is going straight on the x axle. But if it's going in a diagonal fashion then your statement might miss that!

I've put together a small image representation to explain this:

TUtWfIl.png (148.52 KiB) Viewed 641 times

From this I hope you also see the obvious problem.