From WorldForgeWiki

Contents 1 About Google Summer of Code 2 WorldForge in the Summer of Code 2.1 Requirements 2.1.1 General Prerequisites 2.1.2 During the Program 2.2 Helpful Links 3 Ideas List 3.1 Ember Ideas 3.1.1 Ember Prerequisites 3.1.2 Integrate the Google Breakpad 3.1.3 Allow for dynamically dowloadable remote resources 3.1.4 GUI improvements 3.1.5 Automatic adjustment of graphical level 3.2 Cyphesis ideas 3.2.1 Cyphesis Prerequisites 3.2.2 Develop Mason Game Systems 3.3 WOMBAT ideas 3.3.1 WOMBAT Prerequisites 3.3.2 Preview for 3D assets 3.3.3 Research Project: WOMBAT Implementations using other frameworks 3.4 Misc hints 4 For accepted students 4.1 Community related 4.2 Code related

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.
• 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.
• 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, or just a description of which lines in which files should be changed will suffice.

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 Hjortsberg

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 Hjortsberg

GUI improvements

• Summary: Various improvements to the Ember GUI
• Description:Improve the GUI by adding five distinct features:
  • A common quickhelp system, which will unify the various way we now present context help to the user. More info.
  • Actionbars, allowing for binding of items and actions to keys. More info.
  • Support for bags and stacks in the inventory. More info.
  • Allow items to be dragged from the inventory to the world. More info.
  • Points-of-interest markers on the compass/minimap. More info.
• Technical Details: This is a task which will require the student to learn both Ember and CEGUI in depth.
• Difficulty: hard
• Technical requirements: advanced C++
• Mentor: Erik Hjortsberg

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 Hjortsberg

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

WOMBAT ideas

WOMBAT Prerequisites

• You need to know your way around Python already, though the basics should be sufficient.
• Web design skills are helpful.
• You will need to set up a local Pylons install, but if needed we can provide you with virtual machine images with a development environment set up.
• 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 implementing the exclude directories blueprint for the libsvn backend.

Preview for 3D assets

• Summary: Render 2D preview images for 3D assets
• Description: Currently WOMBAT only creates thumbnails for 2D images. However, a lot of the artwork in the repository consists of 3D models that do not have previews yet. The goal of this project would be to design and implement a method for intelligently creating thumbnails for 3D assets as well. As described in the blueprint, this could be done by extending the existing Plunger tool, or by creating a specialized tool. File formats that should be supported are:
  • Ogre3D (binary or xml)
  • Cal3D
  • md3
  • 3ds
• Technical Details: Different 3D file formats require different helpers to load and render. Many models are composed of the mesh, the skeleton and textures, often in different files. A simple software renderer should be used to create the previews that would then be cached on the server side.
• Specification: For more information, see the blueprint.
• Difficulty: hard
• Technical requirements: beginner Python, intermediate maths
• Mentor: Kai Blin

Research Project: WOMBAT Implementations using other frameworks

• Summary: Implement WOMBAT using other Python web-app frameworks.
• Description: Currently, WOMBAT is built on top of the Pylons framework. By the time WOMBAT 0.0.1 was developed,Pylons was the best tool for the job. Now that Wombat has matured, the list of requirements has changed, and some things, like running time-consuming tasks in the background, are a bit clumsy to implement using Pylons. The goal of this project would be to reimplement WOMBAT on top of some other Python web-app frameworks to see if one of them fits better.
• Technical Details: The Werkzeug toolkit, Django and TurboGears should be investigated, the student is free to propose additional frameworks.
• Specification: TODO
• Technical requirements: intermediate Python, intermediate JavaScript/Ajax
• Mentor: Kai Blin

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

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.