Arkanoid type game question

I'm currently stuck in a world of non game apps, so I want to create a game that has animation. The people on IRC heard me say that I wanted to create a Crystal Quest clone. Unfortunatly I have jumped out of that idea.

Now I have a new idea, creating an arkanoid type game. But something more like an old Mac game called Beebop.

I have tried to recreate it but I'm kinda stuck in the functionality. In other words, I have no idea how to handle the basic game concepts.
What i currently have is

- I have a class for all the objects you see on screen
- in my view controller, I go through an array that contains characters and depending which character I get to, I create an object with a specific image
- in my draw loop, I go through the array that contains the objects and draw them in certain points

The problem lies in handling collision detection of the paddle and also of the ball and of course from the green block which should disappear when they are hit by the ball.

Currently the project is in Cocoa, but I will most likely do it in SDL, mainly because SDL has a topleft zero point and because if I manage to make the game fun, it can be ported to other systems.

The following image is how far I got, but as I said, nothing really works, except the paddle that moves with the mouse

Anyway, for the brick collision, you can do a circle vs. rectangle collision test. I did one for a breakout clone I was working on ages ago, I dug up the code and found this. I added the comments in just now. It took me a minute or two to remember just what the hell I was doing here, but hope it helps:

Code:

// Overview: we want to test the distance of the ball
// to the closest point on our rectangle.

// We first need to determine the closest point.
// Let's start the point at the ball's position:
testX = ballX;
testY = ballY;

// Left, right, bottom and top are the boundaries of our rect
left = testRect.left;
right = testRect.right;
bottom = testRect.bottom;
top = testRect.top;

// Clamp the test position to these boundaries.
// This will give us the closest point to the rect
if (testX < left) testX = left;
if (testX > right) testX = right;
if (testY < top) testY = top;
if (testY > bottom) testY = bottom;

But how would you check for what's on the left or right of the paddle. I thought about getting the mouse position, for the left part subtracting half of the width of the paddle from the mouse position and then do a window coordinates to array coordinates conversion to get the object next to the paddle and see what kind it is.

I'd be inclined to make the paddle another rectangular collider, just like a brick in that sense, but one which is controlled by the movements of the mouse. That is, every time you get a mouse-moved event, you send it to the paddle, and the paddle updates its in-game state -- position and velocity, perhaps -- according to the information it received.

Then, colliding the ball with the paddle is no harder than colliding it with a brick, and the only difference is the hittee's response (presumably the ball will always bounce in the same way..?); and, you avoid making your collision code dependent on the specific input method the player is using :-).

Uh, what? You seem to have misinterpreted me... I was just saying it might be easiest to have a consistent physics model -- for example, one in which a circle always bounces off a rectangle in such a way that the ball's perpendicular velocity is reversed, and its parallel velocity is modified by the rectangle's velocity. It doesn't have to be physically accurate, as long as it feels right :-).

In this instance, the brick collisions'll still work just the same, because they don't move... and if you ever want moving bricks, they'll hopefully be that much easier to add ;-).

With a flat paddle and an accurate physics model you cant control the ball, it needs to push the ball left if you hit it with the left of the paddle, or you could use a curved paddle made of gears like I do

Curved paddle is fine, as long as you show it's curved; inaccurate physics are fine, as long as they're consistent. IMO velocity is a more pleasing x-velocity modifier than collision-position, but YMMV. Up to you :-).

unknown Wrote:With a flat paddle and an accurate physics model you cant control the ball, it needs to push the ball left if you hit it with the left of the paddle, or you could use a curved paddle made of gears like I do

Well, it may look flat at screen resolution, but have a "rugged surface" nonetheless (press command-option-= to see it )

Personally, I prefer the velocity modifier rather than the position-based, particularly when the ball goes near the bottom left/right corners, since a position-based reflection is useless there.