Contest Link
Web Player Link

Intro:
Air Pirates was developed in a very fluid way, meaning the game I was planning and the game I ended up with varied greatly over the course of development. Many of the game’s features were thrown in at the last minute and not properly tested. However the core components of the game I wrote at the start of the contest were flexible enough to accommodate these wild design changes.
What went Right:
– I decided to use Unity v2.6 because I been using it for over a year. I knew the names of the native classes and functions that I needed, and how they work. I tried Unity 3 at a friend’s house and I found the slight difference in interface jarring.
– Many of the classes I wrote in this contest pull double duty, or more. The AirPlane class for example was used for the player, airship, and friendly/ hostile fighters. The texture and performance difference between these objects were implemented via public variables changed in the editor.
Just because I can doesn’t mean I should
– Unity has a terrific feature set including physics, shaders, and animation blending. But to take advantage of these features I would have to sink a great deal of time building 3d assets for them. Instead I went with 2d Sprites attached to a square polygon which always faces the camera.
– Airplanes look cool and don’t require animation for their idle, moving and attacking states.
– My art pipe line for the airplanes went as follows: Make a hand drawn sketch on graph paper. Scan sketch and resize it to 128×128. Trace sketch on new layer. Bucket fill with solid colors. Add shade and highlight with color offset. Using a pencil sketch caused me to worry less about exact pixel placement. Using fewer colors gives the game a clean retro look while allowing for palette swaps.
Knowing when to cut my losses
– As you will read in the “What went wrong” section not all the features I wanted made it into the final product. At 6 hours to dead line I decide I should stop messing around with the cool stuff and make a game out of this. Had I continued to dick around I would have release a really cool tech demo instead of a game.
Want went Wrong:
Was too ambitious with original concept
– I have wanted to make a game involving epic battle between airships and airship launched prop fighters for a while. Needless to say the game did not end up like this and I wasted a good amount of time laying the foundation for features that would not be implemented.
Not enough time spent brain storming
– I was writing code less than an hour after the theme was announced. I did not spend much time figuring out what the finished product should look like. I knew I wanted to do something with airplanes and interchangeable weapons pods, and assumed I would figure the rest out as I went along.
Didn’t do long term tests
– I tested my code frequently, but most tests were a few seconds long to make sure the latest feature worked. As such a game breaking bug with the enemy respawn system slipped though. If I had played the game for over a minute I probably would have spotted and fixed this bug.
Didn’t sleep enough before the contest
– The contest started at 7pm on Friday for me. I tried to take a nap after work, but was too excited about the upcoming contest to get any rest. My first night of coding suffered from this.
Didn’t think of the end user experience
– I got too caught up in how much fun I was having implementing the features that I didn’t take into consideration how the game would feel as a whole.
Conclusions:
Using the Unity engine to implement a simple sprite based game saved me a lot of time. Its editor, GUI , and particle features allowed me to make a much more complex game than I would have been able to make from scratch in the time provided. I regret the lack of planning and testing that resulted in the bugs in the final version.