PyWeek - kuri Games
AwardsRatings (show detail)Fun: 2.8 Production: 2.9 Innovation: 3.0 Respondents: 21 |
| Files: | Uploader | Date | |
|---|---|---|---|
| FeatherFall.zip — final | 470.62 Kbytes | piman | 2009/09/06 00:08 |
| Final entry (fixes zip folder issue) | |||
| screenshot-2009-09-05-17.02.04.png | 58.31 Kbytes | piman | 2009/09/06 00:04 |
Friday 11 September, 2009
[ piman @ 04:14 ] Feather Fall Postmortem
(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.
Sunday 06 September, 2009
[ Jessicatz @ 00:13 ] LAUNCH DAY
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.