Difference between revisions of "GSOC ideas"
From Bitfighter
Watusimoto (Talk | contribs) |
Watusimoto (Talk | contribs) |
||
| (3 intermediate revisions by the same user not shown) | |||
| Line 3: | Line 3: | ||
These projects all need to be fleshed out. Points to consider: difficulty level, prerequisites, description and who to ask (See here for an example: http://www.hedgewars.org/gsoc_ideas2012.html) | These projects all need to be fleshed out. Points to consider: difficulty level, prerequisites, description and who to ask (See here for an example: http://www.hedgewars.org/gsoc_ideas2012.html) | ||
| − | * Centralized level repository | + | * '''Tutorial level/mode''' |
| − | * Custom music for levels including central music repository | + | * '''Centralized level repository''' |
| − | * '''Add IPV6 support to TNL layer''' -- Bitfighter currently works with IPv4, but not IPv6. Our | + | * '''Custom music for levels including central music repository''' -- We would like to allow level designers to specify which music plays during a level. This could help set the appropriate mood and ambiance. The music we currently distribute with the game is somewhat thematically limited (by design), so it would be nice if players could add their own music. Our idea is that there could be a central music repository hosted at bitfighter.org, and players could specify any song in that repo for use in their levels. When a player loads a level with custom music, if that music is not yet cached on the player's machine, it will be downloaded from the central repo, and stored locally for future use. In order to ensure that music distributed this way is properly licensed (and to do some basic quality control), only devs could add music to the central repo (usually upon suggestion of a designer that wanted to use it). Therefore, we would need some sort of mechanism for uploading proposed music to the repo, and for those with proper authority to approve it and add it. This mechanism would probably work outside of the game, and would probably be based on some combination of php and html. This project is probably not terribly difficult, but there are many parts that would need to work together, so it might be an interesting multi-technology project. |
| − | * Bring sanity to client-side prediction system | + | * '''Add IPV6 support to TNL layer''' -- Bitfighter currently works with IPv4, but not IPv6. Our networking library, TNL, has some stubs for IPv6, but they need to be more fully developed. If you take on this project, you will be somewhat on your own as none of the mentors really knows how to do this. This could be an interesting project; it might be relatively easy... or not. We just don't know. |
| − | * Journal (replay/save games) | + | * '''Bring sanity to client-side prediction system''' |
| − | * Mobile port work | + | * '''Journal (replay/save games)''' |
| − | * Observer mode | + | * '''Mobile port work''' |
| − | * Automated testing/unit testing | + | * '''Observer mode''' |
| − | * GLES2 | + | * '''Automated testing/unit testing''' |
| − | * Further development of robot players and cool levelgens | + | * '''GLES2''' |
| − | * Feasibility of web client | + | * '''Further development of robot players and cool levelgens''' |
| − | * Extraction and improving physics system (with an eye to simplify collision detection) | + | * '''Feasibility of web client''' |
| + | * '''Extraction and improving physics system (with an eye to simplify collision detection)''' | ||
| + | * '''Lua API documentation''' -- We are rapidly building out our Lua API, and our documentation has not been keeping up. The documentation was originally maintained by hand, then we converted to an automated system based on Doxygen. Unfortunately, Doxygen was not designed for working with Lua/C++ hybrid code, so we use a Perl script to rip through our source and create a set of files that are easier for Doxygen to digest. This generally works pretty well, but very little attention has been paid to making the result usable. The documentation is pretty much there, but what we need is someone to make it more readable. This could be a small, limited project focused on Bitfighter, or it could be made into a broader project looking at solving Lua/C++ documentation in a way that could be leveraged by other projects, using Bitfighter as a case study. | ||
===== EASY PROJECTS ===== | ===== EASY PROJECTS ===== | ||
* Create stats page listing all the stuff we collect on a player; stats will be sent from master upon connect. | * Create stats page listing all the stuff we collect on a player; stats will be sent from master upon connect. | ||
Latest revision as of 19:08, 25 March 2013
Some ideas for GSOC projects:
These projects all need to be fleshed out. Points to consider: difficulty level, prerequisites, description and who to ask (See here for an example: http://www.hedgewars.org/gsoc_ideas2012.html)
- Tutorial level/mode
- Centralized level repository
- Custom music for levels including central music repository -- We would like to allow level designers to specify which music plays during a level. This could help set the appropriate mood and ambiance. The music we currently distribute with the game is somewhat thematically limited (by design), so it would be nice if players could add their own music. Our idea is that there could be a central music repository hosted at bitfighter.org, and players could specify any song in that repo for use in their levels. When a player loads a level with custom music, if that music is not yet cached on the player's machine, it will be downloaded from the central repo, and stored locally for future use. In order to ensure that music distributed this way is properly licensed (and to do some basic quality control), only devs could add music to the central repo (usually upon suggestion of a designer that wanted to use it). Therefore, we would need some sort of mechanism for uploading proposed music to the repo, and for those with proper authority to approve it and add it. This mechanism would probably work outside of the game, and would probably be based on some combination of php and html. This project is probably not terribly difficult, but there are many parts that would need to work together, so it might be an interesting multi-technology project.
- Add IPV6 support to TNL layer -- Bitfighter currently works with IPv4, but not IPv6. Our networking library, TNL, has some stubs for IPv6, but they need to be more fully developed. If you take on this project, you will be somewhat on your own as none of the mentors really knows how to do this. This could be an interesting project; it might be relatively easy... or not. We just don't know.
- Bring sanity to client-side prediction system
- Journal (replay/save games)
- Mobile port work
- Observer mode
- Automated testing/unit testing
- GLES2
- Further development of robot players and cool levelgens
- Feasibility of web client
- Extraction and improving physics system (with an eye to simplify collision detection)
- Lua API documentation -- We are rapidly building out our Lua API, and our documentation has not been keeping up. The documentation was originally maintained by hand, then we converted to an automated system based on Doxygen. Unfortunately, Doxygen was not designed for working with Lua/C++ hybrid code, so we use a Perl script to rip through our source and create a set of files that are easier for Doxygen to digest. This generally works pretty well, but very little attention has been paid to making the result usable. The documentation is pretty much there, but what we need is someone to make it more readable. This could be a small, limited project focused on Bitfighter, or it could be made into a broader project looking at solving Lua/C++ documentation in a way that could be leveraged by other projects, using Bitfighter as a case study.
EASY PROJECTS
- Create stats page listing all the stuff we collect on a player; stats will be sent from master upon connect.
