2 edited body
source | link

I'm making an arkanoid-ish game myself too and I think the solution on how the ball should behave when hitting the paddle is quite simpler and faster than getting into the sin/cos approach... it works fine for the purposes of a game like this. Here's what I do:

  • Of course, since the ball speed increases in time I interpolate the before/after x,y steps to keep accurate collision detection, looping through all "stepX" and "stepY" which are calculated dividing each speed component by the modulus of the vector formed by the current and future ball positions.

  • If a collision against the paddle occurs I divide the Y speed by 20. This "20" is the most convenient value I found to get my resulting maximum angle when the ball hits on the sides of the paddle, but you can change it to whatever your needs are, just play with some values and choose the better for you. By dividing, let's say a speed of 45, which is my initial game speed by this number (20), I get a "rebound factor" of 0.25. This calculation keeps my angles quite proportional when the speed increases in time up to my maximum speed value which, for example, could be 15 (in that case: 15/20 = 0.75). Considering that my paddle x, y coords are midhandled (x and y represent the center of the paddle), I then multiply this result by the difference between the ball position and the paddle position. The greater the difference, the greatear the resulting angle. Besides, using a midhandled padlle, you get the correct sign for the x increment depending on the side the ball hits without having to worry about calculating the center. In pseudo-code:

For n = 0 to modulus ...

if collision_detected then speedX = -(speedY / 20 ) * (paddleX - ballX); speedY = -speedY;
exit; end if

...

x = x + stepX; y = y + stepY;

end for

Remeber, always try to keep things SIMPLE. I hope it helps!

I'm making an arkanoid-ish game myself too and I think the solution on how the ball should behave when hitting the paddle is quite simpler and faster than getting into the sin/cos approach... it works fine for the purposes of a game like this. Here's what I do:

  • Of course, since the ball speed increases in time I interpolate the before/after x,y steps to keep accurate collision detection, looping through all "stepX" and "stepY" which are calculated dividing each speed component by the modulus of the vector formed by the current and future ball positions.

  • If a collision against the paddle occurs I divide the Y speed by 20. This "20" is the most convenient value I found to get my resulting maximum angle when the ball hits on the sides of the paddle, but you can change it to whatever your needs are, just play with some values and choose the better for you. By dividing, let's say a speed of 4, which is my initial game speed by this number (20), I get a "rebound factor" of 0.25. This calculation keeps my angles quite proportional when the speed increases in time up to my maximum speed value which, for example, could be 15 (in that case: 15/20 = 0.75). Considering that my paddle x, y coords are midhandled (x and y represent the center of the paddle), I then multiply this result by the difference between the ball position and the paddle position. The greater the difference, the greatear the resulting angle. Besides, using a midhandled padlle, you get the correct sign for the x increment depending on the side the ball hits without having to worry about calculating the center. In pseudo-code:

For n = 0 to modulus ...

if collision_detected then speedX = -(speedY / 20 ) * (paddleX - ballX); speedY = -speedY;
exit; end if

...

x = x + stepX; y = y + stepY;

end for

Remeber, always try to keep things SIMPLE. I hope it helps!

I'm making an arkanoid-ish game myself too and I think the solution on how the ball should behave when hitting the paddle is quite simpler and faster than getting into the sin/cos approach... it works fine for the purposes of a game like this. Here's what I do:

  • Of course, since the ball speed increases in time I interpolate the before/after x,y steps to keep accurate collision detection, looping through all "stepX" and "stepY" which are calculated dividing each speed component by the modulus of the vector formed by the current and future ball positions.

  • If a collision against the paddle occurs I divide the Y speed by 20. This "20" is the most convenient value I found to get my resulting maximum angle when the ball hits on the sides of the paddle, but you can change it to whatever your needs are, just play with some values and choose the better for you. By dividing, let's say a speed of 5, which is my initial game speed by this number (20), I get a "rebound factor" of 0.25. This calculation keeps my angles quite proportional when the speed increases in time up to my maximum speed value which, for example, could be 15 (in that case: 15/20 = 0.75). Considering that my paddle x, y coords are midhandled (x and y represent the center of the paddle), I then multiply this result by the difference between the ball position and the paddle position. The greater the difference, the greatear the resulting angle. Besides, using a midhandled padlle, you get the correct sign for the x increment depending on the side the ball hits without having to worry about calculating the center. In pseudo-code:

For n = 0 to modulus ...

if collision_detected then speedX = -(speedY / 20 ) * (paddleX - ballX); speedY = -speedY;
exit; end if

...

x = x + stepX; y = y + stepY;

end for

Remeber, always try to keep things SIMPLE. I hope it helps!

1
source | link

I'm making an arkanoid-ish game myself too and I think the solution on how the ball should behave when hitting the paddle is quite simpler and faster than getting into the sin/cos approach... it works fine for the purposes of a game like this. Here's what I do:

  • Of course, since the ball speed increases in time I interpolate the before/after x,y steps to keep accurate collision detection, looping through all "stepX" and "stepY" which are calculated dividing each speed component by the modulus of the vector formed by the current and future ball positions.

  • If a collision against the paddle occurs I divide the Y speed by 20. This "20" is the most convenient value I found to get my resulting maximum angle when the ball hits on the sides of the paddle, but you can change it to whatever your needs are, just play with some values and choose the better for you. By dividing, let's say a speed of 4, which is my initial game speed by this number (20), I get a "rebound factor" of 0.25. This calculation keeps my angles quite proportional when the speed increases in time up to my maximum speed value which, for example, could be 15 (in that case: 15/20 = 0.75). Considering that my paddle x, y coords are midhandled (x and y represent the center of the paddle), I then multiply this result by the difference between the ball position and the paddle position. The greater the difference, the greatear the resulting angle. Besides, using a midhandled padlle, you get the correct sign for the x increment depending on the side the ball hits without having to worry about calculating the center. In pseudo-code:

For n = 0 to modulus ...

if collision_detected then speedX = -(speedY / 20 ) * (paddleX - ballX); speedY = -speedY;
exit; end if

...

x = x + stepX; y = y + stepY;

end for

Remeber, always try to keep things SIMPLE. I hope it helps!