During the Feb 24, 2008 olpc dc meeting we discussed an olpc pong project based on gasp. Wiki pages need names, so for the moment this project is called GasPong. alternatives names are welcomed.
Mike Cariaso is a python programmer with an olpc g1g1 and previous experience teaching computers. He is interested in creating a game which utilizes olpc's unique mesh networking capabilities. Discussions with Wayan Vota, and Jeffrey Elkner suggested this as a worthwhile project for some of the LoCo students.
- develop a new game for the olpc
- learn the GASP api
- advance the GASP api
mentored group development for LoCo students
pong: see wikipedia pong
- paddle: the object controlled by a user. It tries to block the ball from getting past.
Only a very small subset of these features are likely for the actual release. They are intended to help everyone see what capabilities might be necessary, so that we can design for the big case, while building for the small.
1 player mode (A): standard pong. user plays against a simple ai
1 player mode (B): Breakout, shouldn't be too hard.
2 player mode: looks identical to standard pong. but each user is using the keyboard on their own machine.
3 player mode: a 3rd player controls a paddle which moves along the top of the screen.
4 player mode: each player defends one wall.
N player mode: 3 or more players each defend one wall of an enclosed N sided polygon.
the speed of the ball, and the width of the paddle can both vary for easier/harder modes.
The paddle can also be used to collect powerups which move like a second ball. These powerups could increase your paddle width, or influence speed of gameplay.
perspective: while the classic overhead view of pong should be supported, alternatives are possible. Since we will have each user looking at their own screen, they can each have their own view of the space. I'm particularly curious to move into more of a first person shooter perspective. In this way you would feel more like a goalie defending your goal. This metaphor may be more familiar outside the USA.
in this first person shooter mode, the user can be considered to be standing in a cloud which limits visibility as distance increases. The opaqueness of the cloud can vary per user and from moment to moment to create a more complex game environment.
The flash game curveball illustrates this fairly well.
The programming team should learn about and consider the MVC design pattern's applicability to this problem.
The application will also need to consider some of the challenges of Distributed Realtime Computing such as
distributed clocks Lamport timestamps
- handling dead nodes
- maintaining global state in a distributed app
- client server vs peer-to-peer architectures
I'd like to give some consideration to a laddering system as well. Players who fail to defend their goal well should eventually be removed from the main field to allow the best players to play each others. But as soon as 2 users have been knocked out of the main field, they can now play each other. This should open opportunities for interesting scoring and ranking systems.