• About
  • Google Summer of Code
  • Google Summer of Code 2014

    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 #PySoy 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.

    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.

    Bluetooth

    Difficulty: Medium

    Bluetooth is used for game controllers, headsets, and syncing data with mobile devices. PySoy has some initial support for bluetooth on Linux, but it could use much more focused attention.

    What would you do to make using bluetooth devices in PySoy easier or better integrated? In-game controller and headset pairing? Windows or OSX support? Support for moving games seamlessly to/from paired gaming devices?

    Write up your proposal with your vision on where PySoy's bluetooth support could be, UI mockups, code examples, and your roadmap for implementing it.

    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.

    Controller Preferences

    Difficulty: Medium

    As we're just now getting our various clients polished up and ready for players, we've hit the point of needing to handle player preferences and configuration.

    Every player is expected to have an XMPP account which is used for buddy lists, network chat, retreiving game catalogs, providing identity to game servers, etc. XMPP also supports storing private data which can include their personal controller preferences.

    Our goal is to minimize per-game configuration by allowing players to set their preferences once for every PySoy game. Player preferences retreived from their personal XMPP storage will be used to determine their default configuration. Most of the work for this will be in the XML parsing to controller setup.

    Your proposal should include some example XML and a basic flowchart for how the input devices map to actinos in PySoy demonstrating your solid understanding of this project.

    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.

    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 PySoy's abstracted controller API it should be possible to add Kinect support to any PySoy-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.

    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.

    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.

    Wii U Gamepad Support

    Difficulty: Easy

    Add support for using the Wii U GamePad in PySoy as a new client or plugin which renders to the gamepad screen and supports its input devices.

    This is made much easier thanks to libdrc and the abstracted client API we already use, but a good deal of work is still needed to make this easily usable with games.

    As this could be implemented in a number of different ways, draft out your ideas and pseudocode mockups in your proposal.

    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.

    Jump and Run

    Difficulty: Variable

    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.

    Strategy

    Difficulty: Variable

    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.