Here's a postmortem on the project:

What Went Right

1. Unity. Even though I was making a 2D game, I used Unity to manage it all. With a single model of a two-polygon plane, I was able to display all the game elements I needed with little trouble. Unity is great for rapidly prototyping games, and I was able to bootstrap the core gameplay and iterate on it quickly.
2. Pixel art. I am not an artist, so pixel art really lends itself to my game jam projects because it makes my "programmer art" passable. I'd like to say I did it because it's cool and retro, but really, it's because I can produce it quickly and it looks halfway decent. I'd used pixel art in last year's compo ("Heart of Stone"), and it worked so well, I decided to use it again, and it paid off. I am especially proud of the dancing characters; even at the low resolution and constrained color palette, it's pretty clear what they're doing most of the time. And the bad guys have a lot of fun touches to them, such as the motion on the tank firing, the "fall in the pit" animation, and the death animation for the characters when the punk throws his knives.
3. Fixing the aspect ratio. Games that scale to any aspect ratio are great and all, but for the time-limited environment of a game jam, the last thing you need to do is figure out how to gracefully scale graphics horizontally. I settled on an aspect ratio at the beginning of the project and locked it in, which gave me the freedom to just design as I go without being constrained by what I might need it to do if the ratios changed.
4. Simplifying the graphics and its pipeline. With two dancing characters, I knew I'd be in for a lot of art creation and animation, neither of which I am particularly good or experienced at. Plus, I don't know how to Tango, so I was at a big disadvantage for creating the art for the game I had in my mind. So I drastically simplified the characters, the motions, and the manner in which I would display them. It paid off huge dividends because I was able to get a lot of detail in the game without a lot of overhead. And by having a simple "billboarding" system for displaying the characters, I was able to quickly see changes in-game while popping back and forth between Unity and Photoshop.
5. Not being too ambitious. Half the ideas I had for the game didn't make it in to the final build. I was pretty aggressive with what I cut. For a game jam, that's a good thing, because I figured it was better to deliver a finished, polished end product than to have something that lacked polish and approachability at the end. My game is playable from start to finish, it has a presentable opening, little start-of-game and end-of-game flourishes, and a solid ending to the game. It feels complete. Sometimes, getting to that point is the hardest part of a game jam, because you spend all your time focused on the game and don't leave enough time for the other stuff that help players get into the game. But you do have to cut stuff to get to that point, and that is really hard to do when you have a creative idea you want to pursue.

What Went Wrong

1. Heavy animation needs. The vast majority of the time was spent drawing little pixelated characters in Photoshop. There are over one hundred animation frames in the dancing characters alone; all told, I produced upwards of 200 or more pixel art assets for this game in less than 48 hours. It was almost too ambitious, but worse, it was pretty tiring and draining. There was so much art to produce, it was pretty daunting for a non-artist like myself, and it contributed a fair amount of stress to the project.
2. Hard-to-reproduce bugs. I had a few bugs in the game that I was still chasing down on Sunday morning, such as multiple enemies being able to kill you at once. I was pretty sure I'd fixed them, but it was difficult to actually test things like enemies deciding to attack at the same time without writing a testing scenario that would force it to happen. Doing that would be easy enough, but I didn't want to take the time to do it. Any programmer worth his salt will tell you it's always worth the time. And they're right; I probably spent more time trying to reproduce the bug than it would have taken me to just write that test case.
3. Unfamiliarity with the language. I'd used Unity before, but it had been a while. If I was smart, I would have boned up on the language a bit before diving in for a game jam. I thought I remembered it well enough to be productive, but I kept getting hit by little "gotchas", like trying to use C syntax for variable declarations, or forgetting that MicroSoft inexplicably wants to name functions with capital letters, but properties in lower case, but then they expose functions with dot-notation properties with inconsistent naming, so I was always having to guess at things like "is it foo.length? foo.Length? foo.count? foo.Count? foo.Count()? Argh!" Just a day brushing up on the language would have saved me a fair amount of time during the game jam.
4. Bad control scheme. I'm still not happy with the control scheme I have for the game. I feels clunky. Once you get the concept, it's easy enough to grasp and use, but it still feels pretty difficult to control. I had some ideas on how to address that, but I didn't have time to implement them in the span of the competition, sadly.
5. Pixel art. It was a strength, but it's also a weakness. Looking at the games other teams produced, everyone is doing cool-looking 3D games with animated characters and 3D environments. Some people will like the retro feel to it, and I do think I was able to convey a whole environment by constraining the graphics, but once these games get into the judges hands, my game won't have the same eye candy level that other participants' games have, probably. I don't know what I could have done to address that - there's no way I could have done dancing characters in 3D - but it's a reality my submission is going to have to compete against in the final judging.