Tom Astle

[Bullet Blocker--Post Mortem]
Bullet Blocker has problems; I'll be the first to admit that. It has problems, but at the same time, I learned so much in the process of making it, that I'm ok with that. Bullet Blocker was my first completed game, and I always intended to do a Post Mortem for it. After seeing it flop around in the wild for a bit, I think I'm finally ready to deconstruct this guy. I'll start off with the design of the game, then I'll move on to its graphical evolution, and finally, I'll end with the monetization and public release.
Original Concept
If you've ever heard of the Bit. Trip series, chances are you've noticed the striking similarities between Bullet Blocker and Bit. Trip Beat. I feel that I need to address this head on, because the games truly are very similar. I really want to stress that this was nothing more than a huge coincidence. The mechanics for Bullet Blocker sort of evolved into what they are currently.

I originally wanted to make a kind of "reverse shooter". I wanted to make a game where the goal was not to dodge enemy bullets and shoot enemy ships, but to catch enemy bullets, or maybe reflect them back. My first prototype of the game had it so that the player's goal was to catch the bullets that the enemies shot. Whenever the player caught a bullet, the enemy that shot said bullet would explode, and any enemies caught in that explosion radius would explode as well. It was a sort of chain reaction game. The enemy explosion rings that you see in the final game are remnants of this mechanic.
The explosion rings that enemies give off when they die are remnants of the original chain reaction mechanic.
I still needed some way for the player to lose, however, and so I added a life bar. Every time the player got hit by a bullet, they lost health. This made it so that the player had to try to destroy as many ships as possible at a time, because they lost health each time this was attempted. I thought it was an interesting risk/reward scenario. From there, I added some bullets that would not destroy enemy ships when caught, and would only hurt the player. It was at this point that I dumped the chain reaction mechanic. It was difficult to remember which enemy shot which bullet, and because of that, hard to gauge what a chain reaction would actually do. It was, however, fun to block and dodge the bullet patterns. Realizing that, it wasn't much of a logical leap to arrive at the current mechanics of Bullet Blocker. I realized about halfway through the project that the mechanics were almost exactly those of Bit. Trip Beat, and at that point I had gone too far to change them without basically starting over. By the way, Bit Trip. Beat is a much better game than Bullet Blocker, so go play that instead.
This is a better game.
Controls
I waged a bit of a war with these guys. The original controls for this game involved the arrow keys only. I assigned the right and left arrows to up and down movement. It was a bit strange to get used to, but felt fairly natural after a bit. The reason I used these keys instead of the up and down arrow keys is because the natural way to press the up and down arrows has most people using the same finger for each, which slows reaction times. Using left and right for upwards and downwards movement, however, is a bit counter intuitive at first. That combined with the acceleration and deceleration of the paddle, meant that most players were finding the game extremely difficult to play. To counter this, I added the ability to play the game with mouse controls. My friends reported that this pretty much fixed the problem, but I still received negative reactions from most of the other people who played.

The problem was that I left in the acceleration and deceleration of the paddle. I did this to ensure that the paddle wouldn't move any faster with the mouse controls than with the keyboard controls. All the levels had been designed with keyboard controls in mind, and changing the way the paddle moved would have broken some of the levels, and made others way too easy. If people stuck with the game long enough to get used to the controls, I received fairly positive feedback from them, but most people seemed to get irritated with the controls very quickly, sometimes even attributing the slow paddle movement to lag, and gave up within the first few levels. Looking back on this, I should have made the paddle follow your mouse 1:1, and just redesigned the levels that needed it. If I really wanted to keep the movement, I might have been able to help the problem by adding a visual aid; maybe a line from your paddle to your mouse that illustrated the elasticity of the movement. In any case, not addressing this was a big mistake, and the strange controls, paired with the unrelenting difficulty, made this game extremely inaccessible to the average player.
The levels started off way too hard. Unrelenting difficulty, paired with the paddle's strange, elastic movement, made this game very inaccessible.
Graphics
Graphics were one of the most difficult aspects of developing Bullet Blocker. I'm not really an artist, but I wanted to do the entire game on my own, which meant that I had to do the art myself as well. I did end up buying music, but we'll ignore that. I spent a long time on the game's graphics. Originally, the final look for the game was some pretty standard programmer art.

At this stage, I was actually seriously considering just calling the game "Working Title".

This is not a good level select screen.

And the award for the most boring looking game goes to...

I quickly realized that if I wanted to sell the game, the graphics were going to have to change. Because of that, I re-did a few things. At this point, nothing was really distractingly terrible, but it was still really bland; it just didn't stand out at all.
Looking better, but it's got no emotion to it; no style of its own.

Again, this is better, but it's still pretty bland and easily identifiable as programmer art.
It was time for an overhaul. The game had no style or theme, it was just kind of badly abstract. I still wanted to do all of the graphics by myself, however, and so I needed an art style that I, someone without considerable art skill, could pull off decently. The solution was, of course, to make it intentionally bad. As long as it was consistent throughout the game, doing all the art as if it were doodlings in a kid's notebook would allow me to draw badly, but still give the game a consistent and interesting theme.
Crappy, but consistant.

Little did I know, cords extend from the front, not the back of computer mice.

Nothing amazing, but it has its own style and doesn't immediately scream "programmer art"!
Well, that's much better isn't it?
Public Release
Well, after a long and arduous, but ultimately successful search for a sponsor, the game was picked up. Due to events outside of my control, the game took roughly a year from the date it was sponsored to be publicly released. By that point I had had considerable time to contemplate the game and pick it apart. I wasn't expecting much out of the game's release. I hoped that at least a few people would get enjoyment from it, but I didn't at all expect a positive response. True to my expectations, the game was a flop. It was met with a 2.52/5.00 rating on Kongregate, a 2.80/5.00 on Newgrounds, and received mostly negative feedback. I was definitely disappointed, but ultimately, it was a flawed game, and it got about the response it deserved. At this point, I was working on other things, and I was just happy to have the game released.
Monetization
Money is something this game didn't make too much of. I sold an exclusive license to Pinkyarcade.com. My only source of income for this game was the sponsorship price for this license. I also had a few expenses. I bought web hosting and this domain name for two years, and I licensed some music. All together, that added up to a $196.75 cost. The game was generously sponsored for $500.00, which meant that my total profit was $303.25.

In the end, the amount of money I made off of the game was not much, and ultimately not enough to be worth the time I spent on it. That's ok though, the experience I gained from going through this process was considerable, and I don't regret a thing.
Parting Thoughts
I think that everyone's first completed game must hold at least some place in their heart. Looking at it now, I'm actually not that proud of Bullet Blocker. I don't think it's that good of a game, and I wouldn't want to show it off to people. It's too difficult, has bad controls, is not programmed well, and its mechanics are too similar to a certain other game mentioned above. Despite that, I can't help but be fond of it. It was my first foray into the world of indie game development, and it only left me wanting to try again. I learned a lot: some neat game design tricks, why you shouldn't code in the timeline, some of Flash's irritating eccentricities, just how hard it is to finish a game, and just how rewarding a process it can be.

I hope this little Post Mortem has been interesting. You can play Bullet Blocker here. It'd be cool if you enjoyed it, but if you don't, that's ok too.

-Tom
Thanks for reading!