# Thread: Reference to making breakout game

1. ## Reference to making breakout game

Hi guys, i intend to make a breakout game. But i dont know how to start. Can someone give me a direction or reference to making breakout? Mainly i need to know what kind of mathematical theory i should know to code the collision physic. Tell me what book or topic i can research on to help me. Thank you.

2. well I assume you already have an API chosen and everything. You are only going to have to mess with angle of refraction and reflection.

3. Not to be anal, but you won't have to deal with refraction in a breakout game.

Not to be anal again, but I don't think there's really a 'reference' to making a simple game like breakout. I'm not saying it won't be a challenging endeavor, but, I'm pretty sure there are few PhD dissertations on the subject (wait until someone proves me wrong).

In general, I suggest you try implementing as much of it as you can on your own. When you get stuck, send me a private message and I will gladly give you suggestions to bump your progress along.

To get you started, I suggest you look into collision detection overlap tests. Basically, in 2D, come up with a way for determining when two rectangles, or a ball and a rectangle, overlap. When two objects overlap, and are moving towards each other, they collide. When they collide, you then process this collision.

Best of luck.

4. >>when two rectangles, or a ball and a rectangle, overlap.

a ball would still be a rect

5. I am intending to use opengl and win32API. They are something i self-taught myself and i want to put them into practice.

I will code as much as i can. Will post again when i have problem with the collision detection. Thanks for the advice

6. >>a ball would still be a rect

not always, in my crappy game "doublepong" I generate the ball on the fly using lots of small quads (or was it triangles??? cant remember) to create the circle, I dont use a textured quad. Although it is probably very inefficient, I was too damn lazy to create a texture and then do the texturesetup.

7. Ok you have a point there. Although that sounds needlessly difficult, there is no point discussing it here.

8. i have done a rough class diagram, will be using c++.

Code:
```// this class will contain all game logic
Breakout
- level: int // for determine speed of game and width of paddle
- blockmap: int[][] // 2-d array to keep track of the block
- ball:Ball // class Ball contains location and states of ball
+checkCollision(): bool // check for collision
+ updateBall():void // function to update direction of moving ball after collision```

Code:
```// will be using a shrunken rect to represent round ball
Ball
-shrunkenX:double  // coord of top left corner of shrunken rect
-shrunkenY:double // in pixel
-x: double // coord of top left corner of rect that contain
-y:double // ball
-angle: double // angle(rad) is use to keep track of direction that
// ball is moving```
Code:
```Paddle
-x:double
-y:double // coord of paddle in pixel
-width:int // width of paddle determined by level```

Please tell me i am going in the right direction. It seems most logical to use 2d array to represent the blocks.

I believe i wont have problem checking for the rect overlap. However, I am not too sure how should i determine the deflection.
The attribute angle in class Ball is the angle displacement from y-axis. Suppose an collision occur, i just increment the angle displacement by 90 degrees. Does it sound right?

9. I'm very pleased that you've posted a code layout Raison, it shows you have already put some thought into this.

Your code layout looks like a very good start to making a breakout game. Remember, this is your project, and you can implement this however you want. I suggest that you use this code just to get the implementation details working, so dont' be surprised if you find a lot of things changed in your classes by the time you hit a final release. Use this code to get collision detection, the ball's velocity modification, and other complex things working.

Now, about reflecting the velocity. I'm not sure what your math background is, so I'll try to explain things at the most basic level.

Firstly, I don't like the way you've got the velocity of the ball stored. Instead of using axis/angle notation (which is a polar coordinate) I suggest you just store a vector that represent's the ball's velocity. The reason I suggest this is that it's easier to work with, and when you want to actually move the ball you have to convert the angle into a vector anyway in order to add it to the position of the ball.

For one, just to get terminology correct (terminology is important to me) you aren't really concerned with deflection, you are concerned with reflection. Reflection is when a vector's direction is changed such that the angle it makes with the surface coming in (the velocity of the ball before it hits a surface) is equal to the angle it makes with the surface going out (the velocity of the ball after it hits the surface).

I suggest you leave all surfaces in the game such that they are aligned with either the X or Y axis, because this makes the math much easier. In order to reflect the velocity of the ball, you must first determine if the surface that the ball hits is aligned with either the x or y axis. If it is aligned with the Y axis, you reverse the Y component of the ball's velocity. If it is aligned with the X axis, you reverse the X component of the ball's velocity. This ensures that the incoming angle is exactly equal to the outgoing angle.

I drew a pretty little picture (with my elite art skills) demonstrating this idea. This is a good way to go because it's simple, and it produces nice results.

The red thing is your ball that bounces around. The dark blue thing is one of the 'bars' (or whatever they are called in breakout) that your ball will typically hit. The light blue thing is the ball's velocity vector draw from the ball's position (the center of the ball). You can see what the velocity looks like before and after the collision, and I drew each of the vector components of the velocity vector. As you can see, the incoming and outgoing angles that the velocity vector makes with respect to the colliding surface is the same (45 degrees before and after).

10. Hi darkness, thank you for ur elaborated explanation. I really think your suggestion is good.

Code:
```// will be using a shrunken rect to represent round ball
Ball
-shrunkenX:double  // coord of top left corner of shrunken rect
-shrunkenY:double // in pixel
-x: double // coord of ball
-y:double
-x_vector:double // vector of ball movement
-y_vector:double```
This time i will keep two double attribute x_vector and y_vector instead of angle. Each time i need to update the position of the ball. I simply do a

Code:
```x +=x_vector;
y +=y_vector;```
i can also change the magnitude of the vector to determine the speed of the ball.

Reflection is a matter of change the sign of x_vector and y_vector as you mentioned.

Now i can start coding the actual game. Once again, thanks!

11. Yeah not a problem. Best of luck to you.