Breakout Week 4: Building a Wall (Part 2)

This is part two of my two part post of building the wall in my Breakout game.

With the wall in place, the next step is to make the ball break the bricks as it hits the wall.  This bring us back to collision detection and response again.

I did quite a bit of reading on this because there are a number of ways you could do it.  The collision detection part can be fairly easy, where you just check if the ball is within the bounds of each brick, but it gets complicated by the fact that once you know a collision occurred, you also need to know which side of the brick the ball hit because it could hit any of the brick's four sides or corners.  You need this in order to know in which direction to bounce the ball after it hits the brick.  There seemed to be a couple common techniques for doing this, well common ones I found in a quick google search at least.

The first technique involved looking at the previous position of the ball and it's position relative to the brick. For example, you create regions based on the edges of the brick and find which region the ball was in before it hit the brick. The regions would like this:

Breakout Week 4: Building a Wall (Part 1)

I had a pretty busy week last week, okay that was mostly due to the fact that Dragon Age 2 came out and I spent several nights playing and not sleeping. Despite that I did manage to find some time to work on Breakout. The goal for this week was to get the wall drawn and handle the collisions of the ball against the wall. I did manage to get that all working, which I was pretty happy about, but I also came to the conclusion that the way I am handling the collisions is not very good, particularly for the wall.

Because there is a lot to go through with the collision handling and I also want to cover how I setup and draw the wall I'm going to split this week's post in two.  This post will cover the setup and drawing of the wall and it should be relatively short. I'll write another post around mid this week where I'll cover handling the collision of the ball against the wall, the problems with my approach and how I'm going to improve it.  So for now, lets get stuck into the setup of the wall.

As usual, we have a Wall class that handles the setup and drawing of the wall. Just like the paddle and ball it is created by the Breakout class. Here are the main instance variables of the wall.

class Wall {
   private const int bricksPerRow = 20;
   private const double wallHeightRatio = 0.20;
   private const int numRows = 7;
   private static readonly Color[] colors = {
     Color.Red, Color.Orange, Color.Yellow, Color.Green, 
     Color.Blue, Color.Indigo, Color.Violet
   };

   private readonly int screenWidth;
   private readonly int screenHeight;
   private float brickHeight;
   private float brickWidth;
   private Rectangle wallBounds;
   private Texture2D sprite;
   private List<Brick> bricks = new List<Brick>();

Breakout Week 3: When Balls Collide

This week was all about collision detection and collision response.  The plan was to add the ball to the Breakout game, get it moving around the screen and bouncing off the walls and the paddle.  I probably did much more research than was required this week since I spent a lot of time reading about various collision detection algorithms and the physics of collision response.  It turns out that didn't actually use any of the techniques I read about since a very simple technique works well enough for Breakout.  It was worthwhile reading all that though, if for no other reason than I now have a much better appreciation for what I need to learn.

So, research aside, the coding up of the ball itself was very easy, it only took about an hour and half and most of that was spent tweaking various parameters to get the "feel" right. So on to the code.

As with the paddle, there is a class for the Ball with LoadContent, Update and Draw methods that are called by the Breakout class.  The Ball tracks it's own state in these instance variables:

private Texture 2D sprite;
private Vector2 position;
private Vector2 direction;
private int speed;

This is slightly different to the paddle in that we store the speed as a scalar value and the direction as a vector.  The direction is a unit vector so it contains no speed information, which is why we need the speed as a separate variable.  The reason I did it this way is that the ball can move in both x and y directions, unlike the paddle, so using a unit vector allows use to calculate directional changes for the ball without needing to worry about the length of the vector, since it will always be 1.

The ball also has a few other instance variables that hold initial states, ranges of speed and position and whether the ball is currently active or dead.

So, once again, all the interesting stuff happens in the Update method:

internal void Update(GameTime gameTime) {
    if (state == State.Active) {
        UpdatePosition(gameTime);

        if (position.Y > screenHeight) {
            state = State.Dead;
        } else {
            HandleCollisions();
        }
    } else if (state == State.Dead && 
           Keyboard.GetState().IsKeyDown(Keys.Space)) {
        LaunchBall();
    }
}

Week 2: With a Paddle

With all the installation and setup out of the way, this week I finally got to write some code.

I decided that the goal for this week was to get some initial classes laid out for the Breakout game and implement the basics of the Paddle.  Let's start with the class design.

When you create an XNA project, it auto-generates a Game class for you. This class is the core of your Game. In it you implement methods for loading content, updating state and drawing a frame.  However, I don't think it is the best place to put much game logic. I've always tried to avoid pointing too much custom code into classes that extend from framework classes since it makes it harder to test your own code in isolation and it means large amounts of you own code could break if the framework changes. The Game class will act mainly as glue between my game implementation and the XNA framework's game loop. To this end, I created a Breakout class which is instantiated by the generated Game class.  Here is what it looks like:

public class Breakout {
    private SpriteBatch spriteBatch;
    private Paddle paddle;
    private Ball ball;
    private Wall wall;
    private int screenHeight;
    private int screenWidth;

    public Breakout(SpriteBatch spriteBatch) {
        this.spriteBatch = spriteBatch;
        this.screenWidth = spriteBatch.GraphicsDevice.Viewport.Width;
        this.screenHeight = spriteBatch.GraphicsDevice.Viewport.Height;
        this.ball = new Ball();
        this.paddle = new Paddle(screenWidth, screenHeight);
        this.wall = new Wall();
    }
}

It's pretty straight forward, Breakout has a Paddle, a Ball and a Wall, just as you would expect.  The Breakout constructor is passed in a SpriteBatch instance which it will use to draw all the graphics for the game. The SpriteBatch is created in the Game class's Initialize method, where the Breakout object is also created, like so: