Jump to content
  • Advertisement
Sign in to follow this  
death_au

Making A Breakout Clone

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

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Advertisement
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 this post


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

Share this post


Link to post
Share on other sites
Quote:
Original post by BeanDog
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.


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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!