Summer of Code

About Google Summer of Code

Flip code, not burgers. Google is sponsoring students to work on Open Source projects this summer. To learn more about this program see the Google Summer of Code website and the Summer of Code FAQ. You can also find a some advice for students here.

Worldforge collaborates with both CEGUI and Ryzom during the program, and you'll therefore find ideas for these projects listed here too.

WorldForge in the Summer of Code

Find our proposed projects below. You can see past projects at the Past GSoCs page.

Requirements

General Prerequisites

• You should discuss your application on the WorldForge General mailing list before submitting. Note that you need to be subscribed to the list before you can send a message to it.
• You should have the time to work on the project all summer.

During the Program

• You need to provide a weekly progress report.
• You need a Github account where you keep your forked projects.
• Provide your patches early and often.
• This is not exactly a requirement, but it would be nice if you could hang out on WorldForge IRC during the program. This will make it easier to get feedback from other project members as well.

Helpful Links

• Communication channels A nice summary of the communication channels used by the project. New members should start by using the mailing lists (go for the General list), but day to day communication mostly happens on IRC. We also have a specific forum set up for the SoC.
• Application Template The application template we would like you to use when applying.
• Compiling Ember A requirement is that you can compile and run Ember. Due to the large number of required libraries this is not always straight forward, hence this guide.
• Ember development General information on current Ember development (bug tracker, blueprints etc.)

Ideas List

For Summer of Code projects, we recommend working on the Ember client. This is a summary of suggested projects. The full specifications can be found as blueprints on the Ember Launchpad. Note that these are all just suggestions. If you have another idea that you want to see implemented, don't hesitate to submit that instead. It might also be a good idea to talk with the developers first about your idea. Use the mailing list or the forums, or reach us on irc. Most of the developers are based in Europe and are logged on in the evenings.

Ember Ideas

The following ideas represents examples of what we think would be suitable tasks. But keep in mind that you're free to submit any idea that you want, either one of your own or another one from our list of blueprints.

Ember Prerequisites

• You should know your way around C++ already, and be comfortable with templates since this is commonly used throughout the WF stack.
• You should be comfortable with working with many different libraries, combining them and translating data between the different domains, as Ember is an application which uses a great number of third party libraries.
• You should be able to compile/run the Ember client on Linux from the master git repository. The Hammer Script should help you with getting all libraries set up.
• As a way for you to see whether you have the basic skill needed, and for us to prevent non-serious applications we require that any student submitting an application for Ember submits patches for the two errors in a code drop found here. There's one compilation time error, and one error which will be apparent during runtime. A patch file will suffice. Send it to erik@ogenvik.org.

Use MVC features for CEGUI lists and trees

• Summary: Use MVC features for CEGUI lists and trees
• Description: Ember handles UI lists inefficiently. When filling lists with many items it's not uncommon for the screen to freeze for a noticable time as CEGUI has to allocate the views for the list items. This could be improved if Ember instead used the upcoming MVC framework, which is planned to be released alongside CEGUI 1.0.0.
• Technical Details: This is a task which would require knowledge of both Ember and CEGUI. A lot of the UI code is written in Lua, so it's required that the student either knows Lua beforehand or are ready to learn it.
• Specification: More information can be found here.
• Difficulty: medium
• Technical requirements: beginner C++
• Mentor: Martin Preisler

Implement a custom imposter system

• Summary: Implement a custom imposter system
• Description: Replace the current hack of the PagedGeometry component with a custom imposter solution which fits the Worldforge world much better.
• Technical Details: This is a task which would require knowledge of both Ember and Ogre3d.
• Specification: More information can be found here.
• Difficulty: medium
• Technical requirements: beginner C++
• Mentor: Martin Preisler

Ryzom Core Ideas

About Ryzom Core

Ryzom Core is a framework built to encourage and facilitate the creation of open-source MMORPG projects and worlds. It contains all of the essential functionality needed for a mid-to-large scale MMO. All of the essential 3D, sound (including spatial sound), physics, landscape/terrain, data loading and core network services are available. Ryzom Core has a robust pre-built shard framework ready for developers to build game logic upon and ready to scale to whatever the developer needs. One Ryzom Core's fundamental differences between most of its open-source competitors is that Ryzom Core has been in development since 2001 and is the framework behind the commercial MMORPG [www.ryzom.com Ryzom]. Ryzom Core is a complete platform for MMORPG development and includes a vast array of artistic assets, tools, services and a full featured client so that a new project can sit down and begin creation on day one.

Contacting Ryzom Core

You can find the Ryzom Core community through our IRC channel (irc.freenode.net / #ryzom) as well our community.

Mentor Contact Information

• Matt Raykowski: IRC as 'sfb', email
• Vianney Lecroart: IRC as 'ace', email
• Nuno Gonçalves: IRC as 'ulukyn', email
• Dzmitry Kamiahin: IRC as 'dnk-88', email
• Jan Boon: IRC as 'Kaetemi'
• Matthew Lagoe: IRC as 'Botanic'

Tools Related Ideas

Ryzom Core Blender Exporter

• Summary: Create an exporter for the Blender modelling application.
• Description: Ryzom Core has one fully functional exporter for its game data pipeline: 3DSMAX. We greatly wish to enable FOSS users to create content completely independent of proprietary tools. This exporter will need to be functionally identical to the 3DSMAX exporter. This task may also require modifications to NeL in order to enable additional functionality (such as animation tracks keyed with a different algorithm). Finally the exporter should provide a method for build_gamedata to procedurally execute the export functions (see the 3DSMAX MAXScripts called to export shapes, etc).
• Technical Details: At a bare minimum we need the ability to export shapes, animations, skeletons and other objects out from Blender. The process should as closely match the 3DSMAX plugins capabilities as possible so that object creation between the packages is consistent and that the resulting exported data can uniformly be processed by build_gamedata regardless of the modeling package. Liberty can be taken on the presentation of the plugin information as is appropriate with Blender. The NeL builder classes are all in C++ but wrapping them in Python in order to use Blender Python API is acceptable.
• Specification: TBD
• Difficulty: Medium
• Required Skills: Python, C++, 3D Algorithms
• Mentor: TBD

Ryzom Core Landscape Editor Plugin

• Summary: Create a landscape editor plugin for Object Viewer Qt
• Description: Landscape editing and painting is one of the more sophisticated components of the 3DSMAX plugins. This plugin will combine four major components: Tile Editor, Landscape Sculptor and Landscape Painter, Ligoscape Editor. We envision the tool being something similar to EasyGen or the Torque Terrain Editor.
• Technical Details: The Tile Editor plugin will need to rewrite the Tile Edit Qt tool's presentation so that it is more flexible (implemented as re-sizable and dock widgets.) The process will also require the elimination of the PIC library - use CBitmap where edges need to be saved into the tile bank and QBitmap or QPixmap otherwise.

The Landscape Sculpting tool should use bezier patches as the underlying topology (since that is the native topology of NeL landscape zones.) A basic ability to edit sub-objects on the patch and to add sub-objects (cut to add more segments and points) is an essential. The ability to "sculpt" with brushes is the second task required. Finally an option to deform the topology using a heightmap. This tool should output a ".zone" file which is a binary serialization of CZone.

Landscape Painter should be based on the 3DSMAX Patch Painter plugin (nel_patch_paint). Nearly all of the underlying logic already directly manipulated the NeL CZone object - only the 3DSAMX driven presentation needs to be replaced.

The Ligoscape Editor will need to be able to define various zones created by the previous modules as ligobricks and define their purposes (ligozone, ligomat, ligotrans or special.) It will need to be able to export all of this information in a form that is usable by World Editor.

• Specification: TBD
• Difficulty: Very Difficult
• Required Skills: C++, Qt, 3D Algorithms
• Mentor: Matt Raykowski (sfb)

Ryzom Core Studio Developer Tools

• Summary: Ryzom Core Studio Installation, configuration wizards, and development sandbox creator.
• Description: Create a full end-to-end Windows installer for Ryzom Core Studio which walks the end user through setting up a complete Ryzom Core development platform. The installer should facilitate the configuration of a standalone development shard using a pre-built LAMP for Windows, configure the build pipeline to be able output a usable client, install and configure Studio, and integrate the build pipeline into Studio for easy build/preview clients.
• Technical Details: The installer will need to be broken into several distinct bits of work: retrieving appropriate packages (server binaries, media database(s), build pipeline, Python and other third party requirements), installing dependent softwares (e.g. XAMPP, Python), pre-configuring the shard for localhost use (including configuration files and MySQL data), pre-configuring the build pipeline, a configuration wizard for collecting the data for configuring the dependent tools as well as Studio, and writing a basic plugin to execute the build pipeline and start the preview client. This project will require that the student be comfortable with Qt development as Studio will need to be heavily modified to accommodate these changes.
• Difficulty: Medium
• Required Skills: C++, Qt, Misc (experience with packaging or installers such as NSIS.)
• Mentor: Matt Raykowski (sfb)

Ryzom Core Studio GUS Client

• Summary: Create a Studio plugin that authenticates against GUSnet and allows you to manipulate and use GUS modules such as the event coordinator module.
• Description: Create a plugin that lets you authenticate against GUS and then provides friendly, useful frontends to GUS module functionality. This work would eliminate the need for the MFC-specific code in GUS for its IService-based client.
• Technical Details: This project will require a functioning development shard with GUS properly configured. GUS is a single executable that has modular functionality based upon its configuration. This task would be replacing the "client" functionality in the GUS service with a plugin to Studio which would allow content and event creators to manipulate game worlds form within Studio.
• Difficulty: Medium
• Required Skills: C++, Qt
• Mentor: Matt Raykowski (sfb)

Large Storage Repository

• Summary: A version controlled repository system for large binary files.
• Description: The goal of this project is to develop a hybrid centralized-distributed version controlled repository system for large binary files. This is to be used for synchronizing the project asset database with multiple developers over the internet. It works like Mercurial’s largefiles extension, but with less overhead, more flexibility regarding file storage, and much reduced storage requirements on cloned repositories.
• Specification: https://docs.google.com/document/d/1jVILyu1isjrzdE1VJIWoQkGsJS8PHY6GsSQ5DibVr0c/edit#
• Difficulty: Medium
• Required Skills: C++, Networking
• Mentor: Jan Boon (Kaetemi)

Server Related Ideas

Implementation of NLNET Service in Node.JS

• Summary: Create a Node.JS module that is capable of communicating with NLNET services and acting as one.
• Description: The goal of this will be to create a suite of modules capable of performing NeL serialization/deserialization, connecting to NLNET sockets and services, and ultimately being able to act as an NLNET service in some capacity.
• Technical Details: First serialization will have be addresses as everything in NeL is serialized the same way. Next basically connectivity to sockets such as TCP callback services. A proof of concept must be created to provide a testing ground for functionality. Next will be the process of incrementally building an implementation of the NLNET::IService API. Added functionality could be to provide a means to interact with the full Ryzom Core infrastructure, so including Mirror and Tick Service integration.
• Specification: TODO
• Difficulty: Hard
• Required Skills: C++, JavaScript
• Mentor: Matt Raykowski (sfb), Jan Boon (Kaetemi)

NeLNS Qt Displayer and Services Dashboard

• Summary: Create a Qt UI for Ryzom Core Services and a Dashboard organizing all services.
• Description: This task has two parts. The first step is to implement a Qt-based viewer that NLNET::IService can be set to use individually. This displayer should function equivalent to the existing Windows displayer for network services. The second step is to build a "services dashboard" application in which each NeL network service displayer can be attached as a tab.
• Technical Details: The application cannot be run in the QApplication::run loop due to the fact that IService has its own main loop. Optimally the design will allow each service to remain running as an independent process and map into the dashboard through some other mechanism such as IPC.
• Specification: TODO
• Difficulty: Medium
• Required Skills: C++, Qt
• Mentor: Any

Ryzom Core API Service

• Summary: Create a central API hub service with a PHP REST API capable of XML and JSON.
• Description: The project would create a new API service that is capable of providing real-time access to PDR information as well as other statistics. Using the Mirror Service this service can retrieve all of the existing API functionality such as character information, fame and guild information. Additionally this service should have a MySQL database associated with it for tracking non-persistent data points such as data like PvP kills, PvE kills by player and by region, and more. All of this data should be available via a simple TCP interface for consumption by the REST frontend. Ideally the REST frontend would be written in PHP and accompany the existing Ryzom API (see code/web/api).
• Technical Details: The goals in this task would be to provide an expansion of collectable data and a PHP frontend based upon the open source Ryzom API (code/web/api). Unlike the existing API this should not rely on scheduled running of cronjobs to export XML via the pdr_util tool and should be capable of realtime or near-realtime querying.
• Specification: TBD
• Difficulty: Medium
• Required Skills: C++, PHP
• Mentor: Matt Raykowski (sfb) or Vianney Lecroart (ace)

Ryzom Core Service Security

• Summary: Create a shared library for service connectity authentication and authorization and provide a method for inter-service validation.
• Description: The Ryzom Core services do not have an standard method of "authenticating" non-player connectivity. With a handful of tools connecting to services such as MOS and the potential for webapp or tool connectivity to other internal services we should implement a simple authentication and authorization system using user credentials and privileges. Additionally it would be nice for the services to have some way of identifying each others validity within the shard to prohibit 'imposter' services for shards run on a public network with no filtering.
• Specification: TBD
• Difficulty: Easy
• Required Skills: C++, PHP
• Mentor: Matt Raykowski (sfb)

Ryzom App Improvements

• Summary: Improve the Ryzom App framework, add management functionality and write new apps.
• Description: The current open source App framework has no regulation of app and privilege security and has no way to dynamically introduce new apps. The improvements to the App framework should include adding a standard way to for introducing new apps and management of access to apps through privilege levels.
• Specification: Issue #28 (Framework Improvements), Issue #29 (Additional Basic Apps)
• Difficulty: Easy
• Required Skills: PHP
• Mentor: Nuno Gonçalves (ulukyn) or Matt Raykowski (sfb)

Ryzom Game Functionality

Implement New Movement Modes

• Summary: Implement the ability for players to jump and to swim underwater.
• Description: Ryzom Core has a basic ability to support these two features but the work was never completed. This task would be to completely implement one or both of these movement modes.
• Technical Details: See the forum thread for a more thorough discussion of the needed changes.
• Specification: Issue #17
• Difficulty: Difficult
• Required Skills: C++
• Mentor: Jan Boon (Kaetemi)

Conversion of Client Web Browser Technology

• Summary: Implement additional sound triggers such as impulses and phrase mapping.
• Description: Ryzom Core's client currently relies on LibWWW and cURL to facilitate the rendering if its in-game browser. The in-game browser and the accompanying allow Ryzom Core developers to quickly create new features and functionality using web frameworks. The reliance on LibWWW has proven to have two major problems for the project: LibWWW is no longer maintained and is no longer provided in many major distributions package repositories and its functionality is very limited, the LibWWW library has very poor support for advanced browser functionality. Ryzom Core would like to replace this with Berkelium. This would provide Ryzom Core with a rich interface capable of HTML5 and JavaScript.
• Technical Details: Remove the LibWWW code and replace it with embedded Berkelium. Simplify code where possible and document the design. Imlpement special language extensions (e.g. the lua tag) and other Ryzom specific deviations from the HTML standard.
• Specification: Issue #22
• Difficulty: Medium
• Required Skills: C++
• Mentor: Matt Raykowski (sfb)

General Usability

• Summary: Fix usability issues with Ryzom Core
• Description: Currently there's a number of smaller issues such as the "close" button not working, the system not auto-detecting screen resolution etc, that modern games have. Would be good to have these general usability issues fixed.
  • Application 'X' icon does not close the application.
  • Auto-detect screen resolution for default game settings.
  • Full screen outgame screens (windowed launcher, still).
  • Make the 'ESC' key close more than just modal windows.
  • Make it so users can choose to have 'tells' tabbed.
  • Anti-Aliasing Settings
  • Eliminate dependency on enums for titles, allowing adding titles to be content-only adds (a new sheet and a new set of translations) without code modification.
  • Eliminate dependency on enums for continents, replacing things such as Ring point determination with continent sheet information and defaulting continents starting locations in the sheets.
• Specification: TBD
• Difficulty: Easy
• Required Skills: C++, OpenGL
• Mentor: Any

Miscellaneous Game Play Additions

Please note that many of these ideas are short in duration and trivial while others are fairly complex. Please assess the difficulty and time required before using one of these ideas for a proposal. A task which we believe to be only a few weeks worth of work will not be accepted as a proposal. In these cases it may be helpful to lump together a theme of ideas for example guild improvements, outpost improvements or changes to the PVP system.

• Complete the _spires_ code and provide demonstration material and scripts.
• Implement improved mount/packer abilities such as taming/training and cavalry skills (ability to attack with penalty while mounted.)
• Implement PVP XP and PVP-specific skill tree code.
• Implement Guild/Faction/etc banners - using WindTree code to have a 'flapping' effect. Allow the new item type to have AOE bricks associated with it. Provide guild officer commands to grant and revoke standard bearer rights. Allow guilds to buy varying levels of standard. Perhaps add a PVP-restriction to its AOE abilities.
• Modify the guild system to have guild officer defined structure and ranks.
• Improve 'outgame' screens. Allow subsequent runs of the client to be full screen for outgame. Allow an outgame scene to be displayed at the login screen.
• Additional outpost building types (see the suggestion)
• Improve guild management interfaces, provide more details and abilities (see the suggestion).
• Extend outpost code to support a concept of 'homesteading' for guild members. Allow guilds to place guild buildings and players to place player buildings. Could lead to guild-owned hamlets.
• Improve the campfire code to allow creation of other objects, e.g. crates. (see http://atys.ryzom.com/start/app_forum.php?page=topic/view/8827/6#6 the suggestion]).
• Add tell/whisper windows or channels to the UI.
• Improve Ryzom Ring - see the suggestion.
  • Additional logic components.
  • Spawning of props.
  • Ability to add sound effects.
  • Scenario Repository - allow players to submit scenarios and other players to download from WebIG.
  • Ability for a player to 'host' a scenario on the Ring servers.
• Additional mission types: global and faction based missions. Similar in concept to group and guild missions.
• Musical instruments (ala Star Wars Galaxies). See the suggestion.
• RP features such as food or drink. Allow PCs to visit bars/restaurants. Essentially throw-away consumables for dapper sinks and role play.
• Damageable and destructible outpost buildings. Damage affects production (if applicable.)
• Improve material deposits to not be impacted or dependent on EGS reboots: persist the status of the deposit so that the state survives shard reboots but implement seasonal re-population. Make the re-population cycle configurable per deposit zone.

CEGUI Ideas

Crazy Eddie's GUI System is a free library providing windowing and widgets for graphics APIs / engines where such functionality is not natively available, or severely lacking. The library is object orientated, written in C++, and targeted at games developers who should be spending their time creating great games, not building GUI sub-systems!

As one of the oldest and most mature open source GUI libraries, it is widely adopted by both open source and commercial products and packaged in various distributions.

Contacting CEGUI team

You can find the CEGUI team and community through our IRC channel (irc.freenode.net / #cegui) as well our forums.

Mentor Contact Information

• Martin Preisler: IRC as 'mpreisler', email
• Lukas Meindl: IRC as 'Ident', email

Library Ideas

Easy Alternative Skinning System (window renderer set)

• Summary: Introduce a new skinning system that is simpler than the current one, maybe based on CSS
• Description: CEGUI has a skinning system (Falagard) that is very powerful, but also difficult to learn, due to its complexity and syntax. The goal of this project is to introduce a lightweight easy-to-learn skinning system that is especially targeted at artist/designers. It is alright if this skinning system contains less features than the original one, and if it is fulfilling less possible use-cases, as long as it is usable in the most common scenarios. More cpecific ideas include something based on the CSS syntax. Other propositions are welcome.
• Technical Details: The skinning system abstraction is already part of CEGUI (called WindowRenderer, each skinning system is a WindowRendererSet), this project entails creating an implementation based on the abstraction.
• Specification: TBD
• Difficulty: Medium
• Required Skills: C++
• Mentor: Martin Preisler

Font system revamp

• Summary: Make the font system easier to use for users/artists, lift implementation-specific restrictions (especially about size)
• Description: Right now users have to define a Font by family and size, texture is generated according to the parameters. If users want to use 5 sizes of the same font they have to define 5 fonts. This makes sense implementation-wise and makes for good runtime performance but is horrible and limiting for artists.
• Technical Details: We should let users define Fonts by family alone. When a font is requested to be rendered at certain size the glyph cache should be queried and return the closest available match. If we are far off from the requested size we schedule rasterization of that glyph size. Glyph cache memory limit, the margins of how off we are should both be changeable. The idea is to only cache what has been requested. That way we can support full unicode fonts and use them in various sizes without having tons of glyphs in textures that will never be used. When we run out of memory we destroy the least recently used glyphs to free it up. Additionally, the current font rendering we use is relatively simple and we do not make full use of such techniques "kerning" and sub-pixel anti-aliasing. To improve the look of rendered font, such techniques are typically used in font rendering. In order to add this to CEGUI, we would ask you to look for a solution that can be added without reducing performnance noticably.
• Specification: TBD
• Difficulty: Medium
• Required Skills: C++
• Mentor: Martin Preisler, Lukas Meindl

String memory-usage optimisations

• Summary: Work on string-usage optimisations in CEGUI that will both reduce memory usage and increases the overall performance of CEGUI a lot!
• Description: CEGUI makes very frequent usage of strings all over the place in our library. Strings are not only used to store any texts that need to be rendered in the GUI, but are also used in properties, events, for window names, and in a lot of mappings. Our current implementation unfortunately contains a lot of redundant string usage, making the runtime memory way bigger than necessary. This gets even worse once UTF-32 strings are used instead of std::strings, which, however, can be a high-priority requirement for many users, e.g. those who might want to support foreign languages and special character sets. Your goal is to first implement UTF-8 support and then start your work on optimising the performance and memory footprint caused by strings in CEGUI.
• Technical Details: First of all, support for lightweight UTF-8 string support has to be added. Then your work will start on optimisations using clever patterns and modern techniques: This will include reusing strings wherever possible and replacing strings with IDs in mappings (using constexpr). Additionally, every window currently maintains its own property-map. We would like to change this, too, so that all final window types (CEGUI::Editbox, CEGUI::DefaultWindow, etc.) will have one single shared property map (which will in general contain the large majority of properties!). Each created window will still its own (considerably smaller) additional property map, which will foremost contain properties loaded from the LNF (the XML definition of its look).
• Specification: TBD
• Difficulty: Medium
• Required Skills: C++
• Mentor: Lukas Meindl, Martin Preisler

Revamp Ogre Renderer to be more high level

• Summary: Create an alternative Ogre renderer using high level Ogre constructs that will hopefully replace the old one.
• Description: CEGUIOgreRenderer uses some intimate Ogre internals knowledge, we use lowlevel _ prefixed methods to draw. This is suboptimal for various reasons, the renderer is prone to Ogre changes that normally don't affect users. Render targets behave odd in OpenGL, DX10 and DX11 is somewhat supported in Ogre but CEGUI renders with various quirks with it, etc... In addition to that, our default branch contains SVG/custom-drawing features that require adding rendering in certain blend modes and with MSAA on/off on defined levels. You would have to make sure that the CEGUI-OgreRenderer works as goo as the CEGUIOpenGL3Renderer when it comes to these features.
• Technical Details: The idea is to use high level Ogre constructs to render, ManualObject as GeometryBuffer, Materials instead of manually altering the state via Ogre::RenderTarget, etc... All of this has to have comparable performance to the old Ogre Renderer.
• Specification: TBD
• Difficulty: Medium
• Required Skills: C++, Ogre3D
• Mentor: Lukas Meindl

Animation staging

• Summary: Provide means to make complex animations of entire window trees.
• Description: Animation in CEGUI only works on a single window. It would be great if users were able to stage complex animations (think main menu appearing). The idea is to fire off multiple animations on a whole widget tree at the right times. This task also involves writing an editor in the CEGUI Unified Editor for it. The API should be rather simple and easy to do, the editor will be harder (IMO). You will be able to reuse timeline and other components from CEED for the editor.
• Technical Details: This will introduce a new class that will start appropriate animations at the right times. Creating a new format for it will also be required. Python is used to create the editor and C++ for the CEGUI code.
• Specification: TBD
• Difficulty: Medium
• Required Skills: C++
• Mentor: Martin Preisler

Tools Ideas

Finish animation editor for CEED

• Summary: Improve and finish animation editor to CEED.
• Description: The animation editor so far works as an animation previewer with very limited editing. There is timeline and the ability to move keyframes around. This task would involve working to make animation editor not just functional (adding new keyframes, auto keyframes) but also making the user experience smoother. The controls are very clunky as of now as it's just a prototype. It would be very nice to make a designer/artist-friendly window that allows to set keyframes in a 2D window and choose an interpolation mode. The best way to imagine this is probably by thinking of the way popular 3D modelling software (Maya, 3DsMax etc) does this. The biggest share of the work would take place in the CEED editor using Python. If you can offer the required C++ skills we would like you to also implement a simple new interpolation mode as well, such as Catmull-Rom for the interpolation between defined keyframe points, which would go along really well with such an editor.
• Technical Details: CEED is written in Python so most of this task would involve Python coding and using Qt through PySide bindings and CEGUI through PyCEGUI bindings.
• Specification: TBD
• Difficulty: Medium
• Required Skills: Python, Qt4, CEGUI animations, (optionally also C++)
• Mentor: Martin Preisler, Lukas Meindl

Extend skinning editor for CEED

• Summary: Extend and finish the existing work on the LNF-editor of CEED from GSOC2014
• Description: The LNF(the format used to skin widgets, define its states, etc.) editor was added to CEED during GsoC2014 but was not finished due to time constraints and unexpecte issues. A lot of C++ code had to be changed because CEGUI was not ready for the requirements the LNF editor had to the code base, which mostly had not been changed in the past 10 years. After fixing these issues it was possible to create a basic editor that allows editing of WidgetLooks in the editor and seeing the changes right away in the editor. However, the amount of editing that can be done at the moment is quite limited and partially not perfectly user-friendly. The goal of this project is to make the most common and most needed features of skinning available in the editor. These have to be implemented in a user-friendly way. You will have to acquire excellent knowledge of the Falagard skinning system for this task (see http://static.cegui.org.uk/docs/0.8/fal_man.html), to understand how the skinning works and what can be done with it. Most of the work will be done in Python, however you might have to sometimes extend or adapt issues in C++ code, therefore C++ knowledge is heavily recommended.
• Technical Details: CEED is written in Python so most of this task would involve Python coding and using Qt through PySide bindings and CEGUI through PyCEGUI bindings, however some tasks might require C++ knowledge.
• Specification: TBD
• Difficulty: Hard
• Required Skills: Falagard, C++, Python, Qt4
• Mentor: Lukas Meindl

Improve code editing in CEED

• Summary: Code editing and multi mode editing is just a proof of concept right now, it is only used to overcome bugs in CEED.
• Description: CEED ships with a very simplistic plain text editor. Code highlighting and folding is missing. The undo redo system is very very clunky (each command stores the entire snapshot making it very memory hungry). QScintilla recently added support for PySide so we could include a proper code editor inside CEED.
• Specification: TBD
• Difficulty: Medium
• Required Skills: Python, Qt4, QScintilla
• Mentor: Martin Preisler

Misc hints

You can find more ideas on the WorldForge blueprints page. If you have any questions or want to suggest your own project, please contact us, either directly to Erik for Ember projects or through one of our communication channels.

For accepted students

There are a couple of things that we require of accepted students. Failure to perform these could lead to students not getting a passing grade (and thus no money from Google).

Community related

• Provide a weekly report, sent to the general mailing list. The report shall be sent each Monday.
• Try to participate as much as you can in the community. That involves hanging around in irc, asking questions (or CCing mail) on the mailing list (rather than only directly to a specific person).
• We require that you provide your mentor with an way of contacting a third person who knows you. This can be a sibling, parent, friend, partner etc. It will serve as a backup in the event that you would be unable to keep up the contact due to unforeseeable events such as sickness, accidents, internet outages and so on.

Code related

• Follow the instructions regarding how to handle your git clone repo.
• Only change code related to your task. Don't try to alter any formatting. This makes it so much harder for us to merge your changes.
• Regularly sync with the master branch. Preferably as often as you can. This makes it easier for us to merge in your changes, and lets you quickly find and resolve any conflicts.
• Follow the instructions on how to use Git on the wiki. It's imperative that you rebase on the master branch, so that your patches always reside "on top" of the master. After you've rebased you need to use "force" in order to push to Github.
• When making commits be sure to follow the conventions.