Building Space Invaders, Dashboard Style

BY anthony sapp
2011/03/02

As you may have read in Catherine’s earlier post – 2011 has ushered in a brand new look for Dashboard. Along with this new look came a re-vamped website, and we really wanted to do something fun and engaging on our main page – something fun, flexible and dynamic that would really represent our direction as an agency. We came up with a question-driven design that prompts visitors with various questions and depending on how they answer, they are treated to different content.

With the recent emergence of retro-style games on the web and more casual gaming on home consoles and mobile devices (see: Canabalt), and  considering we have several gamers under the Dashboard roof, having a game accessible from the main page was a must for our new site. We decided on a Space Invaders inspired game that would feature our new branding at the core: the goal being to break apart and destroy a large branding element. I was tasked with the programming.

Early Composite

So with the objective of building a throwback game that would engage visitors to the site, and knowing it would be based on a classic 1978 arcade game, my challenge was to make sure the game was simple enough for any user to play, challenging enough to entice avid (albeit casual) gamers, and to (of course) add a little Dashboard flair to boot. But how does one add flair to a game design that originated in 1978 and has been remade countless times since?

Having done the programming for the FWA shortlisted game / site Drive in Another Dimension, I was familiar with the Flash iteration of the prolific box2d physics library, so I thought adding some physics to the gameplay would be a good start. I decided to experiment with the World Construction Kit (WCK), a speedier implementation of the box2d library within the Flash environment due to its use of Adobe Alchemy. The results of the streamlined WCK library were awesome – I had an early game build up and running in a few days which included the ship, the evil enemy words, collision detection and the shooting all included. But that was when I hit the only major roadblock in the programming – small pieces of the enemy were supposed to fall off as bullets collided with it, so how would I design the enemy to allow for this? My first attempt was constructing the giant “WE ARE DASHBOARD” words out of hundreds of tiny pieces. Though the collision detection worked like a charm, the sheer amount of items on the screen was too much for the engine to handle. I was stumped – how would I achieve what the art director (Chris Obergfell) and myself wanted with this engine? Luckily, I had some time to mess around, so I decided I’d give a new engine a try – enter Flixel.

Canabalt - made using the Flixel engine.

I can’t even say how much this engine impressed me. The speed at which I was able to get another build of the game running – due to the impressive codebase this engine is built on, and its’ manageable learning curve – was nothing short of astounding. The engine is designed to build extremely speedy 2d scrolling games and it shows. Where it falters a little, in my opinion, is the collision detection. Even with a great 3rd party methodology for achieving “pixel perfect” collision detection, I simply could not achieve the precision I desired, so I tucked away the Flixel iteration of the game for a rainy day, and reverted back to the WCK build. Maybe if I could attack my earlier problem from a different  angle, I could achieve our desired result.

My second crack at it was a successful one. I knew the cause of the original build’s shortcomings was the sheer amount of items on the screen at once, so the first step, I knew, would be to scale back that number to optimize the collision detection routines. I finally solved the issue using this method: at the outset of the game the “WE ARE DASHBOARD” words are broken into rectangular “chunks” – like in the original build, but these chunks are much bigger. When a bullet collides with a chunk, that chunk breaks into smaller chunks, but only the exact point the bullet hit is destroyed. In this method, the amount of items on the screen at a given time is far fewer – speeding up the gameplay considerably because there are less objects to run through  box2d’s hit detection routines.  I went as far as to make the chunks comprising top portion of the word the largest – because I knew they’d likely be the last pieces contacted with bullets.

Diagram: final collision methodology

This breakthrough put me back on track to have the game completed for the launch of Dashboard’s new site. I even had time to add some bells and whistles – power-ups, background parallax and best of all, sound effects (thanks Kendrick!).

The best part about this project was that I got to experiment. It was one of those projects developers love because it gives us a chance to expand our repertoire and try new things. Often we are so busy we forget that there are other people just like us that are making incredible (open source!) libraries that make our lives easier; but also remind us that no matter how good we get as programmers, there is probably somebody doing things differently than we do, achieving better results, and challenging us to up the ante.

Stay tuned for more fun and games on the home page in the near future and by all means, if you have questions or comments, discuss below.

0

Comments |

Post a comment
Filed under: , , ,