User:Bjordan/GSoC 2008

Spray Play and the Google Summer of Code 2008

I'm Brian Jordan--see my introduction to the OLPC GSoC community here. I created Spray Play with my brothers Greg and Eric during the Boston Game Jam during the summer of 2007. At the end of the < 3 day development period, we demoed Spray Play for a group of local schoolchildren and their parents, and their enthusiasm for the game won us the OLPC Award, which included passes to the Game Developers Conference 2008.

Project Summary

What is Spray Play?

Spray Play is a physics-based action game based on the board game Crossfire. Players (represented by an XO character) aim their character at the puck and spray (or shoot) projectile circles at it, attempting to move the puck into the scoring area on their opponent's side of the playing field. Shot balls stay on the playing field and slide to a collection area behind the XO characters.

Spray Play currently uses a quick-and-dirty collision detection algorithm for physics and includes sound effects bound to certain game events such as shooting (thwoop!) and ball-puck hits (clink!).

The game was originally developed during the Boston Game Jam and playtested by local schoolchildren (observed by their parents) brought in at the end of the weekend to rate games. Spray Play was rated the most fun game at the jam, and won the OLPC Award.

Spray Play has been tested on the XO, but was unfortunately found to be too slow to play reliably with enough balls to make it fun. This is due to both the algorithm used for collision detection and the efficiency of the functions used for drawing.

Screenshot

Spray Play playfield with computer player

Elements and Spray Play

Spray Play's speed problems will be addressed by rewriting the game using the Elements physics engine, which also allows for easy changing of drawing platforms.

Elements is a project that has recently implemented support for the Box2D physics engine. Box2D has been used to create physics demos such as MIT Sketching and games such as Crayon Physics. Elements is a SWIG wrapper around Box2D, and has been shown to run well on the XO (see: Physic_Engines/Speed_Tests). The functionality of Spray Play's current physics implementation is a subset of the capabilities of Elements, and the projects would be a perfect fit.

This week, I have been discussing this project with Chris of the Elements project and getting acquainted with the Elements codebase. The speed benefits that will be gained from changing to the Box2D physics engine may also be bolstered by Elements' modularization of drawing code. This will allow me to change the graphics engine used if testing shows drawing calls to be a significant bottleneck.

Puck Edit Phase

Currently, after a point is scored, Spray Play resets the game board with a different shaped puck. During the GSoC, I will implement a simple Crayon Physics-style drawing mechanism that allows players to draw their own shapes to be used as pucks.

Entrance

After a point is scored, an "E" key and pencil icon will pop up on the screen for three seconds. If this key is not pressed, a random puck will be chosen from the default puck set.

If this key is pressed, the player will be in edit mode and allowed to draw a shape / group of shapes with their mouse on screen.

Drawing

Drawing, much as was done with Crayon Physics and similar projects, will create rectangle-segment hollow shapes for Box2D.

A limited amount of ink for shape drawing will be available, both to cut down on edit time and control the possible complexity of the resulting physics interactions.

Playing

An icon reminder to exit puck edit mode ("E" key and OLPC joystick icon) will be displayed after three seconds of idle time after having finished a shape. After seven seconds, the game will automatically switch to play mode.

A discussion of the technical aspects of puck edit mode is included in the Development Discussion section of this document.

Physics Sound (API)

Graphics are only a piece of the puzzle that is creating an engaging, social game. The creation of a rich sound environment is a high priority for the development of Spray Play. In the most recent version of Spray Play, I bound sound effects to be triggered during ball shooting, puck hits, and ball to wall collisions. The difference in experience between playing with the sound off and sound on is staggering--sound feedback is vital to the game experience. But this game-logic-based sound design is only the beginning.

For GSoC, I will work with the Elements project to implement physics-based sound effects.

Imagine, playing with a physics based simulation, you hear the...

• crunch as one box hits another (collision velocity)
• whoosh of a puck that's been hit into a fast rotation (rotation speed )
• scrape of a "metallic" triangle sliding on the ground (friction coefficient)
• tap, tap, tap of a "marble" dropped from above (collision/elasticity)

GetAngularVelocity() GetLinearVelocity() http://www.box2d.org/manual.html#shapes

Sound Sets (API)

A common issue among sound design for videogames is that of repetition. The problem is eloquently described by Andrew Boyd, who noticed while working on the videogame Blood Wake:

The 'chain gun' sound presented a difficult problem. [...] We needed to make a rapid-firing weapon sound that was powerful and impactful, could be listened to for extended periods without becoming irritating, and was able to support multiple playback instances simultaneously.

Solutions for this problem of repetitive sound effects are presented in Boyd's article, the thesis "Computer Games - Problems with Audio" and "Footstep Sound Effects". Multiple versions of sound effects can be recorded or processed to sound slightly different, and then played back in a random (or semi-random to reduce doubling) order. As I did sound design for the games Kuku and 3D Pong during the Boston Game Jam, I made sure to provide multiple versions of each effect and instruct the teams on using simple random-play methodology.

To benefit others using pyGame and developing games (even other applications) for the OLPC, I will develop an API for sound sets--groups of multiple sounds to be played interchangeably in different modes (e.g., random, random weighted for non-repetition, and footsteps) to allow for simple, better sound design. Sets can have sound effects added, modes changed, and sounds played/stopped (one-time and continuous). Sound sets will operate with pyGame, with the goal of eventual integration into the pygame.mixer API.

Logistical Notes

Eligibility

I am an enrolled second year student at Wesleyan University, and will be enrolled in 2008-2009 as well.

Mentoring

I have been discussing this project and the portions that would improve the Elements project with User:crazy-chris

Development Discussion

Elements/Box2D Sound

b2ContactPoint fields: id normal normalForce position separation shape1 shape2 tangentForce