Ryzom

h1. GSoc2010Ideas

{{toc}}

All GSoC ideas are rated on a simple 4-place scale: Easy, Moderate, Difficult and Extremely Difficult.

h2. NeL3D

h3. Implement new OpenGL backend driver in NeL3D

*Difficulty:* Difficult

*Priority:* Medium

*Description:*

Write a new OpenGL driver for NeL3D based on either OpenGL 2.0+ or OpenGL ES 2.0. The latter OpenGL implementation will be the more challenging effort. Writing an OpenGL 2.0+ driver would be a good step to providing the basis necessary for more modern OpenGL implementations and OpenGL ES 2.0 will set the basis for the future OpenGL 3.0 driver. The new OpenGL driver implementation will have to be API compatible with the rest of the drivers by implementing the IDriver interface. Any extensions of the IDriver API will need to be applied downstread to the existing OpenGL driver as well as the Direct3D driver.

*Requirements:* C++, OpenGL

h3. Fill gaps in existing OpenGL Driver Functionality.

*Difficulty:* Moderate to Difficult

*Priority:* Very High

*Description:*

The existing OpenGL driver is lacking in functionality in a few key areas: driver initialization, anti-aliasing support and native OSX Support.

* The existing OpenGL driver provides no extended driver initialization capabilities. This has hindered our abilities to embed the OpenGL driver into third-party viewports (e.g. in a Qt window.) This will require an "initialization" structure to be passed to the driver through the setDisplay method meaning the structure or implementation should be flexible enough such that there is no separate setDisplay method specifically for OpenGL. Ultimately the goal would be to eliminate the other setDisplay methods and have the same structure driving both the D3D and OGL display initialization.

* Event pumping for third-party displays is done through a function called getWindowProc. This method returns a function pointer for pumping events which is properly implemented in Direct3D and OpenGL on Windows but has no way of providing a comparable function on Unix platforms. The initialization flags should provide the ability for the developer to override the stock WndProc thus allow for the ability to add support for tertiary platforms and UI toolkits such as Qt.

* Currently the NeL implementation for OS X relies upon X11 which is not a default feature for average end-users. We would like to create a custom native handler for the OpenGL driver for OS X systems. This will provide native window creation, screen management and events (keyboard and mouse input.)

* The existing OpenGL driver is currently ignoring the AntiAlias value of the requested mode. Update the driver to determine if the selected AA level is valid (None, 2x, 4x and Max) and then apply it. This functionality exists and works in the Direc3D driver.

*Requirements:* C++, OS X (Xcode), Cocoa, Objective-C, OpenGL

h3. Modularize OS/Platform/Architecture Code

*Difficulty:* Easy to Moderate

*Priority:* Medium

*Description:*

We would like to extract OS and platform specific code into separate code files that can be resolved at link-time as well as runtime. This will help clean a myriad of #ifdefs out of the code and will allow us, at runtime, to link libraries optimized for specific instruction sets (e.g. MMX).

* Provide link and runtime loading of optimized instruction sets

* Provide an interface-based method of implementing, registering and using various event emitters.

* Migrate existing event emitters (e.g. DirectInput and Unix Events) to this new interface system and decouple event management from the 3D driver.

*Requirements:* C++

h3. Create A Programmable Shader Framework

*Difficulty:* Extremely Difficult

*Priority:* High

*Description:*

We want to create a pluggable programmable shader framework that allow us to load shaders at runtime and allows the configuration of use of a specific shader langauge based  upon system support. This will give us the ability to allow graphic artists to write shaders for their models and terrain without requiring timely and bug prone modifications of the render pipeline and will eliminate the existing inefficient CVertexProgram architecture. This will also simplify our ability to support for existing built-in shader effects.

A programmable shader framework would provide the following functionality:

* Ability to define multiple shader alternatives within a single shader definition with the goal of allowign the shader system to choose the correct shader for the situation. For example allow an artist to define both a GLSL and an HLSL shader on the same shader definition so that the system will choose the language appropriate to the driver currently in use.

* Ability to define shaders in multiple venues: dynamically at runtime, on a material within the 3DSMAX plugin, serialized into the material of the shape and able to be loaded from a .shader file serialized by the NeL stream system.

* Ability to define on the shader definition engine constants to be passed to arguments of the shader script.

* Implement both Vertex Program and Fragment Program shaders.

* Allow for multiple passes.

* Allow for multple shaders on a material.

Note: The internal design of this is not set in stone and the NeL community is open to alternative design concepts as long as the high level functionality requirements are met.

Note: Cg is not an adequate replacement for both GLSL and HLSL. Due to its non-free nature making it a mandatory library excludes NeL from popular Linux distributions main repositories such as Debian and Ubuntu. That being said having Cg support is highly desirable for many NeL-based projects.

*Requirements:* C++, OpenGL *and* Direct3D, GLSL *and* HLSL (potentially Cg)

h3. Expand Shadow Rendering Support

*Difficulty:* Difficult

*Priority:* Low

*Description:*

We need to fix shadow rendering to have more broad hardware support. We have a number of platforms in which shadows do not render properly.

*Requirements:* C++, OpenGL *and* Direct3D, potentially GLSL and HLSL.

h2. NeLMisc

h3. Implement Pluggable Scripting Framework

*Difficulty:* Difficult

*Priority:* Medium

*Description:*

We want to create a pluggable scripting framework with a reference implementation in Python or Lua. This framework will provide the essential wrapping of the NeL API so that any NeL-related activity can be accomplished through the reference implementation. The goal in this is to make it easier for new and existing projects to develop gameplay changes dynamically while limiting the impact of compilation. In addition if the reference implementation is in Python this provides a crucial step forward in simplifying the path to a Blender exporter.

*Requirements:* C++, Lua and/or Python

h3. Expand Media File Support

*Difficulty:* Easy to Moderate

*Priority:* Low

*Description:*

We want to add file format support for more texture and image formats using a third-party library such as DevIL. The new functionality should be flexible enough to exclude formats that may not supported by the third party library based on the library compile-time options. In addition to file formats for textures we would like to provide support for loading sound banks from a variety of sources. This new module should be able to be used with NL3D as well as NLSOUND and should be the basis for CBitmap's loading of textures. Rather than being a set of classes it may be beneficial to merge this functionality into a new module called NLMEDIA.

*Requirements:* C++

h2. NeLPacs

h3. Create an Alternative Implementation of PACS

*Difficulty:* Difficult

*Priority:* Low

*Description:*

There have been a number of request to have a "true" 3D collision library implemented for NeL using NeL's types and compatible with NeL's landscape. The primary challenge with this is compensating for the landscape without inducing undue performance losses. The two optimal choices for a potential third-party library to support would be either "Bullet":http://www.bulletphysics.com/Bullet/wordpress/ or "ODE":http://www.ode.org/. It would also be preferred if possible to maintain NLPACS as an API and change it to load the legacy functionality or the new functionality as a driver in the same manner we manage OpenGL vs. Direct3D. PACS currently suffers from being a 2D collision system which introduces limitations on constructs such as bridges that you can walk on and under. Due to the nature of PACS a full implementation will need multiple tools written as well:

* An alternative build_ig_boxes - presently this tool creates a 2D box based on the bounding box of the instance group (group of objects, e.g. building)

* Alternative implementations of build_indoor_rbank and build_rbank.

The "rbank" concept is uniquely PACS but some similar implementation must exist as NeL-based servers use PACS on the server side for collision detection and error correction and it is an undue burden for servers to load and process 3D data in order to generate collision objects. The "rbank" or "retriever bank" represents essential collision objects such as trees and the landscape itself. The "indoor rbank" represents the internals of buildings (and where the various "portals" to buildings are.) This allows the server to know where you are and perform detailed collision detection with a miniaml amount of overhead.

In addition to replacing PACS with Bullet or ODE it would be desirable to have a 3D collision module that allows for advanced client side simulation effects such as rag doll physics.

*Requirements:* C++, Physics, ODE or Bullet.

h2. NeLNet

h3. Implement a Qt displayer for NLNET Services.

*Difficulty:* Easy to Moderate

*Priority:* Low

*Description:*

Presently NeL has three displayer types for NLNET Services: Windows, GTK and Console. NeL is in the process of converting its tools to use Qt and would like to maintain consistency throughout. We would like to implement the NLNET displayer in Qt. The new displayer need not mimic the existing displayers layout and flexibility in designing the new displayer to be more modern is desired. The code for this is technically in the NeLMisc module but the UI displayers are used almost exclusively for NeLNet-based services: "displayer.h":http://dev.ryzom.com/projects/nel/repository/entry/nel/include/nel/misc/displayer.h and "displayer.cpp":http://dev.ryzom.com/projects/nel/repository/entry/nel/src/misc/displayer.cpp and "gtk_displayer.cpp":http://dev.ryzom.com/projects/nel/repository/entry/nel/src/misc/gtk_displayer.cpp

*Requirements:* C++, Qt

h2. NeLNS

h3. New and Improved Login Service

*Difficulty:* Moderate

*Priority:* Medium

*Description:*

We would like to update the Login Service (LS) and the supporting client classes to be more flexible in a variety of ways. We would like it to have more controls and flexibility around managing and securing user-operated shards. One of the goals would be to provide more information downstream to the shard (via the LS connectivity to the Welcome Service) as well as providing a reference implementation of a web-based account management tool. This web-based tool would be independent of the admin service tools.

*Requirements:* C++, PHP

h2. NeL Tools

h3. Convert Object Viewer to be Qt-based.

*Difficulty:* Moderate

*Priority:* High

*Description:*

One of the primary tools used by programmers and designers alike is the Object Viewer. It is currently a Windows only tool and we want to rewrite this tool using Qt, ensuring that it is cross platform. The finished product must run on Windows, Linux and Mac OS X. Our goal will not be simply to mock the Object Viewer into a new UI toolkit but also take the opportunity to modernize its interface and make it more usable than the existing interface. In addition to maintaining the current functionality the update Object Viewer should merge the capabilities of of "ZViewer":http://dev.ryzom.com/projects/nel/repository/browse/nel/tools/3d/zviewer into the Object Viewer, allowing for landscape zones to be viewed and for dynamic settings to be controlled. Pop up menus should be avoided and properties boxes should be used instead, see right-hand dock in NeL Qt sample.

A basic demonstration of using NeL 3D in a Qt widget is provided in "NeL Qt":http://dev.ryzom.com/projects/nel/repository/browse/nel/samples/3d/nel_qt 

Provided are screenshots from our NeL Qt Demo and a screenshot of the existing Object Viewer for comparison:

!nel_qt_update.png!

!ov_2.jpg!

*Requirements:* C++, Qt

h3. Convert Georges Editor to Qt

*Difficulty:* Moderate

*Priority:* Medium

*Description:*

One of the tools used by programmers and content creators is the Georges Editor. It is a tool used to edit data loaded into the game. It is currently a Windows only tool and we want to rewrite this tool using Qt, ensuring that it is cross platform. The finished product must run on Windows, Linux and Mac OS X. The Georges Editor should provide an editing interface for types (.typ), definitions (.dfn) as well as forms/sheets. Types define basic Georges types and the UI element used for editing these types. Definitions define the structure and layout of forms and sheets and finally the forms/sheets are the actual data that will be loaded into a client or server. There are numerous examples of Georges usage within the framework itself as well as in community projects. A desirable optional feature for this editor would be to add sheet management - the ability to manage the sheet_id.bin and generate new sheet_ids. The Sheet ID system is used to assign a unique ID to a sheet for transmission between services and clients.

*Requirements:* C++, Qt

h3. Create Blender Exporter

*Difficulty:* Difficult

*Priority:* Very High

*Description:*

Presently NeL only officially supports 3DStudio MAX with a contributed plugin for Maya. We would like to expand our modeler support to include an Open Source modeling package, Blender. This exporter must be capable of exporting 3D mesh, animation and landscapes.

*Requirements:* C++, Blender, Python

h3. Create COLLADA Converter

*Difficulty:* Extremely Difficult

*Priority:* Medium

*Description:*

Presently NeL only officially supports 3DStudio MAX with a contributed plugin for Maya. We would like to expand our modeler support to include COLLADA-supporting modeling softwares. This exporter must be capable of exporting 3D mesh, animation and landscapes. Due to the nature of COLLADA some work will be necessary in the NeL3D module to add support for deficient areas of the 3D engine, namely adding more interpolation techniques.

*Requirements:* C++, 3D Algorithms

h3. Web-based Translation Chain Tool

*Difficulty:* Easy

*Priority:* Low

*Description:*

We would like to create a web-based tool chain for managing translations. This would provide an easier way for words and phrases to be submitted to the I18N files for translation efforts.

*Requirements:* PHP

h3. Landscape Editor

*Difficulty:* Difficult

*Priority:* Medium

*Description:*

We would like an external tool for for editing and painting landscape. This tool would need to be capable of generating and editing large bezier patches as well as providing varying levels of detail editing and ultimately the ability to save to NeL-compatible zone files. If the application is not a pure-NeL application and uses a windowing toolkit the toolkit used must be Qt.

* Allow creation of a single zone through a template such as a heightmap.

* Allow manipulation of the bezier patches with a variety of "brush" sizes.

* Allow a preview mode that compiles the patch data into a usable zone to view through NL3D's landscape system directly.

* Allow the painting of landscape through a selectable tile bank. 

* Allow painting with a variety of brush sizes. 

* Allow painting of layers (small, large and transition layers.)

*Requirements:* C++, 3D Algorithms, Qt (optional)

h3. BNP Tool Extensions

*Difficulty:* Easy to Moderate

*Priority:* Low

*Description:*

BNP is a virtual file system we use to package game information and media data. At present the tools for manipulating BNP files is simple. We would like to add one or more of the following extensions to the BNP tool chain:

* Make a kio for KDE platforms.

* Make a FUSE based file system for Linux.

* Make a shell extension for Windows.

* WinZip-style application for editing/managing them (written in Qt).

*Requirements:* C++, Varying

h3. Expand Object Viewer Zone Support

*Difficulty:* Moderate

*Priority:* Low

*Description:*

Visualizing objects/shapes, zones (landscanpe and clusters/portals (indoor/outdoor scenes) is presently accomplished through three GUI tools: Object Viewer, ZViewer and Cluster Viewer. We want to consolidate this functionality into Object Viewer. 

*Requirements:* C++

h3. Create a GUI Interface for 3D Pipeline

*Difficulty:* Easy to Moderate

*Priority:* Low

*Description:*

We would like to create a Qt-based GUI application capable of performing the build_gamedata functionality but we would like to eliminate the dependency on that pipeline for this tool and consolidate the functionality and logic of the steps into the tool. This tool would allow programmers and graphic designers to visually manage the steps of the process.

*Requirements:* C++, Qt

h3. Create Advanced Sound Sample

*Difficulty:* Easy to Moderate

*Priority:* Medium

*Description:*

We would like to create an advanced sound sample that allows the user to experience more of the features and functionality of the sound system. This sample would expand upon the existing sound_sources sample by adding a _very basic_ 3D presentation, music, ambient sounds and what ever other features of NeLSound are able to be completed within the project time.

*Requirements:* C++

h3. Advanced 3D Samples

*Difficulty:* Moderate

*Priority:* Medium

*Description:*

We would like to write a series of samples demonstrating the more advanced features of the 3D engine. The list of features will be dependent upon time and resources but will include a simple landscape demonstration, animations, particles and special effects. 

*Requirements:* C++

h2. Snowballs

h3. Implement CEGUI Support in Snowballs

*Difficulty:* Moderate

*Priority:* High

*Description:*

The GUI for Snowballs is very rudimentary. We would like to implement our NeL CEGUI Renderer for Snowballs and add better menu management to the game. This would be a significant modification of the existing functionality to Snowballs. Desired changes are:

* Implementation of CI18N using a PropertyCallback. The system would watch loaded layouts _Text_ properties and identify I18N tokens (e.g. i18n:SettingsButtonName) and then use NeL's CI18N to load the text into the button.

* Implementation of most if not all of the window event behavior through Lua scripting.

* Addition of a main menu that precedes the existing normal loading.

* Allow both local play and online play using menus: the Play Online button would require use of the CLoginClient in DirectClient mode to authenticate/authorization with the LS and retrieve a cookie/frontend combination.

* Create a Settings dialog to manage config file settings (such as landscape thresholds, video driver, etc.)

* Implement a HUD using CEGUI a CEGUI layout.

*Requirements:* C++, XML 

h3. Implement Sound in Snowballs

*Difficulty:* Moderate

*Priority:* Medium

*Description:*

Snowballs needs to be updated to take advantage of the NeLSound module. We want to add functionality into Snowballs to play sound effects for actions, interface interactions, environmental sounds and background music.

* Implement sounds for common UI actions such as clicking buttons.

* Implement sound tracks for entity-related actions such as walking, throwing snowballs and being hit.

* Implement ambient and environmental sounds for certain locations such as the cave.

* Implement background music and add volume control logic to the system configuration and UI (if applicable.)

*Requirements:* C++

h3. Implement Basic Game Logic in Snowballs

*Difficulty:* Easy to Moderate

*Priority:* High

*Description:*

Currently Snowballs has none of the original game logic. We would like to add some of this logic in both from a client and from a server perspective. Examples of new functionality would be the ability to track hits in a database, implement "hit-effects" such as freezing in place for a period of time. The following new game mechanics should be implemented in the Snowballs services:

* Implement chat-channels. The system should have two channels: global and local and the local channel should be spatially filtered.

* Implement score tracking. Whenever a player successfully hits another player the system should track that hit in their score. It should also track when they've been hit and by whom.

* Implement "hit-effects" in the POS service. Prevent the player for moving for a period of time after being hit. Position correction logic already exists in the collision service as a reference.

*Requirements:* C++

h3. Create Snowballs Game Page

*Difficulty:* Easy

*Priority:* Medium

*Description:*

We would like to create a players-page for Snowballs that allows players to view scores, high scores, their character information and more. This could be comprised of simple shard level information and then a larger game-level site that allows the viewing of all configured shard information. Presently the Snowballs shards must be run wide open with no personalization. We would like to allow users to do the following account-related activities:

* Sign up for the Snowballs game.

* Change password.

* View Snowballs profiles. Allow players to view each others statistics such as:

** How many hits they have.

** How many times they've been hit.

** Who hits them the most often.

** Who do they hit the most often.

* Allow viewing of high scores, top ten lists.

*Requirements:* PHP

h3. Build Snowballs AI Service

*Difficulty:* Difficult

*Priority:* Low

*Description:*

We would like to build a simple AI service for snowballs that is able to perform scripted events, control entities in a semi-intelligent fashion.

*Requirements:* C++

h2. Miscellaneous

h3. Implement MySQL Helper Library

*Difficulty:* Difficult

*Priority:* Low

*Description:*

Several of the NeLNS services use MySQL to persist information such as shard statistics, player and character information. We would like to create a helper library to simplify the NeL-developer's exposure to MySQL. This library would simplify calls to SQL, handle error catching and abstract the MySQL such that the NeL developer is only exposed to it as a last resort. It may be possible to utilize another library to do this, but a reference implementation using a NeLNS service must be created to demonstrate.

*Requirements:* C++

h2. Need To Discuss

The following ideas can be discussed further if anyone is interested in them. They are no less important than the others but have no received sufficient discussion by the community to determine the requirements or priority. Do not be afraid to ask about these:

* Create new Qt-based Log Analyzer

** Add additional plugins or create new scriptable functionality for analyzing logs.

* Fix NeLNS Admin deficiencies

** Create a log server compliant with CNetDisplayer

** Update admin web app to be capable of using the new logging server

** Modernize the admin web app (Web 2.0)

* Create an entity management layer that provides pluggable gameplay logic (behavior) identifying information (properties.)

** For inspiration look at "CEL":http://www.crystalspace3d.org/main/CEL

* As an extension on the audio and bitmap file support, support for video playback within nel would be pretty interesting as well.

** Perhaps it could be useful to have all of these in a new nel media library, to avoid putting too many external dependencies within the core libraries.

* Convert and modernize the Tile Editor interface to be Qt-based.

** This is already mostly done, but not modernized. It will need to be completed, tested and merged into the source tree.

** See "Issue 219":http://dev.ryzom.com/issues/219

* Web based (ajax, googlemaps) World editor to edit level design.