Implementing Collisions in Pong

Collision detection is what I need to work on now. If I can implement collisions, my game will be practically done. Of course I’ll still have to add a scoring system, tweak the controls a bit, and maybe add some better graphics, but the bare bones will be there. In all honesty, implementing the collision detection is not as hard as I thought it would be. Collisions are pretty easy to understand if one imagines that every game object has an imaginary box that surrounds it. This imaginary box is called a bounding box. Whenever any two game objects share any of their bounding box coordinates, then we say that a collision has occurred.

In pong, the game objects are boxes so that really makes it easy to implement the code. As it turns out, all the game sprites in my pong game already have a bounding box–an SDL_Rect I added to the class definition. I initially used this rectangle to hold the coordinate pairs so I could display the sprites on the screen. I could now use this same data structure for the bounding box too. The only thing I would have to do is compare the coordinates of the bounding boxes to check if there is a collision. With coordinate pairs, I can do two kinds of comparisons: . The difference is that in one case I’m detecting a collision whenever the coordinates are strictly less than each other while in the other case I’m detecting a collision if the coordinates are equal to or less than. What is the difference between the two?

The above diagram shows the situation when I detect collisions using the less than or equal to operator. In this situation, the ball will never pass the bounding box because the code detects a collision right at the boundary. The problem with this kind of collision is that the eye cannot tell that a collision occurred. This is because the frames go so fast, the human eye can’t keep up so it looks like the ball got close to the paddle then bounced off but never actually collided with it. Of course, I know that in the game code that wasn’t what really happened but only what appeared to have happened. But as in the visual arts, the eye has the final word when it comes to games so if it looks like the ball didn’t hit, then the ball didn’t hit–nobody cares what happened in the code except the programmer.

In contrast, the other type of collision detection uses the strictly less than operator and allows the ball to partially pass the paddle’s bounding box:

This kind of collision is better because the eye is no longer fooled–one can see the collision happening in real time. The only problem is that if the collision code is buggy, then it may happen that one object will sometimes go right through the other one. A similar bug happened all the time in old Atari games like Combat. (I remember I could drive my tank right through walls and the enemy tank without any problems.)

One particular nasty bug is that the ball could potentially get trapped inside the paddle. This is because the ball is much smaller than the paddle and if it passes completely through the front part of the paddle bounding box, then it will remain trapped inside the bounding box–essentially bouncing back and forth between the front and the back. The way to avoid this mess is to allow ball reflection only if the ball is outside the bounding box, not inside.

For my game, I will use the second type of collision detection. A simple function will do the job. Later on, if I decide to add more classes I can implement it as a class method. First I need a function declaration:

A bool is used to return either true or false depending if a collision occurred or not. The two SDL_Rect structures are the bounding boxes. I pass them by reference for better performance. Since they are not supposed to be changed by collision detection, I declare them as constant just to be sure they won’t be modified.

Next I write the function implementation:

The function will return false if rectangle A is outside of rectangle B. Otherwise it returns true by default. When calculating either the bottom part or the right part of the rectangles, the location of the object has to be added to the width or to the length of the rectangle. This is because the SDL coordinate system places the origin of the rectangle at the top left hand corner.

When I call the detect collision function in the game, I call it right before the end of the game loop like this:

If either the left or the right paddles have a collision, then the ball will reflect symmetrically across the x-axis. I could make the function more precise by reflecting across the y-axis when the ball hits the top or the bottom of the paddle; this would require just a little bit more work.

I still have to add a little bit of randomness to the ball when it hits the paddles otherwise the game becomes too predictable–I will leave that for another day. For now, here’s a Youtube video showing how pong looks like after just two weeks of work and less than three months of C++ under my belt.

Pong C++ source code: download.