Removed cyphesis and wombat for this year.
← Older revision
Revision as of 19:16, 15 March 2013
(2 intermediate revisions by one user not shown)
Line 28:
Line 28:
= Ideas List =
= 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 [https://blueprints.launchpad.net/ember Ember
Launchpad], [https://blueprints.launchpad.net/cyphesis Cyphesis Launchpad] and [https://blueprints.launchpad.net/wombat 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.
+
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 [https://blueprints.launchpad.net/ember 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 ==
== Ember Ideas ==
Line 48:
Line 48:
=== Allow for dynamically dowloadable remote resources ===
=== Allow for dynamically dowloadable remote resources ===
−
* '''Summary''': Add support for dynamically downloadable remote
ressources
+
* '''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.
* '''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 [http://www.ogre3d.org Ogre], and deal with network transfer, probably through the libwfut library.
* '''Technical Details''': This is a task which will require the student to both learn Ember and [http://www.ogre3d.org Ogre], and deal with network transfer, probably through the libwfut library.
Line 56:
Line 56:
* '''Mentor''': [[User:Erik|Erik Ogenvik]]
* '''Mentor''': [[User:Erik|Erik Ogenvik]]
−
===
Automatic adjustment of graphical level
===
+
===
Replace current terrain manager with Ogre terrain component
===
−
* '''Summary''':
Design a system which will automatically adjust
the
graphical detail level so that framerate is smooth
+
* '''Summary''':
Replace existing terrain manager with
the
more capable Ogre terrain component.
−
* '''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
.
+
* '''Description''':
The existing terrain manager isn't optimal. Instead we want
to
use
the
one provided by [http://www.ogre3d.org/tikiwiki/tiki-index.php?page=Ogre+Terrain+System Ogre]. Integrating it into Ember involves replacing
the
existing
terrain
manager with it
,
but also adapting the shaders
currently
used for terrain rending to it
.
−
* '''Specification''': More
details
can be found [https://blueprints.launchpad.net/ember/+spec/ember-
automatic-level
-
adjustment
here]
.
+
* '''Technical Details''':
This
is
a
task
which will
require
the
student to both learn Ember
and
[http://www.ogre3d.org Ogre]. There will be some shader coding involved
.
−
* '''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
.
+
* '''Specification''': More
information
can be found [https://blueprints.launchpad.net/ember/+spec/ember-
terrain
-
component
here].
−
* '''Difficulty''':
medium
+
* '''Difficulty''':
hard
−
* '''Technical requirements''':
standard
C++
+
* '''Technical requirements''':
medium
C++
, basic shader knowledge
* '''Mentor''': [[User:Erik|Erik Ogenvik]]
* '''Mentor''': [[User:Erik|Erik Ogenvik]]
−
===
Dynamic calculating of lower LOD versions for meshes
===
+
===
Integrate SmartBody
===
−
* '''Summary''':
Implement dynamic and automatic creation of low-LOD versions of meshes, to be used
for
far away entities
.
+
* '''Summary''':
Integrate the SmartBody system
for
humanoid movement into Ember
.
−
* '''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
.
+
* '''Description''':
[http://smartbody.ict.usc.edu 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.
−
* '''Specification''': More
details
can be found [https://blueprints.launchpad.net/ember/+spec/ember-
automatic-mesh-lod
here]
.
+
* '''Technical Details''': This is a task which will require the student to both learn Ember and [http://smartbody.ict.usc.edu SmartBody]. [http://www.ogre3d.org Ogre] will also
be
touched upon, but to a lesser extent
.
−
* '''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
.
+
* '''Specification''': More
information
can be found [https://blueprints.launchpad.net/ember/+spec/ember-
smartbody
here].
* '''Difficulty''': medium
* '''Difficulty''': medium
−
* '''Technical requirements''':
standard
C++
+
* '''Technical requirements''':
medium
C++
* '''Mentor''': [[User:Erik|Erik Ogenvik]]
* '''Mentor''': [[User:Erik|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 [https://blueprints.launchpad.net/cyphesis/+spec/gs-fortification here].
−
* '''Difficulty''': Medium-Hard
−
* '''Technical Requirements''': Python, basic XML, optionally C++
−
* '''Mentor''': [[User:Alriddoch|Alistair Riddoch]]
== Infrastructure ideas ==
== Infrastructure ideas ==
−
==== Infrastructure Prerequisites ====
==== Infrastructure Prerequisites ====
Line 99:
Line 81:
* You should have a good knowledge of systems design and networking
* 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.
* 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 [https://blueprints.launchpad.net/cyphesis/+spec/metaserver-ng here].
−
* '''Difficulty''': Hard
−
* '''Technical Requirements''': C++, networking
−
* '''Mentor''': [[User:Alriddoch|Alistair Riddoch]]
=== Develop WorldForge security ===
=== Develop WorldForge security ===
Line 119:
Line 91:
* '''Technical Requirements''': C++
* '''Technical Requirements''': C++
* '''Mentor''': [[User:Alriddoch|Alistair Riddoch]]
* '''Mentor''': [[User:Alriddoch|Alistair Riddoch]]
−
−
== WOMBAT ideas ==
−
−
==== WOMBAT Prerequisites ====
−
* You need to know your way around [http://www.python.org 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 [http://www.pocoo.org/projects/flask/#flask Flask] or [http://www.pocoo.org/projects/werkzeug/#werkzeug 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''': [[User:KaiBlin| Kai Blin]]
== Ryzom Core Ideas ==
== Ryzom Core Ideas ==
Line 413:
Line 370:
== Misc hints ==
== Misc hints ==
You can find more ideas on the [https://blueprints.launchpad.net/worldforge/ WorldForge blueprints page].
You can find more ideas on the [https://blueprints.launchpad.net/worldforge/ WorldForge blueprints page].
−
If you have any questions or want to suggest your own project, please contact us, either directly to [[User:Erik|Erik]] for [[Ember
]] projects, to [[User:Alriddoch|AlRiddoch]] for [[Cyphesis]] projects, to [[User:KaiBlin|Kai]] for [[Wombat
]] projects or through one of our [[Main_Page#Communication_Channels|communication channels]].
+
If you have any questions or want to suggest your own project, please contact us, either directly to [[User:Erik|Erik]] for [[Ember]] projects or through one of our [[Main_Page#Communication_Channels|communication channels]].
=For accepted students=
=For accepted students=