In this week’s update, ts-breakout gets a little pixel love thanks to Kenney Vleugels and his Puzzle Pack 2 (which is also where the paddle and ball graphics for ts-tennis came from, although it appears I did not credit that at the time. Sorry Kenney!).

This brings exercise #6 to a close and, according to Plain Tasks, gets us 35% of the way through all of the exercises for this particular game. Hooray!

Now, why was this so much harder than I thought it would be?

Just when I think I can’t possibly have more hubris about my ability to determine how much time a particular gamedev task will take, it knocks me down another peg.

This time around, I knew that I was going to use this graphics pack for the tiles, so the first step for me was to determine exactly how large I wanted the bricks/ball/paddle to be. I was never really satisfied with how skinny the paddle in the original prototype was, for example, nor the bricks.

As a result, although the actual time spent to size the graphics as appropriate, set up sprite sheets, and add in the code to use them for rendering was very slight (as I thought it would be) I actually managed to spend far, far longer than I was originally thought on trying to decide on just the right balance of brick size.

On the one hand, a larger brick size is nicer on the eyes (and more cartoony/stylish for what I want to achieve) but at the same time it severely limits how many bricks there can actually be on the screen, which is a downside. Getting the brick count up where I wanted it to be makes the bricks be an unsatisfying size. Suddenly the ball seems too large, and the paddle is all out of proportion. Chaos!

In the end I settled on a size that I can live with, and increased the number of rows of bricks a bit. This has the effect of bringing the bricks much lower down on the screen, which makes the initial stages of the game a little tricky. On the other hand, the plan for a future exercise is to design custom layouts for the bricks, and so I decided that this allows for more freedom at that point, so it’s good to have them be low as an acceptable range.

A screen shot of the final result, from a game in progress:

If you are a GIMP user, that background might look a little familiar to you. I am by no means an artist, and some looking around for a nicely sized and acceptable (to me) looking image of the variety that I originally wanted (tiled neon looking hexagons) did not turn up many cost effective (i.e. free) images. As a result, I ended up using the GIMP to generate my own seamless tile.

The code that preloads the background image is fairly smart; if it gets an image larger than the stage, it clips it into a new image, while if it is smaller, it creates an image that is a tiled version. This keeps the preload times down (for smaller images, anyway) but run time rendering a bit faster.

I also set up sprite sheets with multiple kinds of balls and colors/shapes of paddles, with an eye towards future enhancements (maybe a sticky paddle should be red or multiple balls should be a variety of colors).

I was going to blast through exercise 7 for this week as well (render lives as icons and not as a number) but then I couldn’t decide if I should use images of the paddle, or of the ball, or how big they should be, or what position (top or bottom? left or right side of the bottom?) so instead I took a step back and played a little KeeperRL.

Sometimes you just need to gain a little perspective, you know?