Over the last decade our 3d cloud game engine gained more than a third of its 60 developers as Google Summer of Code students, many of whom stuck with the project and later became mentors themselves.

The ideas below are only a sample of potential project proposals. If you're interested in submitting one or more proposals to us, join #CopyleftGames on irc.freenode.net to talk to developers and help fleshing out your project idea(s). We can also provide some guidance on which project(s) to focus on based on a student's experience and interests, especially with "blue sky" proposals (projects not on this list).

As general advice, you should focus on the ideas that interest you the most. We select students based on the thought they put into their proposals and their demonstrated readiness to work with our community, not the "importance" of the project to us.

Generally, most of these ideas include work with 4 programming languages; C, Genie, GLSL, and Python. Students are expected to have some programming experience but not necessarily with any of these languages.

LightMelody

LightMelody is a cross-platform network library for open, federated game networking.

Authentication Mechanisms

Difficulty: Medium

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.

Game Support

Difficulty: Easy

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.

Peer to Peer Data

Difficulty: Medium

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.

Voice Chat

Difficulty: Hard

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.

Playerd

Playerd is a cross-platform service for associating players to input devices, handling player identity and preferences, and abstracting hardware to useful game input.

Bluetooth

Difficulty: Easy

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.

Controller Preferences

Difficulty: Medium

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.

Kinect Controller

Difficulty: Hard

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.

Playstation Move

Difficulty: Hard

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 Core

Astronomics

Difficulty: Medium

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.

Bookmarking

Difficulty: Easy

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.

Dungeon Master

Difficulty: Medium

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.

Improved Field Dynamics

Difficulty: Hard

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?

Landscaping

Difficulty: Hard

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.

Revised Audio API

Difficulty: Hard

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.

Shadow Rendering

Difficulty: Easy

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.

Soft Body Physics

Difficulty: Hard

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.

WebGL Rendering

Difficulty: Easy

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.

PySoy on Android

Android Build Suite

Difficulty: Medium

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.

Android Gamepad

Difficulty: Hard

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.

Android Game Editing

Difficulty: Easy - Medium

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.

Android Game Packaging

Difficulty: Medium

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.

PySoy Designer Tools

Blender Tools

Difficulty: Medium

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.

Dedicated Server

Difficulty: Easy

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 Plugin

Difficulty: Medium

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.

Integrated Development Environment (IDE)

Difficulty: Easy

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.

Video Gamecasting

Difficulty: Hard

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.

Web Publishing

Difficulty: Easy

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.

Original Games

When designing a game engine, the proof of the pudding is in using it to make a game. Each of these original game ideas will likely require more work on the engine than in the game itself, and in doing so, you'll blaze a trail for many others to follow.

Adventure

Difficulty: Variable

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.

Garden

Difficulty: Variable

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.