Brick by Brick: Creating a Brickbreaker style game in JavaScript, CSS, and HTML Pt. 7

Breaking the bricks: Detecting collision with our projectile between the bricks, paddle and edges

At this point, we should take a moment to pat ourselves on the back. We’ve got a game being generated entirely from code, the projectile moves and we can control the paddle; we’ve accomplished a lot! In this article, we’ll be working on detecting collisions between the projectile and other elements in the game.

It might seem like the detect collision method should be in the projectile class, but because it works with other elements in the game, we should put it into the game class so that we can self reference instead of having to pass in all of the elements.

Let’s start this method off by detecting collisions from the paddle. Thankfully, we’re dealing with two dimensional, rectangular objects so we just need to see if the projectile is below the top, above the bottom, left of the right side or right of the left side. If these conditions are true, then we need to change the velocity of the projectile.

The way that brick breaker handles the velocity change after a collision is basically to detect which side of the paddle or brick the projectile is hitting and then inverting the speed on the axis according to the side that it hits on, so if the projectile hits the left side of the paddle, the x axis velocity will be inverted as well as the y axis for the top, etc. The speed will also be increased according to how close to the corners the projectile collides.

For now, we’ll just focus on the collision detection and invert the velocity on the appropriate axis and call the method in our updateScreen() function:

And now the projectile should bounce off the paddle! Of course it just continues to fly off the screen after it gets to the bricks, but we were expecting that because we haven’t told the computer to do anything once the ball gets there!

In order to lighten the load a little bit on our processor(not that this is a very processor intensive game), we’ll not start detecting for collision until the projectile is past the bottom of the brick container and then, because the bricks are stationary and aligned in a grid, we can use some math and the width of the screen and height of the brick container to figure out not only when a brick has been hit, but which brick was hit.

I got that far expecting the projectile to bounce off of the bricks, but it the projectile keeps going just like it did before, what gives! If we rewrite the code to give us some helpful output, we can look in the console and see what is causing the bug:

The coordinate values are returning as NaN(Not A Number). Setting a breakpoint and looking at the getXCoordinate() function, it’s trying to parse “auto” as an integer, which it can not do. This means that we need to change how our x and y coordinates are get and set(Situations like this are where the benefits of Object Oriented Programming really shine: we should only have to change a few lines of code).

Looking back, our brick class seemed suspiciously simple. Because of the way they are laid out as grid items, when we try to get their position, we get “auto” because their positioning is set automatically. We need to override the getXCoordinate and getYCoordinate methods from the base element class with ones that will give us the offset of the bricks:

And it’s still not working, how frustrating! If we set a breakpoint and look at the value of activeBrick, we will find out that it has selected the entirely wrong brick, so we need to change the code that gets our projectiles coordinates in terms of the brick columns as well as flip the x and y coordinates when selecting the active brick:

And it’s still not detecting the collision! this is due to the coordinates in the brickContainer essentially being upside down, so if we subtract 266 from the Y coordinate, it will work quite a bit better.

Now it’s almost working, but it’s not quite right is it? We need to tell the projectile to not collide with bricks that have already disappeared:

The last thing we want our projectile to collide with is the walls, so we can set up a another block of if statements to check our projectile’s position against the boundaries of the game:

That should just about wrap up collision detection. We’re almost there! next article, we will work on changing the ball’s velocity in a more appropriate/fun way!

In case you’re behind, or something is not working correctly, this is how my files look at the end of this article: