At the moment the game type is a scrolling shooter, which was chosen due to being the easiest to code.

So here is my take: focus on varying content within the scope of the game, and also focus on making the code easy to expand. The mechanics of the game itself should remain simple however. -this means that enemies should widely vary in appearance and difficulty -the players ships should be able to undergo a wide variety of changes or bonuses -the background should possibly vary widely -there should be an intricate story if possible

My reasoning is this: We have to make the game fun, if anyone is going to pay a quarter to play it, and content that changes throughout will be a good hook. I personally play a game until I think I've seen what it has to offer, more so than to get the high score.

I would also suggest that the game be made steeply progressively harder, so as to attract people who care about the score more.

Issues

Raspberry Pi limitations

One issue that comes to mind is the abilities of the rapsberry pi. Is it capable of running something as visually intensive as say: Tyrian? How many instances can it take of objects at a time, does it have enough memory or processor power? Will a simplified art style help reduce the effect on the processor? (-Mennypunns)

The Raspberry Pi has 512 MB of RAM and has an ARM11 32 bit CPU that runs at 800 MHz (overclocking is available through Raspbian (without voiding warranty as well). My (very) quick estimation is that this will happily run any game we throw at it, unless we step out of the realm of 2D graphics. (-Douglas)

#Needed Code

Player Object

An object for the player's ship(s) that is able to display a picture, detect collision with that picture, modify that picture under certain events, keep track of variable related to itself, such as health, shield, and score, and ideally, extensible, meaning that a block of code can be added to add functionality, without having to modify the rest of the code. This will need to, via sequence to be determined, be able to appear on the left side of the screen and respond to player controls.

Most of this will be covered by the Sprite object of PyGame. The Player object will be extending Sprite. (-Douglas)

Enemy Class

And object for enemies or obstacles, these can be significantly simpler than the player. Need variable for health at the minimum, in addition to the same abilities to display and gather information regarding a picture. I must emphasize that it is an extremely bad idea to try to create this code individually for each enemy, it is better to have an object or class for all of them, and use children code for variance. These need to be able to create instances relative to themselves, that can affect the player (i.e. shoot at him) If we do it this way, we can also use these same objects to create a starry background.

Menus

Menu's will require...a lot of small objects will extremely little coding per each one.

Misc.

Small objects for miscellaneous purposes: bonuses, displaying visual effects, showing the menu, showing player stats, showing high scores...that kind of thing.

#Suggested Game Type Side Scrolling Shooter set in space directly above the earth atmosphere.

The ships and obstacles will be viewed from their sides as opposed to their top or bottom. -issue, will have to draw so that objects appear 3d This will make things like upgrades/bonuses easily visible if we want to implement them.

#Suggested Mechanic: Atmospheric burn Descent into the earth atmosphere too far will turn the ship red, drain shields (if implemented), and then drain health. Going too far will cause the ship to catch fire and fall off screen. This applies both to this ship and to enemies.

#Suggested Visual: Randomly generated star background James can be credited with this: The stars can be made with a series of star objects that vary in size randomly and also move at differing speeds relative to the players constant speed. -issue, in addition to enemies, this may be too hard on the raspberry pi's processor. We've already seen how well it can handle a bunch of squirrels, not well.

#Suggested Visual: Layered transparent starry background moving at different speeds. This will produce a less extensible star visual than James suggestion, and will take up more ram, however it will be immensely kinder to the processor, which may make it a better option if that turns out to be a premium.

#Suggested Visual: Launching sequence from a pad at the beginng of each level. Self Explanatory.

#Suggested Visual: Slightly tinted background that changes over time. -If the stars are all white, the whole screen minus the player's ship and enemies ships, could be tinted a certain color that could indicate progress in a game. Whether or not we use a format that has levels, (would suggest that as it would help hook completionists) it would be nice in my mind if the color the stars were tinted changed over time to show how far you are. Say at the beginning of a level, the stars are all slightly tinted blue, then they become green about a third of the way, then they become orange in the last third and red right near the end. Then for special levels you use a different set of colors.