Twelve Months of Doomsday episode 5: Asteroid Attack

Episode 5 of my TMoD series has been released on Blazing Games so this fortnight I will discuss some of the design decisions that went into the development of this game. While this game is clearly inspired by the classic arcade game Asteroids, it is much more inspired by one of my favourite movies: The Empire Strikes Back. While Asteroids had aliens in it, they were more of an afterthought. I wanted my game to focus on battling aliens not on shooting asteroids. To do this, I made the asteroid field much bigger so the player would actually have to navigate through it and I made the rocks much harder to destroy.

The big problem with making asteroids hard to destroy is the basic fact that navigating using momentum based movement like the game uses makes rapid dodging difficult. To address this problem, I decided that giving lasers some form of impact value would be a good way of solving this problem. Shooting an asteroid will then either alter the course of the asteroid or cause it to break apart.

One of the great aspects of being a game developer/programmer is that you control the laws of physics. I based the amount of impact that a laser has based on the radius of the asteroid instead of the mass of the asteroid so lasers will have a much greater effect on larger asteroids than they should. This decision was made largely based on intangible factor: the feel of the game. This is actually one big advantage of doing small games. You are able to finish the game while the game is still enjoyable so playing the game yourself actually gives you meaningful feedback. When you are spending years working on a game, unless the game is one of those rare exceptions, you will be sick of the game as you reach later stages of it's development.

Originally the game was going to give the player a limited number of lives and the player would not re-appear until the coast was clear. That really didn't fit well with the story, so I decided that the player would only have a single life but would have a shield that would flash when they were hit with a limited amount of shield. This also allowed me to make it less damaging to bounce off an asteroid than to be hit by an alien laser.

Aliens were a lot more dangerous in earlier builds of the game as they would home in on the player and would start shooting at a fair distance away from the player. This difficulty was reduced by making the aliens wander randomly while trying to keep away from asteroids and not shooting at the player until they were fairly close to the player.

While I am sure there are a lot of people who disagree with me, I was quite happy with the way the game turned out.

Flash Professional CS6

I was really considering staying with CS5.5 unless there was a compelling reason to upgrade. Flash CS6 really didn't provide that reason, but as the upgrade price for CS6 for CS5.5 owners was half the price of the normal upgrade price, it was pretty compelling. When I found out that the Web Premium package was being combined with Design Premium, it would mean that a program that I wanted but couldn't justify was now part of my upgrade. InDesign is a desktop publishing application. With all the additional features in the other apps in the suite, the upgrade became a no-brainer.

If I only had Flash, not a suite, I doubt even the reduced price would have been enough to justify upgrading. I hope that I am wrong, but I really get the feeling that Adobe is abandoning Flash. Still, it is a tool I see myself using for many years to come. Perhaps not as a game development platform, but definitely as a tool for creating animations for the games. With Air packagers and Stage3D, it is possible that Flash will remain a platform for game development. As I have the tools, I have decided that I will play around with the starling framework and possibly try some low-level stage 3D work.

Still, for web development, the move to HTML5 is clear. Thankfully, Flash CS6 provides some tools for aiding in this migration. A few weeks ago I looked at a tool for creating image strips. This functionality is now built right into Flash. Likewise, there is a plugin for converting animations over to the CreateJS suite (which EaselJS is part of). While it is a great feature, it does not convert the ActionScript into JavaScript. Had this capability been in CS6, Flash professional would have instantly become the best tool for HTML5 development. ActionScript is a far nicer language to work with than JavaScript so the ability to write in ActionScript and compile to JavaScript would be well worth the price of Flash Professional. Yet another case of Adobe being blind to what they already have.

The thing is, both ActionScript and JavaScript are derived from the ECMAScript standard. ActionScript just happened to be based on a specification that was abandoned due to politics and infighting. Personally I think JavaScript would have been a much better language for web development had ECMAScript 4 passed. Since the underlying language is the same the version would have been backwards compatible. While I understand that some people think JavaScript should be easier, as the web moves towards JavaScript even larger programs will be created in that mess of a language so thoughts of dealing with large scale programs should be at the forefront as that is what the web ultimately needs.

In fact, the languages are so close that I think a quick porting tool could easily be developed so as a side project for this development blog, in future weeks when I don't have other things to discuss, I will look into the issues of writing such a tool. Even though I don't want to add yet another project to my overflowing plate, I just might develop such a tool as part of this blog. I know in the past I had looked for such a tool and while some projects existed they did not work the way I needed. Perhaps it is time for another look.

TMoD episode 4: Space Shield

When researching different disasters the idea of a solar flare was high on the list. The big problem was finding a classic-style arcade game that would work with the theme. Thinking about how to stop a solar flare lead to the obvious placement of satellites, even though realistically you would need way too many. Placing satellites immediately got me thinking of the space junk problem that we are having. This immediately got me thinking about the road-crossing games I played on my cousins Atari 2600 so the game was set.

One of the big issues with the game was the collision detection. Unfortunately, Flash does not have per-pixel collision detection (at least not built in to Flash Player 10, I haven't researched Stage 3D or Starling enough to know if Flash Player 11 does). The object detection is bounding box based. Point based detection does support a per pixel option so I set off on my task to write a simple per-pixel collision detection routine. I originally opted for a simple brute force approach. Flash let's you find the bounding box of a clip relative to a container, so getting the bounding boxes of the two colliding objects then finding the intersection of the two objects is easy. My thought was then to look though the points in the intersection rectangle to see if they both flag collisions at the same points and are therefore overlapping.

In my tests this worked great. The problem is that my tests used vector shapes. When bitmap images were used, anything within the bitmap bounding box was flagged even if it was transparent. There is really no excuse for this other than lazy or incompetent programming at Adobe. This meant that I would have to look at the bitmap data myself. Sadly, this is not a very efficient thing to do.

To get the pixel information, I need to draw into a bitmap data object. This first requires getting a copy of the transformation matrix used to draw the display object. Thankfully this is easily accessible. Next, a translation is applied to only draw the intersection portion of the image. The drawing is done. Repeat for the second object in a second BitmapData object and then compare the pixels in the two bitmapData objects. As this is done using a getPixel function call repeatedly, I honestly can't see this as being very efficient. Then I remembered an article I read about using color filters. This got me thinking about how I could get rid of one of the bitmapData objects  and combine the two images into one.

First, you set the bitmapData background color to black. The draw function supports color filters making it possible to max out or clear a color channel. By maxing the red and green channels while dropping the blue channel of the first image then dropping the red channel of the second image while maxing out the green and blue channels of the second image while drawing it over the first image using the ADD filter you will end up with white pixels where the two images overlap. There is actually a built in routine for finding a bounding box containing a particular color so finding the overlapping pixels is easy.

This is not the best way of doing the collision detection, but it works. There are some edge cases where it won't work, but that isn't a problem in this game. It is sad that such a straightforward thing requires so much work.