Hello again!
In this video, we are going to add interaction between the ball and the paddle to our game.
To do this, we need to be able to detect whether the ball and the paddle have actually collided.
And we also need some way to say, what will happen when that occurs.
We are going to add a function, handle_collision(), which will make the ball bounce off the paddle.
This will modify the ball, by changing its direction.
So we take that by reference.
The paddle is not modified, so we take that by const reference. And then later, when we add bricks to the game,
we need a function which will make the brick disappear when the ball hits it.
So we have an overload for the ball and the brick.
We also need to detect whether the ball and the paddle are colliding.
And in fact, this is true for any entity so we can write a polymorphic function.
This takes the base class, entity, by reference, and then we can pass any subclass of entity, for either
argument.
And this will return true if the two entities overlap with each other.
In C++ we only make functions a member the function if it is part of the class interface, and obviously
that is not the case here.
So we make these non-member functions.
So that means that these non-member functions will need to change the direction of the ball.
So we need to add some member functions which will do that.
So we have functions to make the ball move up, and to make it move to the left, or to the right.
So here is out entity header again. We have added the declarations of these member functions.
We are going to make them pure virtual.
So every subclass will have to implement them.
Then in the ball class we implement these. To make the ball move up,
we make the "y" member of the velocity negative. To make the ball move to the left, we make the "x" component negative.
And to make it move to the right, we make the "x" component positive.
And we also need to implement these for the ball.
The paddle cannot move upwards, so we just leave that as an empty member function.
And you could argue that these member functions really should belong in the ball class and not be in the entity.
So again, that is an architectural decision.
And in fact, I have made the exact opposite decision
to the one I made in the last video, so I am afraid I am being rather inconsistent here!
We have a new header where we declare these interaction functions. And then we have a source code file
for them.
To detect interactions, we can actually use it an SFML feature. So we get the bounding box for
each of the entities. And then we can call this member function, intersects(). And this will return true
if the two boxes overlap each other, otherwise false.
And then in our function for the collision, we first of all check whether the paddle and the ball are
overlapping. And if they are not, then there is nothing to do.
If they are, then we make the ball bounce upwards.
So, for the ball to hit the paddle, it must have been coming down, so we can now make it go up, to bounce
off it.
And then we decide whether the ball is going to bounce to the left or the right.
So if the ball is on the left of the paddle, then we make it bounce to the left.
Otherwise we bounce to the right.
And then finally we need to add this code to the main function.
So we include the header.
And then when we do the update graphics, we add a call to this handle_collision().
So this will update the graphics.
So the ball is now going in the right direction.
If it has collided with the paddle. And there we are.
So, yes, it does bounce off the paddle.
So, if it bounces off the left, it goes to the left, and if it bounces off the right hand side of the
paddle.
(Sorry, it is very difficult to do this and talk at the same time!)
So if it is... there is the left.
There is the right. And the right again.
Okay, so that is it for this video.
I will see you next time.
Until then, keep coding!