TMoD episode 3 Invasion

Before I begin, I would like to thank Andreas for providing me with keys for Texture Packer Pro and Physics Editor ( http://www.texturepacker.com/ ). I will be using and reviewing those tools in future posts.

This week I am going to take a bit of a look at Twelve Months of Doomsday Episode 3: Invasion which was released last week. As I said before, when creating a game that is paying homage to an existing (old by modern standards) game, I like to have my own twists to the game. Anybody familiar with classic arcade games knows the game "Space Invaders". In this game an army of aliens march back and forth across the screen trying to get to the bottom of the screen.  The obvious twist for this game is to have a number of formations. This is clearly not an original twist to the game as there are numerous games that did just this. My personal favorite Space Invaders variant would be Gorf.

To me, this is not enough of a twist, so I thought about having a different movement pattern. This got me thinking about another classic arcade game known as centipede. The neat thing about that game was that if you shot the centipede in the middle, half of the centipede would continue on it's existing course while the other half would immediately drop down a row. This would also give me the chance to have lines moving in different directions at the same time.

Implementing this movement logic was a bit more challenging than I originally expected. The core movement logic is easy enough. The aliens are put into "lines" where they follow the head alien which determines the movement for the line. Each alien simply tries to move to the location of the alien ahead of them. Dividing the line into two is simple enough. The new line gets flagged to move down so that is simple to handle. The problem is determining where the aliens can move to and if they have a clear shot. Checking against every alien to see if a collision was going to happen would be very inefficient. Granted, todays computers are more than fast enough that I could probably have gone this route. Instead, I break the play field into a tile grid and mark the location of aliens on the grid with the ability to reserve a tile so you don't end up with multiple aliens trying to go into the same tile.

As I didn't want aliens shooting through each other, this made checking if an alien was in the clear and could take a shot at the player was very simple. The grid is checked to see if there are any aliens in the same column as the alien. If not (and reserved tiles in that column count as aliens) we know that the alien can take a shot without hitting another alien.

The future is collapsing.

When I wrote my original version of Color Collapse last millenium, it was in C++ for Windows 95. At that time the shareware scene was still strong and I had noticed that there were a lot of Tetris and Columns clones appearing. My personal design philosophy is that if you are going to "pay hommage" to a game, you should always have something original or new to add to the game. Obviously, there are exceptions to this rule (such as for existing card and board games) but I've always tried to put my own twist on any game that I am developing. With Color Collapse, that twist was to have the game board filled in at the start and the goal of the game was to clear the board.  I don't know if I was the first person to come up with this idea, probably not, but I was not aware of any other game that did this when I originally created the game.

When I finally decided to play around with web development a few years later, I ended up having to port the game from C++ to the then relatively new Java platform.  Last year I was going through the games I have created for the BlazingGames site with the goal of seeing what games could have enhanced versions created for it and came up with a lot of new play modes and special tiles that could be added to Color Collapse so decided it would be a good upgrade candidate. Unfortunately, before I got that project started properly, my mother was hospitalized and later died of cancer. The fact that my mother really enjoyed this game both has me wanting to finish this enhanced version while making working on it emotionally hard. The fact that the 2012 meme can only be exploited once dictated my plans for 2012 so this years releases are pretty tied up.

For this reason, I have decided that 2013 would be the year I really focused on properly enhancing this game. My 2011 plans were to write the game in Flash. Now that everyone is writing Flash off, even though I personally think it will be at least until 2016 that Flash will remain strong, I am thinking that HTML 5/JavaScript is probably the route to go with this game. The game is not overly complex so there should be no issues moving the game to JavaScript.

The sad thing is that even that decision is not a straightforward decision. I can use my existing (BGLayers) library for the game. I can switch to another open source library which would probably provide me with better performance and more already implemented features. I could also wait and see what Adobe's Edge tool does. From the tiny amount I have played with an early demo of the tool it does seem like a JavaScript version of Flash but different enough that I would probably have a lot of re-learning to do. All this is assuming I want to write JavaScript using JavaScript. As it turns out, that is not the only option.

Alternatives to writing native JavaScript is Google's PlayN which converts Java into JavaScript and has a game library as well. Also from Google is their Dart language which is in early stages. Then there is CoffeeScript which seems to be gaining a fairly large following.

This is one case where having too many options is just as bad as not having enough. About all I can say at this point in time is that the Color Collapse Plus project will be the site focus of 2013 (subject to change due to unforeseen factors or the incredibly unlikely event that the world really does end) and will be in HTML 5. The how is the tough question.