After pretty much a whole week of doing nothing, except talking about the idea for 10 minutes on the first
day, piman decided to write the game anyway. He worked on it for about 15 hours total in the last days,
and I made a few graphics in about two hours today. Talk about a wasted week.
Nevertheless, I'm quite happy with the result, even if it's really immature right now. Let's see how
well it turns out when we continue working on it out-of-contest.

(This is a copy of the postmortem post on my coding blog. Since I only worked on it for a couple days I didn't keep any notes during the competition, and so this was all written yesterday night. It's also really long. Hopefully someone else finds it interesting.)

I originally didn't intend to enter - especially after I lost half a tooth at the start of the week - but after coming up with an idea that it didn't look like anyone else was pursuing I put together a basic flight prototype. It was a particularly frustrating week at work so when I came home I felt like coding something of substance.

I think it's pretty good for the 10 hours of coding and 2-3 hours of art we put in. I don't think we've had any of the usual bugs which plague PyWeek entries like dependency hell, weird OpenGL bugs, or crashes in untested code paths. We kept the game simple and focused and made sure there was plenty of time for testing.

Controls
Feather Fall started as a controls prototype. Making flying feel really good was my main priority; all the game mechanics came later. Playing other PyWeek entries is sometimes frustrating for me. The controls are twitchy or unresponsive even in otherwise great games. So I think having our controls feel really good, even given shallow mechanics, made our entry stand out a bit.

The goal was to give the player an interface suggesting they might actually have to adjust two rotors strapped to their sides. The original version used an Xbox 360 controller but since not everyone would have that I switched to a keyboard. Placing the controls on opposite sides requires you to use both hands and using space for acceleration made it feel like a "big" action.

This is where it sat until Thursday/Friday, when I threw in the obstacle generator to add some challenge and the score counter to make it a game. Layer was incredibly useful during the early control tweaking stage. It's easy to add new entity control bits and the real-time physics constant tweaking let me hone quickly in on the behavior I wanted.

Level Generation
Since we didn't have any time levels are generated randomly with a trick stolen from Passage (in retrospect the scoring mechanics are very much a vertical version of Passage, although the controls are nothing alike). As you go up the obstacles get denser; as you go further from the origin they get more chaotic in size.

Jessica suggested picking up coins as a mechanic in addition to flying fast and far. It was easy to implement since I already had code for generating an infinite area of platforms and it made the initial flight up more interesting. It also increased the temptation to fly so long you ran out of fuel, hoping to compensate with more coins.

Last Minute Changes
Jessica and I had a disagreement about the game's scale for most of the development. She wanted a bigger main character that moves slower (in pixels/second) and I wanted a tiny player who moved fast with a larger visible game world. She drew the art, so she won. There were a number of hacks in the collision code to account for this (we didn't make the player bigger on the physics side - we made the obstacles invisibly larger). It still plays well and I think the scoring is balanced. However the obstacles are packed too densely too soon, so reaching the ground safely is an enormous score bonus.

One of the dumbest things I wrote was a failure to multiply the velocity by dt to generate the next position for the frame. Because the game ran at a stable 60fps for me I hadn't noticed, and since some of the factors were getting multiplied I didn't notice. Since the input to the acceleration comes from a total of 6 factors, the quickest fix was to dt *= 60 before handling the velocity. Whoops. In the end the physics felt fine, but the motion equations are the biggest embarrassment in the code. There were a number of other stupid but harmless problems in that code.

The Help Screen
I think my biggest success was the tutorial / help screen. Since we have a unique control scheme I wanted to make sure people at least knew what keys to press. I placed a starting line a bit above the player and made the game not really matter until the player passed it as well as a wall of text. You can test changing rotor angles and hopping around before you actually take off the first time. If you've played the game before, you can just hit space and take off and ignore it.

I'm not sure anyone has turned to our README.txt for controls, which is a win in my book (especially compared to some other PyWeek entries). We'll be shrinking or somehow changing the text in the future (probably making it a real main menu). It's too much for a non-PyWeek game.

Future Work
I've already done some major refactoring and cleanup of the project to account for the crap code written in the last couple hours of the competition, and to let us do some minor variations in the game mechanics. We'll probably submit it for Pyggy and definitely put a more final version on the Yukkuri Games site.