248 Chapter 10
detection (where we make the ball bounce back from each edge of
the screen) to the following:if picx <= 0 or picx >= 700:
speedx = -speedx * 1.1
if picy <= 0:
speedy = -speedy + 1In the first case, when the ball is bouncing off the left and
right sides of the screen in the horizontal direction, we increase
the horizontal speed, speedx, by multiplying it by 1.1 (and we still
change the direction with our minus sign). This is a 10 percent
increase in speed after each left and right bounce.
When the ball bounces off the top of the screen (if picy <= 0),
we know that the speed will become positive as it rebounds off the
top and heads back down the screen in the positive y direction, so
we can add 1 to speedy after we change the direction with the minus
sign. If the ball came toward the top at 5 pixels per frame in speedy,
it will leave at 6 pixels per frame, then 7, and so on.
If you make those changes, you’ll see the ball get faster and
faster. But once the ball starts going faster, it never slows back
down. Soon the ball would be traveling so quickly that the player
could lose all five lives in just a second.
We’ll make our game more playable (and fair) by resetting the
speed every time the player loses a life. If the speed gets so high
that the user can’t hit the ball with the paddle, it’s probably a good
time to reset the speed to a slower value so the player can catch up.
Our code for bouncing off the bottom of the screen is where we
take away one of the player’s lives, so let’s change the speed after
we’ve subtracted a life:if picy >= 500:
lives -= 1
speedy = -5
speedx = 5This makes the game more reasonable, as the ball no longer
gets out of control and stays that way; after the player loses a life,
the ball slows down enough that the player can hit it a few more
times before it speeds back up.
One problem, though, is that the ball could be traveling so fast
that it could “get stuck” off the bottom edge of the screen; after play-
ing a few games, the player will run into a case in which they lose