Summer of Code

From WorldForgeWiki

Jump to: navigation, search


Contents

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 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 Ember, Cyphesis or Wombat. This is a summary of suggested projects. The full specifications can be found as blueprints on the Ember Launchpad, Cyphesis Launchpad and Wombat 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

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 this special Ember code drop. 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.

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 ressources
  • 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

Automatic adjustment of graphical level

  • Summary: Design a system which will automatically adjust the graphical detail level so that framerate is smooth
  • Description: Ember already has an ability to change the graphics detail level, as well as the ability to tweak the settings of the terrain system. However, all of this must currently be done by hand. This task aims to implement a system which will sample the current frame rate and adjust the graphical detail level accordingly, so that the player always has a smooth framerate.
  • Specification: More details can be found here.
  • Technical Details: This task does not require much knowledge of Ogre or CEGUI, but it will require that the developer becomes familiar with large parts of the Ember source code, as this feature is sure to touch on many different subsystems.
  • Difficulty: medium
  • Technical requirements: standard C++
  • Mentor: Erik Ogenvik

Dynamic calculating of lower LOD versions for meshes

  • Summary: Implement dynamic and automatic creation of low-LOD versions of meshes, to be used for far away entities.
  • Description: While Ogre has a built in LOD system which allows you to provide different versions of each mesh for different LOD levels, the current media available only provides high level meshes. One approach to this would be to have Ember instead dynamically calculating various lower detailed meshes on the fly, to be used for lower LOD levels.
  • Specification: More details can be found here.
  • Technical Details: This task requires basic understanding of how a mesh works, basic familiarity with Ogre, and the ability to implement various methods for collapsing a 3d mesh into a lower detailed one.
  • Difficulty: medium
  • Technical requirements: standard C++
  • Mentor: Erik Ogenvik

Cyphesis ideas

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

Develop Mason Game Systems

  • Summary: Implement game systems require to build a basic castle fortification from scratch from gathering raw materials to the completed construction.
  • Description: WorldForge have been working for some time towards a loose set of ideas for a game called Mason. Mason has a generic medieval fantasy setting and is a freeform multiplayer sandbox game in which players have a broad ability to permanently affect a persistent online game world. A number of example game systems have been defined as a starting point. The goal is to implement these game systems, and then further expand the defined systems. An ideal candidate would help push the boundaries that the core code can currently support, debug existing infrastructure and stimulate the rest of the WorldForge team to create a more capable framework.
  • Technical Details: Game systems are implemented by editing XML data which defines the game elements, and by writing python scripts that defines how players can interact with the systems. It may also be necessary to propose and make changes to the C++ core on which the game systems run.
  • Specification: More information can be found here.
  • Difficulty: Medium-Hard
  • Technical Requirements: Python, basic XML, optionally C++
  • Mentor: Alistair Riddoch

Infrastructure ideas

Infrastructure Prerequisites

  • You should be a capable general programmer, capable of understanding code and picking up new languages as required.
  • You should be familiar with C++, include templates and the STL
  • You should have a good knowledge of systems design and networking
  • You should be able to compile and run Cyphesis and Ember from the master git repository on a Linux system.

Next generation Metaserver

  • Summary: Enhance WorldForge metaserver to support IPv6, server matching and authentication.
  • Description: WorldForge uses a metaserver to register the existance of game servers, and allow clients to get a list of those available. The current design is simple and elegant, but not extensible and does not provide enough features to support our evolving requirements. It needs to be re-written to support a set of new features, and allow for future extension.
  • Technical Details: The new metaserver needs to support old clients in legacy mode as well as defining a new extensible protocol which is independent of the underlying IP version (for IPv6 support), capable of supporting better server searches using additional data fields, and support extensions to the protocol.
  • Specification: More information can be found here.
  • Difficulty: Hard
  • Technical Requirements: C++, networking
  • Mentor: Alistair Riddoch

Develop WorldForge security

  • Summary: Enhance WorldForge system to use well design, off the shelf technologies for encryption and authentication.
  • Description: WorldForge uses plain text network communication, and only the most basic of authentication security. In order to support the necessary level of security it will be necessary to use much stronger technologies, but it is well outside the scope of the project to develop or implement these technologies from scratch. Technologies are required to ensure privacy and integrity of communication and a high standard of authentication both of users and of server systems.
  • Technical Details: We expect the StartTLS and SASL will be extremely applicable technologies, and anyone considering this project should evaluate the way these technologies are used to enhance the security of XMPP. XMPP has much in common with WorldForge communication protocols.
  • Specification: More information can be found here.
  • Difficulty: Hard
  • Technical Requirements: C++
  • Mentor: Alistair Riddoch

WOMBAT ideas

WOMBAT Prerequisites

  • You need to know your way around Python already, though the basics should be sufficient.
  • Web design skills are helpful.
  • To help you cut your teeth on Wombat and help us to filter out non-serious applications, every student applying for Wombat should have a go at setting up a small webapp serving a couple of image files from a directory. The webapp should be implemented using either Flask or Werkzeug. The focus should be on clean code, following the PEP8 standards, and good documentation.

Yaminon - A modular back-end server for WOMBAT

  • Summary: Split out the WOMBAT back-end handling to a standalone server.
  • Description: The current WOMBAT design relies on using the paste standalone server and using different threads to handle the back-end tasks like updating the SVN repository and cleaning up the database. The goal of this project would be to implement a standalone server service that handles all the back-end tasks for WOMBAT. A common SQL database will be used to communicate between the web front-end (WOMBAT) and the back-end server.
  • Technical Details: While currently the only required version control back-end is subversion, the design needs to stay modular enough to allow for easy addition of new back-ends. As a proof-of-concept, a second plain file back-end should be implemented using the same API.
  • Specification: TODO
  • Technical requirements: intermediate Python, beginner SQL
  • 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 [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 forums.

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'

Tools Related Ideas

Account Management Web Application

  • Summary: Create a basic account management and back office administration web application.
  • Description: Ryzom Core is presently shipped enabled to create new accounts without validation or verification. The idea behind this would be to create a new web application that would allow for basic account creation with email validation and CAPTCHA support. The tool would allow the player the ability to manipulate various pieces of their personal profile as well as to change their account settings such as their password. The back office component would need to provide the ability for game administrators to perform basic CRUD operations on player accounts as well as the ability to edit their permissions. It should also provide a central place to edit bans. The application would ideally be complimentary to the WebTT tool (written in CakePHP and sharign session and user information with it.)
  • Technical Details: The web application will be a basic CRUD application in the first phase with refinements to apply. It should be template driven and the data saved should be normalized appropriately to make future customization easy.
  • Specification: TBD
  • Difficulty: Medium
  • Required Skills: PHP
  • Mentor: TBD

Ryzom GUI Editor

  • Summary: Create a GUI editor for Ryzom's Interface Library
  • Description: Ryzom Core has a robust GUI system which is driven through XML files. This means that it is easy to layout new dialogs and modify existing ones provided you understand the elements in the XML dialogs. To make modifying and adding new dialogs easier we want to add a GUI Editor plugin to OVQT. For examples you could look at CEGUILayoutEditor or MyGUI Layout Editor.
  • Technical Details: The tool should be written as an OVQT plugin. Before the actual editor is written the interface code (interface_v3) will need to be modularized into a library that the plugin can utilize independent of the client source code. This may also mean modularizing the CDB system. The GUI Editor does not need the ability to read the CDB system, the stand-in labels would be sufficient.
  • Specification: TBD
  • Difficulty: Very Difficult
  • Required Skills: C++, Qt
  • Mentor: TBD

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 Maya Exporter

  • Summary: Create an exporter for the Maya modelling application.
  • Description: Ryzom Core has one fully functional exporter for its game data pipeline: 3DSMAX. 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). Note that the student will need to download and use the free 13th month student edition of Maya.
  • Technical Details: At a bare minimum we need the ability to export shapes, animations, skeletons and other objects out from Maya. 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 within Maya. A fair portion of the basic ground work of an exporter already exists for the student to review at: http://werewolf2.svn.sourceforge.net/viewvc/werewolf2/trunk/tools/maya/
  • Specification: TBD
  • Difficulty: Medium
  • Required Skills: C++, 3D Algorithms, Maya API and MEL.
  • Mentor: Matt Raykowski (sfb)

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 Build Gamedata Frontend Plugin

  • Summary: Create an OVQT plugin allowing execution and monitoring of build_gamedata.
  • Description: build_gamedata is a Python-based tool that automatically exports and builds gamedata. The purpose of this task is to create a plugin for Object Viewer Qt that provides a way to execute the various stages of the pipeline, to view the logging/debugging and provide basic workflow status. In addition to this the build_gamedata workflow should be represented in some form - either tree view or graphical - and allow certain stages to be run directly. This will require modifying the build_gamedata tool so both C++ and limited Python will be required.
  • Technical Details: TBD
  • Specification: TBD
  • Difficulty: Medium
  • Required Skills: C++, Qt, Python
  • Mentor: TBD

Server Related Ideas

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

Ryzom Core Statistics Services

  • Summary: Improve PDSS and implement additional commands.
  • Description: The PDSS service provides the ability to schedule command execution at an hourly and at a daily interval. In addition it collects a fixed set of data. It would be helpful to begin adding the ability to query live runtime data such as the number of mobs in region, the number of mobs killed, the number of a specific item and so on. All of the work to schedule and output data is manually created on the server using pdss_css scripts and the output is locally stored. In order to decentralize the presentation of this collected data it would need a messaging API that would allow services (or PHP scripts capable of sending CMessage objects) to upload/update scripts and retrieve information.
  • Technical Details: The goals in this task would be to provide a more flexible scheduling mechanism, an expansion of collectable data and additional service-level control commands for upload/retrieval of data and scripts.
  • Specification: TBD
  • Difficulty: Medium
  • Required Skills: C++, PHP
  • Mentor: TBD

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

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: TBD
  • Difficulty: Difficult
  • Required Skills: C++
  • Mentor: TBD

Implement Additional Sound Triggers

  • Summary: Implement additional sound triggers such as impulses and phrase mapping.
  • Description: We would like to add the ability to do things such as send "play sound" impulses from mission scripts and the ability to map a phrases to a sound samples. The idea is to provide mission creators more depth and control over their events and dialog.
  • Technical Details: The "play sound" impulse should be fairly easy. We will need to implement a mission action similar to CMissionActionPopupMsg which in simple terms uses the PlayerManager to send a "USER:POPUP" impulse to the client. The phrase mapping will be more difficult but could be done fairly simply by combining the locale name (e.g. EN or FR) to the end of the phrase (e.g. WELCOME_TO_RYZOM) creating a new sample named "WELCOME_TO_RYZOM_EN" - if such a sample exists in the sample bank play the sound from a source located at the speaker. This will allow us to have limited verbal dialog.
  • Specification: TBD
  • Difficulty: Easy
  • Required Skills: C++
  • Mentor: TBD

Implement Character Achievements

  • Summary: Create a player achievement system.
  • Description: Create a special achievement brick family and a WebIG application to view per-character achievements. The first phase will be the brick family, sample bricks (and a mission to grant them) and the basic WebIG application. The second phase will be to design and implement a basic framework that would allow developers to easily write "rules" to the achievement system for specific non-mission types of achievements. As an example the implementation should include an achievement rule for: total PVP kills, total mob kills, total mission completions, total rites accomplished. The third phase would be to add new command(s) into the AI script to allow NPC writers to script the process of providing achievements.
  • Technical Details: You will need to be familiar with the brick system and be able to modify it in such a way to not have a negative impact on legacy data. You will need to research and document the process of adding new script commands. You will need to design and document an extensible "rules" system. This latter task will encompass the majority of the Summer of Code period.
  • Specification: TBD
  • Difficulty: Medium
  • Required Skills: C++
  • Mentor: Vianney Lecroart (acemtp)

Conversion of Client Web Browser Technology

  • Summary: Convert the client web browser library from LibWWW to a modern alternative.
  • Description: The Ryzom Core client is currently reliant upon cURL and LibWWW for the retrieval and parsing of web content (specifically for WebIG.) LibWWW is no longer actively maintained and distributed in the main Linux distributions. This task would undertake replacing LibWWW with an alternative.
  • Technical Details: Determine the alternative frameworks (e.g. LibXML HTTP Parser, Berkelium, etc). Remove the LibWWW code and replace it with the alternative implementation. Simplify code where possible and document the design. Must maintain all special language extensions (e.g. the lua tag) and other Ryzom specific deviations from the HTML standard.
  • Specification: TBD
  • Difficulty: Medium
  • Required Skills: C++
  • Mentor: TBD

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

  • Jeff A. Marr: IRC as 'Jamarr'
  • Michael Kapelko: IRC as 'kornerr'
  • Martin Preisler: IRC as 'mpreisler', email
  • Stefan Stammberger: IRC as 'fusion44'

Library Ideas

Samples framework

  • Summary: Unify all samples together into one executable with a framework.
  • Description: Currently, samples are separate applications that are run separately. It would be nice to have some sort of a unified framework for defining samples. That way you can start CEGUIDemos executable and browse through samples, switching them, etc... Part of this task is to create new demos, improve existing ones or possibly remove them if they don't make sense anymore.
  • Technical Details: New samples should be coded in C++, Python or Lua (all languages CEGUI officially supports), so this framework should have bindings for Python and Lua. The GUI for choosing samples should of course be done with CEGUI. Ogre has a similar sample framework (but samples can only be written in C++).
  • Specification: TBD
  • Difficulty: Medium
  • Required Skills: C++, limited Python and Lua
  • Mentor: Jeff A. Marr, Martin Preisler, Stefan Stammberger

New Font API

  • Summary: Improve on the current Font API to make it more declarative and convenient for users of the library.
  • Description: CEGUI exposes a lot of pain regarding text rendering and realtime 3D graphics to the user. You have to explicitly instantiate the font in sizes you will want, you have to instantiate bold, italic, etc variants as separate fonts, ... This task would involve changing the API around to make it simpler for the user. You would be able to define a Font you want to use and sizes would be loaded into textures dynamically (including garbage collection).
  • Technical Details: This will almost surely involve using Freetype2 library to generate the necessary textures.
  • Specification: TBD
  • Difficulty: Medium
  • Required Skills: C++, freetype2 API
  • Mentor: Jeff A. Marr, 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: Jeff A. Marr, Stefan Stammberger, Martin Preisler

Canvas (custom render independent drawing) + SVG subset

  • Summary: Make CEGUI capable of drawing vector images.
  • Description: CEGUI only draws rectangles at this point (it binds textures to them but they are still rectangles). This task would be about adding the ability to draw other shapes to surfaces of widgets. The API should reuse concepts from other libraries. It would be cool if we were able to draw a subset of SVG with this API (preferably having a subclass of Image called SVGImage).
  • Technical Details: Implementing a CEGUI Skia renderer would help greatly with the SVG subset part of this task.
  • Specification: TBD
  • Difficulty: Hard
  • Required Skills: C++
  • Mentor: Jeff A. Marr, Martin Preisler

GUI Navigation

  • Summary: Create a GUI navigation and visual focus implementation.
  • Description: Currently, primary interaction with CEGUI takes place via the mouse input device only. CEGUI should be enhanced to allow other devices - such as the keyboard - to be used for interacting with and navigating the GUI and to provide appropriate visual feedback.
  • Technical Details: The idea here is to provide some form of abstract interface for navigating a GUI layout, and then provide an implementation of that interface that uses the keyboard. Other challenges will include adding appropriate mechanisms to provide navigational hints to the core GUI classes, and extending the core window rendering classes to provide a uniform approach to visually indicating which GUI element has current focus. IRC history explaining more of this
  • Specification: TBD
  • Difficulty: Medium / Hard
  • Required Skills: C++, some XML knowledge
  • Mentor: Michael Kapelko

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 throguh PySide bindings and CEGUI through PyCEGUI bindings.
  • Specification: TBD
  • Difficulty: Hard
  • Required Skills: Python, Qt4, Falagard looknfeel
  • 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, to AlRiddoch for Cyphesis projects, to Kai for Wombat 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.
  • When making commits be sure to follow the conventions.
Retrieved from "http://git.worldforge.de/wiki/Summer_of_Code"
Personal tools