This is a list of possible student projects for Google Summer of Code 2011. The game engine is written in C++ so you should be familiar with its basics for all the projects below. If there is something in OpenClonk you would like to work on in the scope of GSoC 2011 and which is not in this list then please contact us in IRC or in the forums and if it's a cool idea we can surely find a mentor and make it happen. Also if you have questions to any of the ideas below feel free to ask in IRC, in the forums or talk directly to one of the mentors listed.
Note: OpenClonk was not accepted as a mentoring organization in 2011. If you want to work on any of the ideas below without being paid you are still more than welcome of course, and the mentors mentioned would be happy to get you started and assist you where they can.
Introduce DirectX support
When we introduced support for 3D mesh rendering we only did so for the OpenGL renderer. Since meshes are required to run the game the DirectX option is currently disabled. However there are many drivers which support DirectX better than OpenGL, and Window handling (such as Tabbing out) works better in DirectX mode, so it would be cool to have it back. The current implementation of the 3D mesh renderer loads meshes in the Ogre3D format and amongst others, supports uv-mapped textures, orthographic/perspective rendering, (bone) animations, an interface to C4Script (Clonk's script language) for attaching additional meshes to bones, change textures as well as play, mix and control different animations.
Requirements: C++ knowledge, Windows OS, ideally some basic understanding of 3D computer graphics / DirectX API
Mesh Rendering performance
Some players report poor FPS rates on their otherwise adequate hardware. This task involves finding potential bottlenecks and fixing them. Especially the new mesh rendering code is probably subject to more optimization. Ideas for things to investigate include re-using the depth buffer for multiple meshes, executing skeletal animation on the hardware or adding support for Level-of-Detail for meshes and/or textures.
Requirements: C++ knowledge, ideally some basic understanding of 3D computer graphics.
With the overhauled controls in OpenClonk it became impossible to play the game in splitscreen mode because every player needs mouse control. Splitscreen mode can be re-introduced by allowing multiple mices to be used, one for each player. The generic splitscreen code is still in place, so the code that needs to be written needs to manage multiple input devices and propagate events correctly.
Difficulty: Medium to Hard
Requirements: C++ knowledge, at least two mice/pointing devices :)
Extend in-game GUI: Non-modal inventory windows
The in-game inventory management is overhauled completely for the next milestone to be faster and more intuitive to use. This involves the implementation of generic non-modal windows which can interact with each other through an appropriate script interface. The generic windows are written in C++ while the specific (inventory) windows should be implemented using the script interface provided by the C++ implementation. To summarize, this project consists of three different areas of work: First, the construction and rendering of the windows and its contents, second, the interface to C4Script and third, the implementation of specific inventory (and other) windows in C4Script.
Resources: None yet
Requirements: C++ knowledge, ideally knowledge about C4Script (Clonk's scripting language)
OpenClonk features an editor in which, amongst other things, selected objects in the game can be altered and their methods be called. Currently, the window that shows the properties of an object shows the properties of the object definition, the actual object, local variables and effects on the object in a small simple text window which is inconvenient and which doesn't allow the values to be changed. The window that lists the objects in the game also needs a redesign as it is unclear which item in the list represent which object in the game area.
All in all, the editor needs a thorough redesign to be more helpful in scenario creation and debugging of game content. For example the properties window should show the different types of properties of an objects in separate tabs and in an editable table. But there are many more improvements that can be done on the editor such as a simple way to put new objects into the game area.
The editor for the Linux version is made with GTK+, the editor for the windows version uses native Windows controls. However it is up to you what GUI technology you want to use for the redesigned editor (and on what platform you want to get it working first) so choose whatever you are familiar with. Another option is to use the same code that is also used for the ingame GUI, C4GUI. This requires probably more work than using an existing well-known toolkit but might turn out to be easier to maintain on all three platforms.
Difficulty: Easy to Medium
Resources: This is how the editor looks currently: Media:Gtkeditor.png
Requirements: C++ knowledge, ideally experience in GUI programming