Play the Html5 game (if the game appears too small, try using a larger zoom):
Thanks for playing!
Original design document
Jumping-based 2d platformer, where the player can switch from the top of platforms to the underside of platforms
Player can move a character left/right around with left/right arrows, and jump with the Up/Down/Space key.
The goal of the game is to navigate from the starting position to a goal.
If the character falls further than X distance, instead of dying or taking damage, the character will flip from the top of the platform to the underside of the platform.
While on the underside, gravity is reversed (hence why 'Down' is a jump key)
Like on the top, when the character falls X distance on the underside, the character will flip back to the top of the platform.
To keep the scope small, these are features that, while nice to have, can be left out if necessary:
Original writeup- immediately after completing the project
I am very pleased with the improvement that extending the deadline provided. I was able to hit many of the Nice-to-Have features, as well as provide some additional extras (such as auto-saving progress.) Admittedly, some of that may have been also due to working in Flash, with the Flixel game engine, which I have used before for other game prototypes, but, based on where I was last Sunday (no collectables, only 2 levels), the extra time really paid off.
One technical lesson I am particularly pleased about was learning how to make a psuedo-abstract class in ActionScript3 (the Flash language). Although the language doesn't have any built-in support for abstract classes, I was able to accomplish something similar by simply creating a base class that used a dummy implementation for the properties that I wanted to be virtual. Using this approach, I was able to consolidate all the map-building logic into one base class, and then simply have each individual map only responsible for defining where to find the layout and images for that specific map. This turned the process of adding new maps into a 5-minute thing (excluding the time spent actually making the map). It was also way more manageable, when I had to make changes to the base behavior to support saving. (I am now thinking about ways make this abstract base map more generic, possibly as a set of basic behavior I can add to any future game I want to make.)
One thing that I did wrong, however, was putting off getting the flash game on the site until the release day. I underestimated the complexity of getting Flash to play nice with a browser (for example, I added the "Click to Play" screen to work around an issue where the game wouldn't accept keyboard presses.) For future games, I am going to include all the desired browser-flash (or browser-whatever) details in the design doc, under either Nice-to-Have or Required; that way I make sure I properly allocate time for them.