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.

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

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.

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.