Public Group

# Making A Breakout Clone

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

## Recommended Posts

I'm currently learning games programming, and encountering a few problems writing a 2D breakout clone. Namely the collision detection. It's the first time I've done any collision detection at all, and while I can get it working a little, it's no where near believeable. At the moment I have a single ball, defined by it's centre point and it's radius, I have a speed in the x direction and a speed in the y direction (bottom to top is positive). It has a game loop run by a timer which runs at 1ms intervals. The bricks are defined by a two dimensional array of brick objects, all of identical height and width. I also have a rectangular bat at the bottom that is guided by mouse control. So what I want is this: I need someone to teach me how to check if the ball collides with the bricks/bat in one game loop, then ricochet believably. The methods I've tried so far have the ball sometimes going through the corners of bricks and sometimes reflecting when they really shouldn't. I've looked at a few open-source breakout clones, but a lot of them have similar problems... Oh, by the way, if it's relevant, I'm using Managed C++ in Microsoft Visual Studio 2005. Byt for collision detection algorithms, other languages are okay, I only seek to understand how it works. Pseudocode would be fine too...

##### Share on other sites
The most robust way is to use line-line intersection tests on the four sides of each block. Assuming that you have a position (x,y) and velocity (vx, vy) in units/second of the ball, you can parameterize your line like this:

position(t) = (x + vx*t, y + vy*t)

Since the blocks are aligned with the x and y axes, the intersection tests are dramatically simplified. Given that x(t) = x + vx*t, and the x-value of the side of the block is, say, 4, you can pretty easily solve for what t would be when the ball hits that block's side. If t is positive when x(t) == x(block) and y is in the range of the block's side as well, then you've got a hit. Repeat for every side of every remaining block, take the answer with the smallest positive t. This tells you the first block it will hit.

If t ends up being .01 (meaning it will hit the block in .01 seconds), and your frame is only going to take .005 seconds, you know that you don't have to worry about a collision this frame.

However, if t is .01 and your frame will take .04 seconds, you know that the ball will collide at .01 seconds into the frame. So, move the ball along its track .01, then invert either the x or y velocity (depending on which block edge it hit, vertical or horizontal) to get it going the other way, and move it the extra .03 seconds.

Get all that? Phew. It'll be inefficient, but I doubt it'll matter with just a few hundred blocks. Anyway, it's really late, so just say so if something here made no sense at all.

##### Share on other sites
Maybe it helps to have a look here: http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=30

##### Share on other sites
Quote:
 Original post by BeanDogThe most robust way is to use line-line intersection tests on the four sides of each block. Assuming that you have a position (x,y) and velocity (vx, vy) in units/second of the ball, you can parameterize your line like this:position(t) = (x + vx*t, y + vy*t)Since the blocks are aligned with the x and y axes, the intersection tests are dramatically simplified. Given that x(t) = x + vx*t, and the x-value of the side of the block is, say, 4, you can pretty easily solve for what t would be when the ball hits that block's side. If t is positive when x(t) == x(block) and y is in the range of the block's side as well, then you've got a hit. Repeat for every side of every remaining block, take the answer with the smallest positive t. This tells you the first block it will hit.If t ends up being .01 (meaning it will hit the block in .01 seconds), and your frame is only going to take .005 seconds, you know that you don't have to worry about a collision this frame.However, if t is .01 and your frame will take .04 seconds, you know that the ball will collide at .01 seconds into the frame. So, move the ball along its track .01, then invert either the x or y velocity (depending on which block edge it hit, vertical or horizontal) to get it going the other way, and move it the extra .03 seconds.Get all that? Phew. It'll be inefficient, but I doubt it'll matter with just a few hundred blocks. Anyway, it's really late, so just say so if something here made no sense at all.

This is probably the best, most accurate way, but also probably the most difficult to implement. Easier ways just involve comparing positions, and if it is close enough, you get a hit. For the paddle for example, if ypos-paddlesypos<(size of ball) AND (xpos is between paddles left and right sides), you collide with the paddle. It isn't the most accurate, but is pretty easy to visualize.

1. 1
2. 2
Rutin
19
3. 3
khawk
15
4. 4
5. 5
A4L
13

• 13
• 26
• 10
• 11
• 44
• ### Forum Statistics

• Total Topics
633743
• Total Posts
3013644
×