In a follow-up of last week’s update (and terrible pun), this week brings the completion of the last exercise and some pondering on the next one; multiple brick types. This is one of those situations in which I have spent more time considering options and ideas than I would have spent actually just implementing something (anything) and calling it good enough. I’m still not sure if this is a sign of a little growth in the game design arena or just my regular desire for everything to be perfect to such a degree that nothing ever happens. Certainly there’s not a lot of growth in the “terrible pun” department.

I finished up the exercise from last week, which was implementing a few different brick layouts for use in the game. I had my sights set on roughly 10 to start with, but in the end I stopped at 5. The reason for that is primarily due to thoughts about the next exercise. In that one, the goal is to make some bricks different than others, such as requiring more hits to destroy or being invincible.

My notes say that this was to be quickly implemented as just a function of the color of the actual brick; say that a blue brick takes a single hit to destroy and a red brick takes two hits to destroy, so when you hit a red brick, just make it blue. However I like the idea of NOT doing that and in fact actually having a little bit of visual “decay” on the blocks.

In order to do that a little more meta information would be required to carry more information on each brick location, which is not a big deal for the BrickGrid entity, but it would require a little extra data in the levels as well. As a result of this, I decided to stop at just 5 levels while I try to decide how exactly to go about this.

I want the solution to be quick and easy (no sense in burning a whole lot of brainpower for a generic breakout clone, of all things) but I also want to strike a balance where I try and extend my design abilities a little big and venture a little into newer territory. Just doing the same old stuff over and over again is not likely to cause much growth.

My first thought is something similar to Rx; create a new entity (e.g. Brick) that knows how to render a brick as a given image or a given color, has its own internal value that indicates how much “life” the brick has along with the ability to overlay some transparent sprites to show cracking as “life” is diminished, and so on. Once that’s done, all of the logic for bricks would be pulled out of BrickGrid and placed into that entity and BrickGrid would gain just an array of Brick instances.

This has the added benefit of each brick theoretically knowing exactly where on the screen that it’s currently placed, which would make the collision testing between the ball and the grid a lot nicer. That’s something that I don’t think is the subject of an upcoming exercise but is still something that I’d like to tweak a little bit more to match the level of detail that the paddle uses for collisions (e.g. stopping the ball at the point of intersection).

While I think on that and do a little more design brainstorming, I leave you with an example of one of the simple brick layouts I came up with. As an aside to this, doing even a little level design here had made me wish that I settled for a brick column width that was an odd number to make symmetrical things a little nicer to create.