Summer of Code

From WorldForgeWiki
Jump to: navigation, search


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.


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 Ember. 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

Integrate the Google Breakpad

  • Summary: Integrate the Google Breakpad crash reporting system with Ember
  • Description: Google hosts a project called the Breakpad, which is an automated crash reporting system. This project aims to integrate into Ember, so that crash information is automatically sent to a Worldforge server for collection and processing. A phase two of the project will involve building various crash report handling and reporting functionalty, perhaps integrating it with the Launchpad used for bug tracking.
  • Technical Details: This is a task which won't require any in depth knowledge of Ember or the Worldforge system. The focus is instead on the Breakpad system, and how it can be integrated into Ember.
  • Specification: More information can be found here.
  • Difficulty: medium
  • Technical requirements: beginner C++
  • Mentor: Erik Ogenvik

Allow for dynamically dowloadable remote resources

  • Summary: Add support for dynamically downloadable remote resources
  • Description: Allow for media to be dynamically downloaded from remote resources. This involves specifying how resource discovery and location definition is specified and then implementing this in the client. The goal is to allow each world to be able to fully provide it's own complete set of media.
  • Technical Details: This is a task which will require the student to both learn Ember and Ogre, and deal with network transfer, probably through the libwfut library.
  • Specification: More information can be found here.
  • Difficulty: hard
  • Technical requirements: advanced C++, basic knowledge of web servers and network transfer
  • Mentor: Erik Ogenvik

Integrate SmartBody

  • Summary: Integrate the SmartBody system for humanoid movement into Ember.
  • Description: SmartBody is a system which allows for advanced movement or humanoid meshes. This would be a perfect fit for Ember, as it would bring much more depth and expressiveness to the humanoid characters. This task involves making sure that SmartBody code is integrated with Ember, but also that there are enough bindings in the Model format to leverage SmartBody features.
  • Technical Details: This is a task which will require the student to both learn Ember and SmartBody. Ogre will also be touched upon, but to a lesser extent.
  • Specification: More information can be found here.
  • Difficulty: medium
  • Technical requirements: medium C++
  • Mentor: Erik Ogenvik

Cyphesis 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.

Cyphesis Prerequisites

  • You should be a capable general programmer, capable of understanding code and picking up new languages as required.
  • You should be experienced in Python, or good with another similar high level language and be prepared to put in the effort to learn Python.
  • You should be able to compile and run Cyphesis from the master git repository on a Linux system.
  • You should be familiar with C++.
  • You should be able to run Ember.

AI entity filters

  • Summary: Implement AI entity filters, or "entity queries"
  • Description: For AI characters we need a better way to let them look for or interact with entities. Just going by the type of the entity isn't enough. We need a way to use multiple criterias to select entities. Think of other query languages like SQL.
  • Technical Details: Understanding how query languages, using chained criterias, are constructed will help. You will need to do work in both C++ and Python.
  • Specification: More information can be found [1].
  • Difficulty: medium
  • Technical requirements: medium C++, medium Python
  • Mentor: Erik Ogenvik


  • Summary: Add support for instances
  • Description: An "instance" is an entity which only exists for certain other entities, and only for a certain duration. See other MMORPGS for how this concept works. We need to add support for this to Cyphesis.
  • Technical Details: Understanding how the entity system works.
  • Specification: More information can be found [2].
  • Difficulty: medium
  • Technical requirements: medium C++
  • Mentor: Erik Ogenvik

WOMBAT ideas

Wombat Prerequisites

  • You should be a capable general programmer, capable of understanding code and picking up new languages as required.
  • Knowledge of the Go programming language is a plus
  • You should have a feel for user interfaces
  • WOMBAT is developed in a git repository, but interfaces with a subversion repository. Knowledge of both systems is a plus.


  • Summary: A web server for WOMBAT serving files and JSON metadata
  • Desciption: WOMBAT interacts with the WorldForge media repository to display media assets. The idea of this project is to create a web server using a Go web framework such as Revel to serve images and JSON metadata to a web application.
  • Technical Details: For this task, a clean web API needs to be designed to make the development of a web app as easy as possible. The server implementation should come with a simple example web application that can be used for testing out the web API.
  • Specification: TBD
  • Difficulty: medium
  • Technical requirements: medium Go, medium JavaScript
  • Mentor: Kai Blin

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 [ 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 ( / #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)

OVQT Tool Conversions and Improvements

  • Summary: Complete the conversion of important level design tools such as Tile Editor and Georges Editor and implement improvements to existing tools or to the OVQT framework.
  • Description: The OVQT tool has become the primary tool used for content creation in Ryzom Core. It's still a fairly immature tool and needs plugins adapted to it or polished so as to be more usable and stable. There are several on-going efforts to accomplish this such as a new Georges Editor plugin, a new Tile Editor plugin and a mostly complete Mission Compiler. In addition there are some tools which could use some additional minor functionality. The editor framework itself is purposely simple but could use some slight improvements as well.
  • Technical Details: This project will be a collection of small improvements to existing tools, minor updates to the extension framework and the completion of partially-to-mostly completed tools with existing reference implementations. There are issues linked for each one of these.
  • Specification: : Issues #11 (Georges Editor), Issue #12 (Tile Editor), Issue #24 (Mission Compiler), Issue #25 (Splash Screen), Issue #26 (Hot Load Plugins), Issue #27 (UXT Editor)
  • Difficulty: Medium
  • Required Skills: C++, Qt
  • Mentor: Matt Raykowski (sfb) or Dzmitry Kamiahin(dnk-88)

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: TBD

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


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 ( / #cegui) as well our forums.

Mentor Contact Information

  • Michael Kapelko: IRC as 'kornerr'
  • Martin Preisler: IRC as 'mpreisler', email
  • Stefan Stammberger: IRC as 'fusion44'

Library Ideas

Easy Alternative Skinning System (window renderer set)

  • Summary: Introduce a new skinning system that is less powerful but easier than Falagard
  • Description: CEGUI has a very powerful skinning system that unfortunately is very hard to grasp and work with. People often make jokes that it's Turing complete and can be used to guide missiles. The goal of this project would be to introduce a lightweight easy skinning system that is artist friendly. It is OK if this skinning system isn't all powerful and if there are many use-cases that it can't fulfill but it should be usable for common scenarios. Specific ideas include something based on the CSS syntax.
  • Technical Details: The skinning system abstraction is already part of CEGUI (called window renderer, each skinning system is a window renderer set), this project entails implementing this abstraction.
  • Specification: TBD
  • Difficulty: Medium
  • Required Skills: C++
  • Mentor: Martin Preisler

Font system revamp

  • Summary: Make the font system easier for users/artists, don't impose 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. Then when font is requested to be rendered at certain size we will look into glyph cache 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.
  • Specification: TBD
  • Difficulty: Medium
  • Required Skills: C++
  • Mentor: Martin Preisler

Model/View widgets

  • Summary: Convert Tree, ComboBox, Listbox (both ItemEntry and ListItem variants) to the model/view paradigm (see Qt - QAbstractItemModel)
  • Description: Create a model abstract class that user can implement in their own structures. This prevents having multiple copies of the same data. This project would also finally unify all the various data viewing widgets to the same paradigm.
  • Technical Details:
  • Specification: TBD
  • Difficulty: Medium
  • Required Skills: C++
  • Mentor: 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...
  • 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: Michael Kapelko, Martin Preisler, Stefan Stammberger

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.
  • Specification: TBD
  • Difficulty: Medium
  • Required Skills: C++
  • Mentor: Stefan Stammberger, Martin Preisler

Tools Ideas

LookNFeel editor for CEED

  • Summary: Add the looknfeel editor to CEED.
  • Description: As of now, CEED edits layouts, imagesets and animations. LookNFeel editor would be a killer addition. Basically would allow artists to create new skins without touching XML code. This has always been a feature that many requested.
  • 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: Hard
  • Required Skills: Python, Qt4, Falagard looknfeel
  • Mentor: Martin Preisler

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.
  • 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
  • Mentor: Martin Preisler

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.
Personal tools