Testing, Thanks

Thank you to all those who came and took part in the testing event for Breakout: The Breakout on Monday, 18th of August. I hope that you all enjoyed playing the game and I really appreciate all of the feedback you gave.

Testing

Today I am testing the game. If anyone would like to play on Breakout: The Breakout please come along to Gateway House room 6.53.

One person has already completed the game today and gained a new high score, why not come along and have a go too?

Project management

It is nearly the end of July and with only one month remaining to work on the Major Project it is important to consider how the project is progressing and if the work is on schedule.











The code is complete and has been fully implemented. It is important to now focus on testing the prototype and completing the supporting documentation.

The Major Project is running to schedule.

Testing

The IOCT Masters Showcase Event at The Phoenix on Friday, 25th of July 2008 offered an opportunity to demonstrate the game and get feedback from players.

Feedback was extremely positive, with people staying to play the game for a while. Comments suggested that the game was interesting to play and once you had started playing you didn’t want to stop, and also suggested it would be better to play the game on a faster computer in order for the game to run slightly smoother. This is an issue I was already aware of and was just demonstrating the game on the laptop I have been using to code it on. Ideally, I would have demonstrated the game on a desktop computer, however, I did not have access to one during the event.

Other comments suggested that people liked the design of the bricks in the different levels, as I had created posters to show print screens of the different levels. People were keen to play the game and interested in how the object detection worked, asking about how the movement of the AIBO ball (used as I only had a limited space in which to demonstrate my work) controlled the paddle on the screen.

Startup screen

The startup screen is the first screen that the player sees. I wanted to create a bright, appealing image for the startup screen that also reflected the game. I tried some designs using Microsoft Paintbrush, as I wanted the graphics for this screen to be in keeping with the graphics in the rest of the game.

Designs from Microsoft Paintbrush:








































Having chosen a design I liked, I developed this and took the file into Adobe Photoshop to add a lighting effect and the titles. The effect and titles add to the creative effect of the image.




The final design for the startup screen:










To use the image I have created as the startup screen I have used the “cvLoadImage” code to copy the image pixel by pixel, one colour channel at a time and load it to the screen.

Congratulations screen

Something exciting/worthwhile needs to happen as part of the visuals for the congratulations screen in order for the player to want to complete the game. Following on from my idea to include the Cliff Richard tune “Congratulations” I have decided to create a dancing Cliff Richard for this screen.

In order to create the effect of a dancing Cliff Richard I began by trying to draw Cliff Richard using Microsoft Paintbrush. I was working on the idea of having two similar images and switching between the two, to create a dancing effect. To create an image of Cliff Richard I was referring to a video of his performance during the Eurovision Song Contest on YouTube.com. I then realised I would be able to take a few print screens of the video of Cliff Richard dancing and use these instead. From the print screens I found two similar images and cropped them to leave two images which when switched between gave the effect of Cliff Richard dancing.

I then began my research into how to load the two images to be displayed as part of the Congratulations screen and then switch between the two.

In the drawing file of my code I draw the Cliff Richard images to the screen, with an if statement relating to the toggle switch in the main Breakouy_v3.c file. The toggle allows the two images to be switched between, creating the effect of Cliff Richard dancing. In the drawing file I also had to flip the images of Cliff Richard vertically, as they were loading upside down before I added the cvFlip line of code.

Save the high scores

A similar method is used when saving the high scores, as the method for reading the high scores. Instead, to save the high scores the external file is written to, using “fileHandle = fopen(“highscores.txt”,”w”);”.

This line of code opens the relevant file for writing and I have then used “fprintf” to write a string (the player name), tab a space, an integer (the player score) and created a new line. To end this command, I have then used the code line “fclose(fileHandle);”.

Sort the high scores

As a player adds their name and score to the High Score Board the list of highest scores must be resorted into order. The highest score list should have the highest high score at the top and the lowest high score at the bottom.

In the code I have set three integer variables and three character strings, followed by a set of if and else statements to sort the order of the score board once a new high scorer’s name and score have been added to the list.

Enter High Score Board

I have decided to include the following items in this screen:

• Title of screen
• Three letters that can be changed
• An OK button to confirm the name and move on to the next screen

Here is the initial design for the screen, created on the computer.









The design of each button includes:

• Main colour fill
• Highlight colour along the top edge of the button
• Highlight colour down the right side of the button
• Lowlight colour along the bottom edge of the button
• Lowlight colour down the left side of the button

There are three types of button:

• Upper button

• Above the letters
• Go up one letter when the crosshair is held over the button for two consecutive frames

• Lower button
• Below the letters
• Go down one letter when the crosshair is held over the button for two consecutive frames
• OK button
• Larger than the other buttons so that it is visually obvious
• Has “OK” written on it
• When crosshair is held over the button for two consecutive frames, allows the name to be saved to the external text file, the order of the scores and names are reorganised in the external file and the View High Score Board screen is then displayed.

The final version of the Enter High Score Board.

Gym ball

I now have the gym ball, the main controller for the game. During code development I have been using an AIBO ball, as it is very similar in terms of hue and saturation. The AIBO ball has been extremely useful, not only because of it’s colour related properties, but also because of it’s size. The AIBO ball is far smaller than the gym ball and is therefore easier to use when sitting at the computer working on the code.

The larger gym ball will be used for the game, as planned, as I believe it offers the player a more interesting gaming experience than playing with the AIBO ball. Playing with the larger ball requires the player to stand further from the screen on which the game is displayed and in turn offers the opportunity to include more players at one time as the ball can be moved anywhere within the cameras viewing range.

Separating the code

Having all of the code for the game in one file was making working on the file difficult, especially when trying to find certain sections of the code. I have created a header file, which is then called by each of the other .c files, allowing them to compile.

The header file includes:

• Libraries and includes
• Define constants
• Structures
• Global variables
• Game items
• Image
• Function prototypes

The code has been separated into suitable sections, with the .c files including:

• Breakout_v3.c
• Breakout_v3.h
• Collision_Detection.c
• Drawing.c
• High_Score.c
• Levels.c
• Sound.c

Brick cracks

In levels two and three the bricks are not deleted on their first contact with the ball. To show the player which bricks have been hit, I have coded a crack design. The cracks appear in level two once a brick has been hit once. In level three two cracks appear on the brick after the first collision and then another crack appears after the second collision.

To design the cracks I tried a variety of designs on a printscreen of the bricks, using Microsoft Paintbrush. Once I had chosen the brick crack preferred design, I then calculated the pixels which were part of the crack and coded this using the cvLine command. The cracks are created by coding a series of small lines.

The code is divided into three sections, one for each crack. In level two cracks one, two and three appear on the first collision. In level three cracks one and two appear after the first collision and crack three appears after the second collision.

Coding the brick collision effects

To code the brick collision effects I have included checks in an if statement, to check once the brick has been hit if the hit number matches the level number. In the first level, if the brick has been hit once then the player will hear an explosion effect whilst the brick disappears. In the second level of the game, the first time a brick is hit (which is one number less than the level number) the player hears a collision noise and cracks appear on the brick. The second time a brick is hit (the same number of hits as the level number) the player hears an explosion noise and the brick disappears. In the third level, the first hit creates a collision noise and two cracks appear on the brick (this is two hits less than the level number), the second hit creates a collision noise and another crack appears (this is one hit less than the level number) and the third hit causes an explosion noise and the brick disappears (as the hit number equals the level number).

Brick collision effects

In order for the player to know when the ball collides with a brick I have decided to make this clear through the use of visual and audio techniques. This will give the player(s) an indication that a brick has been hit and that the computer has recognised this. Cracks have been coded to represent bricks which have been hit but have not yet been hit enough times to be deleted (the brick has not been hit the same number of times as the level number).

The range of audio and visual effects that occur when a brick is hit include:

Level 1: Brick hit first time = Explosion noise, brick disappears
Level 2: Brick hit first time = Collision noise, cracks appear on the brick
Level 2: Brick hit second time = Explosion noise, brick disappears
Level 3: Brick hit first time = Collision noise, cracks appear on the brick
Level 3: Brick hit second time = Collision noise, another crack appears on the brick
Level 3: Brick hit third time = Explosion noise, brick disappears

This requires the code used for the brick disappearing, first set of cracks and second set of cracks and also the explosion and collision sound effects.

Music

Having added sound effects to the game and understood how the MIDI signals can be used, I have also decided to include some musical elements. I feel the introduction to the game and the congratulations screen would benefit from having music playing alongside the visual image.

For the congratulations screen, I feel it appropriate to use Cliff Richard's "Congratulations". In order to code this, I researched and found a piano score on the Internet to find which notes are used in the chorus, the length of the notes and where the rests are in each bar. I then used a conversion list to convert the pitch musical notes into code and was able to write a piece of code to play the chorus of "Congratulations".

Here is the code I wrote for "Congratulations":

Sound effects

Bloop:






Used during the countdown, synchronised with the countdown

Explosion:





Used when a brick explodes

Waaaa:







Used when a "life" is lost

Boing:






Used when the ball collides with an object on the game screen, including:

• ball hits brick
• ball hits border
• ball hits paddle

Completion:








Used when a level is completed

Sound code

I have researched the ways to add sound effects using c code and OpenCV. The best way appears to be to use a Musical Instrument Digital Interface (MIDI) voice. MIDI works by transmitting digital data about the pitch, intensity and length of notes, for example.

In the code I set up sound as an integer variable to include:

• Frequency (as a floating point number)
• Duration (as an integer variable)
• Volume (as an integer variable)
• Voice (as an integer variable)
• Tempo (as a floating point number)

Volume ranges from 0 – 127, or off to loudest
Voice ranges from 0 – 127, each number representing a different voice or instrument effect

This took some time for experimentation and research to find the noises I wanted to include in the game.

A sample of the code looks like this:

Sound

I have carried out some research into the use of sound in game and have decided to add sound to the game, to make playing the game a more interesting experience, as it involves more of the senses.

Times in the game that may benefit from sound:

• Ball and border collision
• Ball and paddle collision
• Ball and brick collision
• Brick explosion

Other times during the game when sound effects or music could be used:

• Losing a “life”
• Completing a level
• Congratulation state
• During the countdown
• Introduction to the game

Brick collision each row

The calculations shown in this blog are for the first row of bricks. The calculations are the same for each row, changing the number in the code, for example, bricks1 is used for the first row, bricks 2 for the second row and so on.

Brick collision from above to sides of brick

The collisions to the sides of the brick when the ball is travelling from above are the same as when the ball is travelling from below.

Brick collision from below to right

The code for this is similar to collision detection when the ball is travelling to the left, using i+1 instead of i-1, as used when the ball is travelling to the left.

x1 = (bricks1[i+1].posx – bricks1[i+1].halfwidth) – prevballx – gameball.radius + 4;






Again, check that the collision occurs between the top and bottom of the brick, add one to the hit count each time a brick is hit, add ten to the score when a brick is deleted, reverse the ball direction, calculate the final ball position and check if the level has been completed.

Brick collision from below to the left

Collision on the side of a brick only occurs when the ball is travelling sideways and the brick next to it no longer exists. I need to create an if statement, which says if the ball is travelling to the left, but do not check if the brick being hit is the left-most brick (as there is no brick to the left of it to be hit), then check the side collision.

x1 = prevballx – (bricks1[i-1].posx + bricks1[i-1].halfwidth) – gameball.radius – 4;
t = (float)*1 / (float)gameball.velx;
y1 = (int) (t*(float)gameball.vely);
tempballposx = prevballx + x1;
tempballposy = prevbally + y1;


//Check that the collision is between the top and bottom of the brick
if (bricks1[i-1].posy + bricks1[i-1].halfheight + 7 >= tempballposy && bricks1[i-1].numberhits < level)
{
bricks1[i-1].numberhits ++; //Add one to hit count
if (bricks1[i-1].numberhits == level); //Set up to check if brick hits equals level number then a sound effect could be added later
}
score = score+10; //Add 10 to the score each time a brick is deleted
gameball.velx = - gameball.velx; //Reverse the direction of the ball
gameball.posx = tempballposx + (int) ((1.0-t)*(float)gameball.velx); //Calculate the final ball position
gameball.posy = - tempballposy + (int) ((1.0-t)*(float)gameball.vely); //Calculate the final ball position
checklevelcomplete(); //Check if the level has been completed

Meeting with Project Supervisor

Meeting with Project Supervisor, Mohammad Ibrahim
Friday 19th June
2.15pm

I demonstrated a version of my work and talked Mohammad through the code. I answered questions relating to the working process and the code itself. We discussed possible directions for the project, such as potentially adding sound. I had not previously considered incorporating sound into the game, as I was not sure exactly how tight time constraints would be (having never programmed a game before), however, Mohammad believes that I am working and progressing well and may have time to add additional aspects to the game.

Brick collision from above

Collision detection to the top edge of the brick when the ball is travelling from above.



y1 = previous ball posy – bricks1[0].posy – bricks1[0].halfheight – radius – 1
t = y1/vely
x1 = t*velx

tempballposx = previous ball posx – x1
tempballposy = previous ball posy – y1

for (i=0; i<12; i++)
if (tempballposx >= bricks1[i].posx – halfwidth && tempballposx =< bricks1[i].posx + halfwidth)
if (bricks1[i].numberhits < level) //Check brick still exists
bricks1[i].numberhits++ //Add one to hit count
vely = - vely //Reverse ball direction
ballposx = tempballposx + (1-t)* velx //Check final ball position
ballposy = tempballposy + (1-t)* vely //Check final ball position

Brick collision from below

Collision detection to the base edge of the brick when the ball is travelling from below.

y1=(bricks1[0].posy-bricks1[0].halfheight) – previous ball position – radius – 1
t = y1/vely
x1 = t*velx

tempballposx = previous ball posx + x1
tempballposy = previous ball posy + y1

for (i=0; i<12;i++)
if (tempballposx>= bricks1[i].posx – halfwidth && tempballposx =< bricks1[i].posx + halfwidth)
if (bricks1[i].numberhits < level) //Check brick still exists
bricks1[i].number hits++ //Add one to hit count
vely = - vely //Reverse the ball direction
ballposx = tempballposx + (1-t)* velx //Check final ball position
ballposy = tempballposy + (1-t)* vely //Check final ball position

Brick collision

To create the collision detection on the bricks, I need to calculate a number of collision detection circumstances, these include:

• ball travelling from below, hits base of brick
• ball travelling from above, hits top of brick
• ball travelling from below, hits right side of brick
• ball travelling from below, hits left side of brick
• ball travelling from above, hits right side of brick
• ball travelling from above, hits left side of brick

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