(Quick) Game Design Document for the May 18th game

High Level:

Jumping-based 2d platformer, where the player can switch from the top of platforms to the underside of platforms

(some) Details

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.

Nice-to-have features (in order of priority)

To keep the scope small, these are features that, while nice to have, can be left out if necessary:

• Collectable doodads
  • In addition to navigating a level, the player can choose to try to collect some collectable things in the level.
  • At the end of the level, the player will be informed Y out of Z doodads were collected. This will allow for more approachable level design while still providing engagement for more skilled players.
• Retry button/Key
  • Players should be able to choose to retry the level at any time
  • This will allow the level design to include traps that, the player must restart after entering (functionally similar to bottomless pits in a traditional platformer).
• Multiple levels
  • Platformers typically benefit from having pre-designed levels (rather than randomized levels).
  • Since that means that a single level will always be the same, that increases the value of having more than 1 level. Time permitting, I'd like to add several levels.

Reflections

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.