Creating Brickbasher (just added a few days ago, but programmed in 2004) was one of my first eye-opening experiences programming small garage games. I have been a fan of Breakout style games since the age of 8 (read about the story here) when I first sampled the classic Atari 2600 version. What seemed like a relatively easy game to create became an exercise in frustration and a very humbling experience.

To start programming the game, I looked back and read a bit about how Brad Stewart, programmer of the Atari 2600 version created his masterpiece. The most notable thing I read was that Mr. Stewart divided the paddle into eight sections, so when the ball hit one of those sections, it would be sent in the proper direction. This seemed easy enough for me. In Flash, I created 8 separate hit areas on the paddle. Whenever the ball would hit one of them it would recalculate a new direction and update the ball to move in the direction. Easy huh? But I soon realized that there were not just “8” directions in which the ball could be moving. I also needed to calculate from which direction the ball hit the paddle. For instance, if the ball hits the left-most edge coming in from the left, it should send the ball back off to the left. However, if the ball hits the left most edge coming in from the right, it should have the same effect. However, with my simplified system, this did not always happen. coming in from the right and hitting the left-most section sometimes sent the ball back to the right, which looks and plays weird.

I also made another mistake programming this game that was much more costly. In 2004, Flash MX with Actionscript 1 was not a fully object-oriented language. However, I tried to treat it like one and thought I would be all fancy and program this game using design patterns. The Singleton and Subscriber models seemed like they would work very well with a game. Singleton is a pattern that makes sure you only have one object of a certain type created while you program is running. Subscriber uses a messaging model and has objects publish/subscribe to events of each other. Singleton worked fine, and I would still use it in any project where it was required. However, Subscriber was a disaster, at least how I implemented it. First of all, the messaging was slow. Much slower than just having my main game loop call functions of objects in an array. Secondly, I made the mistake of having each individual object run on it’s own interval. For instance, every brick on the screen checks for a hit with the ball on every frame. Stupid, stupid, stupid.

When I went back in 2006 to re-skin the game for Brick Basher Under Attack: No Way Out I was devastated that I had created such inefficient and ugly code. I started to re-write the whole mess, and I’m still in the process of doing that for the forthcoming “Brickbasher 2.0”. However I learned some very important lessons from the experience. First, nothing is “easy”, not matter what you think. Secondly, the latest and greatest programming “fads” do not necessarily make fast running, good games. I’m sure I will always make mistakes while trying create new games, but the real mistake would be not learning from them. That is why I posted these two games. They are not perfect, but they are part of an evolution. This site is not just about the games, but also about the process of making them. I will never be able to learn from my mistakes unless I can acknowledge having made them in the first place.