Traditional, single-factor username:password authentication is increasingly being phase out in favor of newer authentication techniques such as Oauth2, Persona, and X.509 certificates.

Add support for one or more of these mechanisms to LightMelody. This will typically involve some interaction with web browsers and writing small, customizable webapps.

This project would including working with a number of different languages, experience with HTML and Javascript will be extremely useful.

There are many free and open source games which have poor network support. Replacing a game's existing network code with LightMelody could both improve the game overall and help polish the library for use in other games.

Your proposal should include the game(s) you want to work with, the existing network support you'll be replacing or extending, and what features LightMelody will add or improve.

Game server hosting can be made more affordable and scalable by allowing clients to share game data peer to peer. Adding support for this to LightMelody would allow many games and game engines to support this feature with little effort.

For your proposal, draft up an outline on how this could work both as a protocol and in the LightMelody API. Cite existing code and protocols you can build on and advantages/drawbacks to your proposed approach.

Most of this project can be done in C and/or Genie.

Expand LightMelody to support multiparty voice chat using XMPP Jingle, FloraFox, and Opus codec for WebRTC compatibility.

There are many forms this may take, research and propose how you'll implement this from protocol to user interface, including any web-based components it may require.

A majority of this work will use C libraries and potentially Javascript.

One of the nicer features we could provide is the ability to pair and manage bluetooth devices from within games.

While providing nearly identical functionality, each OS (Android, Linux, OSX, Windows) has its own bluetooth API, each of which needs to be supported though not all necessarily for your project.

Draft up a mock UI and API for your proposal, along with how bluetooth can be supported seamlessly with hotpluggable HID devices.

Minimize per-game configuration by allowing players to set their preferences in playerd as defaults for every game in addition to per-game configuration which overrides this.

As player accounts are typically XMPP accounts, preferences should be stored in XML format. Your proposal should include some example XML and a basic flowchart to demonstrating your solid understanding of this project.

There are existing libraries for Linux, Windows, and OSX for using a Kinect, however, very little in the way of game support outside of specific XBox titles. With playerd's abstracted controller API it should be possible to add Kinect support to any playerd-based game.

This would involve use of libraries such as OpenCV to identify the player's limbs and guestures, with different guestures representing different actions. The player should be able to configure this just as they would any other controller.

Given the complexity of this task, in your proposal we'd be looking for details on how motion tracking and guestures would be identified, how to get very basic input working early on in your project, and what changes may be needed to the core engine to support this as an add-on module.

The playstation move controller has a lot of interesting potential for playerd, being less expensive than a Nintendo Wiimote and working with hardware most players already have (eg, webcam vs light bar).

Supporting it would require access to the webcam and potentially libraries like OpenCV to track the light ball.

Most of the difficulty in this is interfacing with webcams on different OSs and ideally serving as a virtual pointing device, so low level device experience is a plus.

PySoy provides several options for scenes which offer different types of 3D environments, one of which is soy.scenes.Space which is intended for astronomically large outer space environments.

One of the issues with Space is overcoming the Z-buffer's limited resolution which we've previously solved with multi-pass rendering. Another issue is rendering complexity with superlarge astronomical bodies (stars, planets, moons) in the background but which the player could actually travel to and potentially even land on. At the same time, we would not want to waste limited processing capability on rendering small asteroids and ships too far away to be seen. Given this is for gaming, we also don't need to run a complete planetary system scale physics simulation for every rock and piece of debris on the server unless one or more players is near enough to see it.

Include in your proposal a pseudocode or flow chart outlining your rendering and physics processing chain, describe how a game designer would create her own planets and planetary systems, and a draft API for soy.scenes.Space along with any other classes you'd develop for your project.

PySoy is designed primarily to run games on servers which clients can play without downloading. Games can be found through app stores, social media, game catalogs hosted on their developers' websites, or by catalogs browsed on the PySoy clients themselves. However they're originally found, players should be able to return to games they enjoyed easily.

As every player needs an XMPP account to connect to the game server, we can use this same account to bookmark their favorite and recently played games. As these bookmarks are stored on their XMPP server, they'd be available on any device they use automatically.

The XMPP bookmarking code should be relatively straightforward, but support for it would involve handling a good deal of client UI code. Proposals for this idea should include UI mockups, a description of the work you expect will be needed in both the core engine and clients, the XML format of the bookmark entries, and how SGK data will be stored or reliably referenced from the bookmark entry.

PySoy provides several options for scenes which offer different types of 3D environments, from a single room to landscapes, but we don't currently have a scene for one of the most common game environment: the dungeon.

Dungeons are caves, fortresses, space stations, or other expansive buildings where a network of rooms are connected with tunnels or hallways often filled with puzzles, monsters, and treasure. From easier level design to collision detection, there are many reasons to provide a dedicated dungeon scene class.

As this is a new class, you have a relatively blank slate for ideas to implement this. Your project proposal should be a blueprint - from API, to level designers, to faster collision detection.

One of our Google Summer of Code 2007 students worked on "Field Dynamics", which took the form of "field" objects in 3d scenes which pushed, pulled, floated, spun, or otherwise influenced the movement of 3d bodies in their range.

Fields have remained in PySoy since, but could really use an overhaul. We'd love to see buoyancy and wind actually act on the volume and surface of bodies, color and/or surface texture properties to support optional field rendering, optimizing field effect processing so they can be used more heavily even on mobile devices, and generally cleaning them up and fixing up the fields that aren't working anymore.

As we already have a basic Field API (see soy.fields), we're looking for details on how you intend to implement or improve these fields; eg, how will you calculate submerved volume for buoyancy, how will your Wind class calculate surface area and angles better or faster, how would you support reducing the number of calculations to tradeoff accuracy for speed on slower (eg, mobile) devices?

PySoy provides several options for scenes which offer different types of 3D environments, one of which is soy.scenes.Landscape which currently is just a heightmap.

We could do so much better - background (LoD) terrain, 3d grass shubbery and trees that blow in the wind, clouds, weather effects like rain lightning and snow, the ability to tile multiple Landscape scenes together into a much more massive outdoor environment, and all of these features still providing the game designer near-absolute control over artistic style.

In your proposal, present your master plan for making Landscape scenes awesome. We want to see details on poly/texture reduction for slower platforms, rendering hacks to allow easy detailed background terrain and weather, and a proposed API for tiling multiple scenes together into a larger world.

Design and implement a new audio API for PySoy.

The API should support pre-recorded audio samples in .soy files, recording audio (which can be stored in .soy files), receiving live streams over RTP, and sending live streamed audio. All audio will use the Opus codec and playback may be either attached to soy.bodies (3d positional audio) or a soy.Client (regular non-positional audio).

The API should also contain access to adjust sample volume, playback time, and a way to mark samples as sound effects, voice, background music, and potentially other categories which a client may want to adjust volume independently for in the client UI. Samples should also be able to be marked for language with multiple samples for different languages supported per sample object in addition to supporting timestamped subtitles.

Client UI such as selecting which audio devices to use for input and output, adjusting global volume levels, and language/subtitle support is out of scope for this project idea.

Your proposal should contain a rough API design along with a roadmap to implement it. We will be looking for thoughtfulness and use-case consideration when evaluating your proposal, though its fully expected that the API will need to evolve (along with your roadmap) over the Summer.

Rendering shadows in OpenGL is a subject of countless papers and discussion, but PySoy currently doesn't support rendering shadows - a task which may potentially include revising our entire lighting system.

For your proposal, research and propose which method(s) you'll implement for rending shadows keeping in mind the broad range of devices PySoy runs on.

Most of this project will be working with GLSL, though if you have experience working with C-like languages you can learn this during your project.

Up until now PySoy has had only rigid body physics (implemented by ODE). Bodies cannot squish, bend, or otherwise deform in response to collision - only bounce without changing their shape. With soft body physics, bodies would gain a number of properties which determine if and how they change shape when they collide.

At the core this would likely include a 4x4 deformation matrix passed to both the vertex shader and used in the second-pass collision detection. Remember that this is rough game physics, not scientific or engineering physics simulation, so speed is more important than accuracy. Consider both our primitive shapes (Box, Sphere, Cylinder) and Mesh, as well as how fields could distort soft bodies outside of regular impact collisions.

Your proposal should contain a rough API design along with a roadmap to implement it. We will be looking for thoughtfulness and use-case consideration when evaluating your proposal, though its fully expected that the API will need to evolve (along with your roadmap) over the Summer.

We recently migrated PySoy to render using OpenGL ES 2.0 which brings us very close to WebGL support. One of the next steps in a HTML/5 plugin-free client is implementing our render cycle in pure javascript with WebRTC used for networking.

In proposals to work on this we're looking for an understanding of how this can integrate with our existing engine, thoughts on keeping the existing codebase clean and managable, and considerations for expanding this work into a full javascript-based game client.

Javascript experience strongly recommended.

While we have a simple build tool (Waf) used on every other platform our Android builds use static and shared libraries from different sources, a mix of different build tools, and a set of incomplete directions which are difficult at best to follow. As a result, our Android versions are always lagging behind.

Waf is entirely Python-based and is easily extendable, it would be fantastic if we had an Android NDK plugin as part of libsoy which could be run with simple commands like ./waf build_apk and output a library APK, or even ./waf install_apk to install it on a connected Android device via adb.

Part of this project would be refactoring SweetSoy to separate it into two separate packages (libsoy and SweetSoy) and updating SweetSoy to work with our modern API.

Add support to SweetSoy for using an Android device as a fully featured game controller, similar to the Wii U GamePad, using the input devices of the phone/tablet (accel, gyro, touch) along with its screen.

Most of this task is setting up the P2P inter-client negotiation over mDNS since SweetSoy in this configuration would also connect to the game server directly for its independent screen. Much of the complexity in how to setup the different screens can be left to the game with the default being to mirror.

Proposals for this should include sketched UIs for this (including on-screen controls), ideas on the new P2P negotiation protocol, and some game pseudocode for supporting two clients with different screens being used by the same player.

PySoy's primary purpose is to empower players to create and mod games easily, however, thus far our Android client has lacked any real tools for editing games. We'd like to compliment our current Android support with a variety of game designing tools.

We would love to see project proposals for remotely editing Python code running on a game server, 3D mesh editor designed for multitouch interfaces, or a scene/level designer with simple drag and drop interface. In your proposal, describe and diagram what the user interface would look like, how the user will interact with it, and the deigner's workflow from their phone or tablet to the game server.

Our Android support is currently in the form of a PySoy client called SweetSoy. SweetSoy serves as a game catalog, allowing players to find PySoy-based games and launch them without installing a separate app for each game. We would like to provide an alternative game distribution method for Android whereas games can be published to Google Play.

This should come in the form of a utility which accepts a .sgk file (Soy Game linK) and produces a .apk. These game APKs should be very small; an icon, metadata, and some boilerplate code that loads libsoy (published separately) and connects to server specified in the .sgk.

In your proposal, we'll be looking for your thoughts on how to handle cross-game configuration (XMPP login, controller settings), if and how the per-game boilerplate code could be minimized, and what other pieces will need to be completed for this to work.

Blender is a popular free software 3d modelling and animation package. While Blender has its own builtin game engine, its also commonly used to create 3d objects for games using other engines which have different rendering models and features.

The ideal workflow for artists using Blender to design objects for PySoy-based games is to be able to open a PySoy frame in Blender itself and thus see their changes in realtime while running PySoy in Blender's embedded Python.

In your proposal, we'd be looking for your research on the API hooks you'll need to use in order to demonstrate your understanding of the project and include mockup UI for how it could look.

PySoy games are developed and run in Python, but when running a game on a server we'd much rather have a dedicated server application which runs in the background and provides standardized game administration. This dedicated server application could be written entirely in Python.

Game administration functions such as listing players, disconnecting players, banning players, blocking IP addresses used by abusers, etc could be provided via XMPP to admins (by JID). A simple Python wrapper to run a game in the background is trivial, much of this project would be adding support for those administrative functions to PySoy.

We'll want to see a pseudocode mockup of the server along with a description for how it'll load and manage games in your proposal.

Most or all of this project could be written in Python.

GIMP is a popular free software image editing program which is useful for editing textures. Textures, however, are not just images which leaves a lot of room for improvement.

It'd be fantastic if artists could see the texture they're working on mapped onto 3d models as they're working on it in a preview window. This would require plugin hooks for whenever an image is updated so the texture data can be updated respectively.

Another big improvement would be mipmap editing. Mipmaps are lower resolution versions of textures for further away objects, but depending on the artistic style a game developer may want to enhance certain features (thicker outlines, better contrast) which requires the ability to edit any or all mipmaps of a texture.

Since textures are applied to many triangles, it may also be useful for the outlines of those triangles to be shown over the image (like a grid or guides do), perhaps even with the ability to change the texture coordinates for those triangles.

These are just a start. Write up your vision for a GIMP plugin along with UI diagrams and references to API hooks you'll need to use.

Build a highlighted text editor using PySoy widgets which allow developers to edit PySoy game objects while the game is running. This is primarily useful as a learning tool for youth running local copies of games, but may also be valuable for game developers doing quick remote changes to their running games.

Existing Python modules such as ipython or bpython may be used for code highlighting, editing, and saving - but any of these packages will need PySoy-specific support both for the UI and data visualization.

Most or all of this project could be written in Python.

One of the best ways to promote new games is with gameplay videos. While there's a variety of 3rd party tools for screencasting, these often require a lot of CPU power to encode the videos in realtime and result in degraded game performance. Recording uncompressed HD video frames to disk for later encoding would cause the same problem by taxing disk I/O.

A possible solution to this is to record the state of the game in realtime, then play back that state to render and encode frame by frame offline. This could be done with a Python script, GStreamer, and extending the core engine to support recording and playback.

Expand on this for your proposal, if and how this can be generalized as a standard engine feature, how to integrate this with social media, and what changes specifically will need to be made to the core engine to get your offline video encoding script working.

While we've made many considerations to make publishing a game to the web easier, and a few XSL templates for generating HTML/5 previews of games, a big part of our overall decentralized game networking plan includes game developers being able to host their own game catalogs.

The webapp will need to connect to XMPP to process live game data and player profiles, generate raster versions of SVG game icons, and expose metadata through a variety of standard conventions (HTML/5, OpenGraph).

PySoy publishes games as SGK (Soy Game linK) files, which are SVG game icons with game metadata added in dublin core format. With your proposal, detail the workflow for game developers to setup a self-hosted catalog, including any web frameworks you plan to use, and demonstrate a simple XSLT to generate OpenGraph metadata from a provided SGK file.

Most or all of this project could be written in Python.

Design a 3d adventure game where you control a character moving through a world filled with treasure, enemies, puzzles, and a story to play through.

In your proposal detail what PySoy classes (current or future) will be used, how dungeons and terrain will be designed, and mockups of your artwork.

Design a garden game where different seeds are planted, cared for, and sold at market to buy upgrades with cooperative social elements.

In your proposal detail what PySoy classes (current or future) will be used, how levels will be designed, and mockups of your artwork.

Design a basic side-scrolling "jump and run" game (think Mario Bros, Megaman, Little Big Planet) with power-ups, obsticles, enemies, bosses, and multiple levels.

In your proposal detail what PySoy classes (current or future) will be used, how levels will be designed, and mockups of your artwork.

Design a basic realtime strategy game (think Starcraft) with resources, units, buildings, and combat.

In your proposal detail what PySoy classes (current or future) will be used, how will terrain be developed, and mockups of your artwork.