In this week’s update, not one but two exercises have been completed! Of course, one of those is the one from last week and the other one was pretty simple, but nevertheless, progress! To be more specific, I finally settled on the mechanism I liked the best for altering the ball speed in game and tied it into scoring for the next exercise, which I also completed: earning extra lives (hence the title of this blog post).
First, lets discuss that whole ball speed thing. I decided on two different mechanisms for increasing the speed of the ball.
- Every time a brick of a certain color (in this case pink/magenta) is destroyed
- Every time a brick in every 4th row is destroyed
As the code was originally written, the ball would do collision detection with the grid of bricks (just an array of integers that indicate what color to display the brick as) and would also update the score as well as removing the brick. As such, a little code refactoring was in order.
I created a simple BrickGrid entity that is responsible for holding onto the grid of bricks as well as rendering it. This entity can also tell you if a brick is at a particular location, which exact brick it is, and remove bricks, plus some other handy things. This refactor cleaned up a lot of code because it meant that the rendering code in the game scene was a lot nicer and a lot of global constants could be filed away into a single place. It also sets us up for things like custom brick layouts later on.
Also modified is the method in the Ball entity that performs the intersection with the BrickGrid entity. This was reworked a bit so that it could use the new entity. More importantly however, it was also modified to only react to a brick by reflecting its travel as needed while also returning back the location in the brick grid that the intersection happened at. This is a lot cleaner than it used to be, which was a bit of a hold-over from the original non-OOP version of the code.
With this new position of collision information, the game Scene is now responsible for removing the brick at that location and also updating the score. This allows it to detect what brick was actually collided with so that it can (for example) increase the ball speed based on its location in the grid or it’s type (color, currently).
The speed increase itself is a percentage increase over the current speed, to account for how many possibilities there are in a single life for the speed to increase itself; the speed resets back to the default speed when you lose a ball. That finished up the ball speed exercise, and with that I moved on to the next exercise, the ability to earn extra lives.
Here I went for the simple idea of awarding an extra life every multiple of X points (30,000 in this case). This is because I decided to take the ball speed into account when it comes to the number of points scored for removing a brick. In the original code, it was always 100 points, but now there is a score multiplier that ranges from 1x to 5x based on how fast the ball is going.
With the ball speeding up more and more during a single volley and getting more score based on speed, this seems like an OK trade off for the time being because when you die it becomes harder to get more points until you’ve played a little while longer.
As you can see from the screen short above, the game always tells you where the next free life is going to be awarded so that you can track it. What you can’t see there is that I added a little bit of a visual tweak so that when a free life is awarded and it’s added to the display of lives (which above is empty because I suck), the new entry blinks for a little bit to call your attention to the fact that it happened.
The next exercise will be adding in music and sounds, which should be fairly simple to do as I’ve done that a few times before in other projects and I have a good idea of what music I want to use at the moment.
However, since it’s currently Canada Day and I’m a happy Canadian, that exercise can wait a little bit.