>Is this the best approach for this type of game?

No. The best approach is priori-ish. You predict if a collision will happen and act accordingly. Like you have the normalized time interval of 1 from one frame to the next, you check if a collision will happen (with some sweeping algorithm), the you subtract the (normalized) timespan from your remaining timespan (started with 1) and continue with that until you run out of (normalized) time. Thats it... basically.

Its horrible complicated... mind you. But the advantage is that the simulation is *very* accurate. It does look and feel a tad more solid/real than breakout games usually look like. (You also dont lose speed when collisions happen.)

Well, I suggest to keep it like that. <edit>I mean the simple approch, you're currently using</edit> If your timestep is small enough it works pretty well. If the displacement gets too big the ball might warp through bricks and/or the paddle.

*copy&paste*



Eg the brick is 16px heigh and the ball radius is 6. 16+6+6=28. So don't move more than 27px otherwise the ball can warp through bricks. (It's really "fun" if the ball warps through the paddle ).

The ball follows the path... it hits a brick on the side that intersects the path and is closest to the balls current position.

ahh thats my topic! i can only underline to use a very basic collision detection. my first java project
was a (never finished) arkanoid. as more as i advanced in the game and used more complex
techniques the problems really grew exponentially!
there are questions like how to measure if a ball hits exactly a corner of a ball. or the problem
of multiple reflections, e.g. the ball hits a brick, so that its velocity vector gets reflected. after each
collision you would need to check another time for a collision (if the ball gets "reflected" into another
brick) etc.
another issue is how you generally deal with movement. if you add a dx/dy to your with bigger values
for fast movement the ball can jump over small objects without collision or even get stuck in them.
most methods to avoid this result in another compromise: precalculating a collision, to move a stuck
ball out of its position etc.

i really noticed that an atomic clear arkanoid becomes a physical snooker simulator. to make things
short, take the easiest way to have a collision, test, if any of your little inaccuracynesses are detected
by your eye or by the game feeling. and then consider more complex improvements.