I want to know how to make a very basic breakout game.... How would you make the blocks disappear when the ball hits it?Or, even better, can someone post their code for a simple one so I can learn from it?Please and thank you!;D

Having worked on a breakout clone in 3D before, I know the logic in making one can be stifling. Here are some tips to help you out:

Ball physics hitting blocks are easy. You check to see which side of the block you hit then simply reverse the X or Y speed of the ball by multiplying by -1.

Ball physics hitting the paddle are not so easy. There are a variety of ways to go about it but the most accepted method is that the paddle is sort of like a compass. One side is the largest angle left you can hit the ball, the other is the largest angle right, and then where the ball hits you just interpret between those angles. You can calculate the X and Y speeds of the ball by taking the angle and speed you want and using sin() and cos().

Making blocks disappear is simple enough. Just make a grid of blocks. Each block has a state, either on or off. When on, the ball can hit the block. When off, the ball passes right through. You can use that state to determine what to draw as well.

Anything else, such as non-fixed block sizes, powerups, etc. will add huge amounts of complexity. Start simple, then build off of that.

The 3D version I was making was complicated by having to make the ball roll in 3D, along with having a smart camera that viewed the playfield optimally. I never completed it, but it's still on my system if I ever want to try. Making it in 3D was what really jumped the production time of it and why I had to stop.

My friend finished this much code (for our project)... but it's glitchy! She asked me to fix it up but I don't know what to do. I checked the code a few times and I just don't get why it's not working properly.

The startNew function doesn't work. And the passage of the ball is VERY repetitive... but we used srand() function. Why isn't it going in random directions?

James Stanley: I think compiler optimization probably converts multiplying by -1 to exactly that, since that is faster. It was just easier to explain the way I did.

ultratar:

Here are some suggestions:

You should only draw your buffer to the screen once each frame. Not after every object you draw.

When you draw a buffer to the screen it is much better to use blit() than draw_sprite().

So long as you only make one draw to the screen per frame you can remove your acquire_screen() and release_screen() commands.

There is no reason to keep track of "dir". It's an overcomplicated solution to the problem of knowing which side the ball has hit a block on, and is prone to errors. The better way is to check hits on 8 points of the ball, one point for each 45 degree angle from the centre. When a point registers a hit, you simply reflect those axises. It's made even simpler since you can combine each opposite check with each other. (For instance, if you hit the bottom or top of a block you still reflect the y speed by converting to its negative, or multiplying by -1.)

Having a fixed speed will get boring fast due to the limited ways you can move the ball this way. What you should do instead is make your speed and ball coordinates a floating point value and use decimal values for movement, such as 0.1 or 0.0583. This way you can incorporate more angles and get more interesting movement.