Brick properties

Each brick needs properties for positioning, collision detection, design information and keeping a record of how many times each brick has been hit.

Each brick has the following properties:

• Position in x
• Position in y
• Width
• Height
• Half width
• Half height
• Number of times brick has been hit
• Main colour
• Darker colour
• Lighter colour

To draw each brick, set it’s position and three colours (to create the pseudo 3D effect), then draw it to the screen if the number of times it has been hit is lower than the level number.

pos x = position in x
pos y = position in y

Brick design

Having considered the measurement of the game play area, the number of pixels between the left and right borders and the number of pixels between the top border and the top edge of the paddle, I tried to divide the play area to include a suitable number of bricks. I have decided to have a brick grid consisting of 12 x 7 bricks.

Each of the three levels in the game has a different brick design pattern, these are:
Level 1 = Green and purple checkerboard
Level 2 = Rainbow in horizontal colour-bands
Level 3 = White with green squares spelling “IOCT”

Level 1









Level 2









Level 3










Each of the bricks uses three colours, a main colour, a highlight colour and lowlight colour. The use of three colours creates the pseudo 3D effect, used throughout the game.

Levels

There are three levels in the game. Each level must be completed, by deleting all of the bricks in the level before the player can progress to the next level. Each level has a different brick design, to make the difference between the levels clear visually.

The levels also differ in the ease with which they are completed. This increases the difficulty rate of each level as the player progresses through the game.

Level 1 = Each brick hit once then it's deleted
Level 2 = Each brick hit twice then it's deleted
Level 3 = Each brick hit three times then it's deleted

Score

Each time the ball and the brick collide the player receives 10 points. The 10 points are added to the score in the bottom-right of the game play window.

High score board

To understand how to create the High Score Board I needed to research this topic and how score boards are created for computer games. The scores need to be saved in a separate text file. The file is loaded into the structure of the memory at the beginning of the game.

I have structured the text files as follows:
Name (3 characters) Tab Score

To write the headings, “High Score Board”, “Name” and “Score” to the screen I used the sprintf code. I’ve also used the sprintf code in printing the text from the separate file to the screen.

To read the information from the separate file I have used the fscanf code. I began by pointing the computer to the relevant file and have created an integer variable to deal with the scores and a character variable to deal with the names. The code used then opens the relevant file and reads it: fileHandle – fopen(“highscores.txt”, “r”);

I then read the string, tab across, integer and create a new line. This points to the name and score strings. A copy of the name and score are then created. This process is repeated three times to then be used in displaying the names and scores of the three highest scorers.

Collision detection: Paddle

The ball must be projected on to the paddle and the point at which the ball would have contacted the paddle and this point must be calculated. As the paddle has curved edges I tried to angle the edges of the paddle collision detection lines, however, having tried to use the intersection of two lines I could not get the collision detection process to work as desired. I have decided to extend the line across the top of the paddle, so that the collision occurs whenever the ball collides within the length of the paddle.

paddley = top edge of paddle in the y axis

Test:
paddley > position in y – radius

y1=paddley – ball position y + radius
t=y1/vely
x1=t*velx


Test condition, ensure ball hits between paddle edges:
previous ball position x + x1 > paddle position – paddle half width
&&
previous ball position x + x1 < paddle position + paddle half width

ball position x = previous ball position x + x1
ball position y = previous ball position y + y1
vely=-vely
ball position x = ball position x + (1-t)*velx
ball position y = ball position y + (1-t)*vely

Collision detection: Top border

Test:
maximum y < position in y + radius

y1=maximum y – ball position – radius
t=y1/vely
x1=t*velx
ball position x=previous ball position x + x1
ball position y=previous ball position y + y1
vely=-vely
ball position x=ball position x + (1-t)* velx
ball position y=ball position y + (1-t)* vely

Collision detection: Right border

x1=maximum x - ball position x – ball radius










t=x1/velx
y1=t*vely
ball position x=previous ball position x + x1
ball position y=previous ball position y + y1
velx=-velx
ball position x=ball position x + (1-t)* velx
ball position y=ball position y + (1-t)* vely

Collision detection: intermediate point

The intermediate point is the collision point.

ball position x = previous ball position x – x1
ball position y = previous ball position y + y1

ball position x = ball position x + (1-t)* velx //end ball position in x equals whole distance to be travelled minus distance travelled before intermediate point, multiplied by velocity in x
ball position y = ball position y + (1-t)* vely //end ball position in y equals whole distance to be travelled minus distance travelled before intermediate point, multiplied by velocity in y

Collision detection: Left border

Collision detection needs to be calculated, as the ball contacts and needs to rebound from the borders around the game board, the paddle and the bricks.

This works on the physics equation:
speed=distance/time

To calculate the movement of the ball after collision I need to know how much time it has taken to reach the collision, as a proportion of a time step. The remaining time in the time step after the collision is used by the ball travelling in the opposite direction.
x1=ball position x – minimum x + ball radius //calculate distance ball travelled before collision








t //amount of time step as proportion, between 0 and 1
y1 //distance travelled in y before collision
velx //total distance moved (real and projected) in x in time step
vely //total distance moved (real and projected) in y in time step

t=x1/velx //distance travelled in x in proportion to whole distance to be travelled in time step
y1=t*vely //calculate distance travelled in y before time step, multiply whole distance the ball would travel in time step by proportion already travelled
velx=-velx //reverse direction

Developing ball movement

The movement of the ball is based on the mathematical principles of trigonometry and Pythagoras theorem, so these principles were researched.
h = overall velocity of the ball (the hypotenuse)
x = x component of the ball velocity
y = y component of the ball velocity
0 = theta, angle of the path of the ball, set to a randomly generated number between 35o and 55o

x = sin 0 * h
y = cos 0 * h

Trigonometry:
Trigonometry can be used to calculate angles. In right-angled triangles, where there is a hypotenuse, the term SOHCAHTOA can be used:

• SOH = sine = opposite/hypotenuse
• CAH = cosine = adjacent/hypotenuse
• TOA = tan = opposite/adjacent

Pythagoras theorem:
In a right-angled triangle, the hypotenuse is equal to the sum of the other two sides. Often written as: a2+b2=c2

Random number generation:
For the ball to leave the paddle at the start of each game using a different angle, a random number between two set boundary numbers should be generated and control the ball’s initial movement. The boundary numbers are 35o and 55o as these were considered suitable angles between which to project the ball from the paddle.
To create a random number between these boundaries the srand code is implemented to initialise the random number generator, using processor clicks, as these values are different every time the program runs. The boundary angles are then set and the angle must be between these values, it is then multiplied by 2pi/360, and converted to radians. The ball velocity in x and y are then calculated and the remainder of the random number is divided by 2, giving an answer of 0 or 1, allowing the x component to be reversed, changing to direction the ball takes as it leaves the paddle.

Coding a timer

In order to create a countdown I needed to code a timer, again I needed to carry out some research to find the best way to do this. To work out that a second in time has passed the processor clicks need to be counted. If the number of processor clicks is greater than the number of clicks per second, then a second in time has passed.

The timer may also be used if I add a time counter to the game. This is not necessary and may make the scoring system more intricate. I may add a time counter to the game if I manage to get the rest of the essential coding done within the expected time limits.

To create the timer I have included the header file time.h and used the clock code in my game code.

Font experimentation

As the game needs to include text I have carried out some research into the font options available using OpenCV and then carried out some experiments with these.

Text items include:

• Initialisation
  
• Score
• Countdown
• Game over
• High score board

This is an example of the initialisation screen and the font used throughout the game.

State transition

Working from the initial state transition diagram that was presented in the project proposal and presentation, I coded eight states for the game. The states take the player through the game, linking one state to the next depending on the outcome of each game. For example, the game over state may lead to the enter high score state (if the score is greater than the lowest high score) or to the view high score state (if the score is lower than the lowest high score).

The states are:

• Initialisation
• Startup
• Countdown
• Playing
• Game over
• Congratulations
• Enter high score
• View high score

Creating the ball

The design ideas for the ball and testing suggested that the ball should be yellow, to ensure that it stands out against the background of the game board, the video image of the players.

The ball has the same diameter (in pixels) as the height of the paddle, to keep continuity and for aesthetic purposes. A small white rectangle has been added to the yellow ball to create a pseudo 3D effect and add detail to the ball.

The ball has been coded to move only within the borders of the game board. This required some mathematical work, to calculate the velocity of the ball, it's projected position from an initial state to the next during one time step, the distance the ball travels in the x and y axis in a single time step and when it should rebound from the border, accounting for the radius of the ball.

Creating the paddle

The paddle consists of a rectangle and two circles, one at either end of the rectangle. This gives the paddle curved edges, which makes it more visually interesting than just a rectangular design.

The paddle is created using a number of variables. These variables are used to calculate the position of the paddle, the distances it can travel along the x axis inside of the game board and the way in which it interacts with the ball, through collision detection.

The design ideas for the paddle include a highlight and lowlight stripe in the code to add detail and to help create the pseudo 3D effect.

Creating the game board

Having considered various screen sizes for the game I have decided to use a 640x480 window, as this is the largest available and will make the game easier to see.

Design ideas:

• Blue border along the top and the two vertical sides of the screen
• No border along the bottom of the screen, as falling off the bottom of the screen leads to the players losing a "life"

Borders:

• 20 pixels in total in height (for top border) and in width (for vertical borders)
• Lighter blue and darker blue lines add pseudo 3D effect
• Each highlight or lowlight is made of three lines of varying length, to create the pseudo 3D effect
  

Image Processing

I've started to code the game by working on the image processing needed to capture the video signal from the web-cam, turning this into a binary Hue and Saturation image and also creating a flipped copy of the video image in it's original state.

The binary image is used to calculate the weighted-centroid of the bright pink colour of an AIBO ball. The AIBO ball is being used during development, whilst I wait for the larger pink gym ball to arrive.

The copy of the video image has been flipped and will used as the background for the game board, so that players can see themselves, as well as the gym ball. The players will be able to see that the way in which they move the gym ball has an effect on the paddle used in the game.

State Transition Diagram

Initial state transition diagram, as in my major project proposal and presentation.

This will be referred to when planning the structure of my game and allows me to consider how one game screen relates to other game screens. I will use this to remind myself of the order in which I want the game screens to appear.

Gantt Chart

Planning

I've been busy planning my ideas for the project. I've been creating initial design ideas for the game board/screen and have been trying to work out where the objects will be placed on the screen, how they will interact with one another and specifiying some names for key variables.

The project is heavily based on mathematics, to understand the collision detection and spatial position of objects on the screen. I have been researching and working in my logbook at this planning stage so that I have firm ideas in place before trying to code the game.