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:

Used a known technology

– 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.

Code for reuse

– 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.

Using Airplanes

– Airplanes look cool and don’t require animation for their idle, moving and attacking states.

Low rez pixel art

– 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.

I cut all the features that didn’t produce a game. I added a simple menu, high score, and timing system. The last 20 minutes have been me uploading like crazy.

I am very satisfied with this Ludum Dare, and hope to see you all next time.

GG all

Obligatory screen shot:

After a ton of sprite work, (you can’t see i this image). I have the game playable. You can kill enemies and die. There are some particle effects and weapons choices as well.

Tomorrow I will add a re spawn system, some new enemies and weapons and call it done ( I hope).

I can’t stay wake any longer.

When the contest first started I planed to make scripted missions, which now seems like a bit of a waste since I spent most of my time making the engine, and drawing the sprites.

The new plan is to make a random environment and have the player wandering around it killing stuff for money.

I have been up for 25 hours now (stupid work). I finally implemented the bullet collision and health system. So now I can shoot down bot controlled planes. Playable link is still:

http://www.monkeydev.com/unity/ld20/ld20.html

I am going to catch a few Z’s. When I get up I will make new graphics and get started on the real AI.

Thanks to the wonder of Unity, I have a player and 3 bots flying around four way points. The planes are temporary, but the ground is finalized. I spent 2 hours working on it.

Playable version up at:
http://www.monkeydev.com/unity/ld20/ld20.html

So my basic concept is to do a top down air combat shooter. The Player’s aircraft has one hard point and no fixed weapons. It’s dangerous to go unarmed, so the player should take this Rocket pod, Machine gun, or Torpedo. Each of these weapons have a very limited use and the player must return frequently to the mother ship to rearm.

Jettisoning the spent weapons pod will improve flight characteristics, but may detract from a limited supply of gear for the mission. I have yet to decide.