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

Post them all here.

It would probably be better if people played the game before reading this. But there are probably no major "spoilers" in here.

So I originally intended to only work on this the first and last day since that's the only time I really had any time for this. Well, actually, I didn't intend on participating at all since it was during a very busy week. But then I got a good idea the first day and felt complelled to implement it.

I ended up working on this for 3 more evenings during the week and also took some time during lunch to find content.

Answers to some never asked questions
-I start story mode and nothing happens. I just see a screen with keys and what they do.
The game starts out paused (Delta t=0) so just press p to unpause.
-How do I jump on the last level?
Press z. You can't jump in the previous levels.
-Why can I jump only once?
You can jump more than once but it takes quite some time for it to recharge. When you can jump, a "z" appears at the top right of the screen.
-Is level 7 really possible?
Yes, but I have to jump twice. Once after w=8 and once for the final jump.
-This game is too hard. How to I cheat?
Uncomment the only line that says #self.mq.lives=2
-Why does the animation in level 3 look wrong?
See the first point in the To do list at the end.
-Why does the quill move forward and turn slowly? Isn't this an action game.
I wanted this game to be more about planning ahead than about reflexes. But actually, it turned out that many levels can be solved if you are either good at planning or have good reflexes (except possibly the last level, where you might need a bit of both).
-Why can't the shapes/polytopes solve their own problem?
They only exist "on paper". Initially, I wanted to make it more obvious that the quill and S^20 only communicate with each other through the surface the quill is on (and then the sphere would only see the shadow of the quill and of course, vice versa).

Collision detection
I originally thought that having collision detection would be too slow because of the number of line segments to intersect them with. This wasn't even close to being a problem so its good to know for the future that drawing continuous lines using line segments is a very doable thing (I was already start to think of ways using fewer segments and circle arcs).

What did cause a problem with collision detection was the arithmetics (see previous journal entries for this). No more problem occured after that. I meant to but didn't have time to implement the suggestion.

Duration
I think that I (accidentally) made the right choice in picking a project that I originally thought could be done in one day. I got more and more ideas as the week progressed (many of which I didn't have time to implement). The original idea was just a quill pen drawing on various topological surfaces. If I participate again, I'd want to make a game of approximately the same complexity (unless there were other members, of course).

Content
I knew well beforehand that I couldn't generate graphics, sounds or fonts. And this is not because I lack the time to do so (although, I do lack to time to do that). What came to a surprise was that content that was appropriate was very hard to find (needed it to be some kind of free license and have it all fit together somehow). Even the quill itself took some time. In fact, I spent a lot of time removing transparent pixel from the one I did finally find. It would definitely be interesting to know where other participants find their resources (and why these sources are good). I used the links on the pygame resources page but I think there are better things out there.

Complex numbers
Using python's built in complex numbers worked surprisingly well for managing 2d points although I don't think this is their original purpose. This also made rotating easier later on (e.g.,:*1j for pi/2). It was also useful when I wanted to specify a point in polar coordinates rather than Cartesian.

To do list (which time did not permit)
In approximate order of "priority":
-Show the line "This animation has been modified to fit your monitor and mind." to the animation at the beginning of level 3. I kept forgetting to add this and it ended up not in the current version. This is the explanation for not seeing higher dimensional polytopes despite the text refering the them (in fact, the code itself does allow the drawing of the higher dimensional ones).
-Add an ending screen. I already vaguely know what I'd want to put there but its far too specific to be found on the internet (except maybe for copying and pasting).
-Add a second ending screen (There are currently two very slightly distinguishable endings for those who've noticed. That's because two endings were intended.)
-A boss level.
-Fix the level menu so that the "Back" button isn't drawn off-screen.
-Add more game modes, each of which includes some of the following features.
--More shapes with effects when you are inside (e.g., increase/decrease (turning) speed, springboard that makes you automatically jump)
--Don't make you "teleport" when you hit a pasted edges. Instead, just rotated/flip n copies of the base n-polygon and paste them there.
--Use the camera to scroll (its implemented but never used in the current version).
--Together with the above two features, don't draw the boundaries anymore (the player has to figure out the topology by seeing their own trail, which they can of course draw in a specific pattern for easier recognition).
--Together with the above, make the screen turn rather than the quill.
--Make the bounding polygon change (like in story mode, but randomized or make it increase its "difficulty" periodically so there is an advantage in acting fast.)
-Allow players to enter a scheme and play a custom level. This is almost implemented but currently, the code needs to be changed manually by either changing the "allschemes=.." line or the "self.scheme=..." line for story mode and survival mode respectively.

Dear Everyone:

Are you finished 'Feather of scale' ?
I haven't finished it. but I enjoy to write it.

Frankie
P.S. Is it a 'Die-Hard-Game' ?

Abbey was having a bit of difficulty using the keyboard to play the game. She's not comfortable using multiple keys at once and even then often has to look to find keys.

So I've added WiiMote support :)

Actually it's a bit of a hack at the moment because I couldn't get any of the OS X bluetooth / wiimote libraries to work. I ended up installing DarwiinRemote and configured it to generate keys appropriate for my game (with the remote held sideways and buttons 1 & 2 used for spell & jump).

I'm going to look into PS3 controllers next...

It's been pointed out that Linux needs timidity in order to handle MIDI. This affects HIIW too, since it also uses MIDI music. I've tried to arrange things so that it will continue working without music if support isn't there, but I haven't tested that.

No, not continuations, but rather where I'm going with the game now :)

I gave a quick off-the-cuff presentation to MPUG last night showing how my game evolved and grew over the week. I used a checkout from my local bzr repository from when I finished each night. I'll be giving a better version of that presentation at this weekend's BarCampMelbourne.

I've been refactoring the player control/update code to clean it up. I'm also planning on writing proper cocos layers for my SVG layer loading using squirtle. This should clean up the game rendering and management.

I've got a couple of other local changes to cocos that I need to check over before committing too.

I wonder whether pyggy could do with being a couple of months shorter?

Well, we've elected to continue working on Chickenstein, since we all love the idea.
Personally I am finding a lot of the bugs in PYGGEL simply by using it, so that is great as well.

Today I sat down and fixed the last remaining outstanding bug (lose chicken gun if you swap weapons) and worked on optimizations.
With just 30-45 minutes of work we've doubled the FPS of the game O.o

So you can expect more interesting and intense levels in the future XD

if you're trying to play Pratfall! on linux and having weird crashes and no music, make sure you have timidity installed.  the game uses midi files for music and although it's not super clear from the pygame docs this requires timidity to be installed on your system.  apparently it doesn't just fail gracefully if timidity isn't present.  windows doesn't need anything else since windows comes with a softsynth in the base operating system.

So, PyWeek is over and so am I... really I'm dead after soo much. But it was quite fun participating so I'll be looking forward to the next compo, and this time I'll make sure to have my libs and planning done so my code won't look like a complete mess of locals and globals flying everywhere and almost no classes whatsoever.

Anyways, things went quite the other way around in this week. At first I had no idea at all for the feather theme, but then I just thought of merging all themes into one big game, so it should be easier. Well, somehow I guess it was. Doing a platform was quite fun, but I completly skipped the planning part and midway through the game I had was completly different from what I had in mind.

The original plan was really a math-ish puzzle game, where you would have to toggle switches to activate paths and portals, but I planned maps a lot larger than the ones I ended up making. Then I remembered pygame alone is not the best to make update-the-entire-screen-every-frame games and dropped the idea. Then I just focused on getting some functional stuff done and started writing a lot of codes at random.

The results, although I did made it to the deadline, weren't that great. As you can see by looking at the code (please don't do that, most of things there are sorta shameful .-. although there are something useful I wrote on the last days of the compo, like the novel manager thingy) everything is a mess and most of things I wanted to do I couldn't just because I spent a lot of time doing things that I needn't either because I could just pick up some lib or go without it. The complex map module I wrote at first was one of those all-not-needed things. I really didn't need something with lots of frames where player would have the ability to jump and such.

After all I had a lot of trouble editing code and some bugs resulted from this. Like sometimes if you press escape and select don't exit the game, the game will keep asking if you want to exit what is sorta annoying. There's also a bug in collision system where feathers will just pass right through bugs but won't kill them, but this should be something with the mask module, I didn't had really much time to work around this, but some bounding box collision should work perfectly here.

In short, there's a list of things that didn't work to me in this compo:

• Did no planning whatsoever (my todo lists couldn't be taken as a planning)
• Spent precious time working on the wrong things.
• Made a mess of locals and globals on the code, which leds to bugs and difficult to edit the code.
• Spent precious time doing nothing but looking at the console screen waiting for some brilliant idea to pop up out of nothing.

Things that I learned during this compo:

• How to use bitmasks and pixel-perfect collisions in pygame
• I should make plannings before go writing things at random
• I should use OOP to get things more organizated

So, I'm ready for next PyWeek, with a bit more of knowledge on how to make a game. And hopefully next time I'll have a fun game that won't have a completly messed source code.
Btw, I guess I'll keep working on this game, maybe I can get something interesting out =D