Difference between revisions of "Google Summer of Code/2008"

From BZFlagWiki
Jump to: navigation, search
m (Protected "Google Summer of Code/2008" [edit=autoconfirmed:move=autoconfirmed])
(Program Evaluation)
Line 31: Line 31:
 
While there's never any guarantee that work on any code will be integrated, this is very much the desire and '''intention''' of our participation in the Summer of Code.  Students are expected to interact on the [http://my.bzflag.org/irc/ #bzflag IRC channel] on the Freenode network, abide by the [http://bzflag.svn.sourceforge.net/viewvc/*checkout*/bzflag/trunk/bzflag/DEVINFO DEVINFO] rules, agree to the [[Google Summer of Code Acceptance|development requirements]], and focus on providing a clean maintainable implementation.
 
While there's never any guarantee that work on any code will be integrated, this is very much the desire and '''intention''' of our participation in the Summer of Code.  Students are expected to interact on the [http://my.bzflag.org/irc/ #bzflag IRC channel] on the Freenode network, abide by the [http://bzflag.svn.sourceforge.net/viewvc/*checkout*/bzflag/trunk/bzflag/DEVINFO DEVINFO] rules, agree to the [[Google Summer of Code Acceptance|development requirements]], and focus on providing a clean maintainable implementation.
  
Biding BZFlag's acceptance into the program, the final list of selected proposals will be announced on April 14, 2008 at 12:00 noon PDT.
+
The final list of selected proposals will be announced on April 14, 2008 at 12:00 noon PDT.
  
 
= Proposal Ideas =
 
= Proposal Ideas =

Revision as of 04:05, 22 March 2008

The Google Summer of Code 2008 was announced on February 25, 2008. BZFlag has been accepted again this year as a mentoring organization. Given our enormously successful participation in the program in 2007, BZFlag will again participate in the program in 2008. BZFlag will accept student project proposals from March 24 to March 31 ending at 5:00 PDT (0:00 April 1 GMT). Further information on the application process and some proposal ideas are below.

Promotion Flyers

BZGSoC2008 small.gif

Provided below is a promotional flyer to help spread the word about our involvement with the Google Summer of Code. Flyers are available in various languages that we have mentors for so that students from all over the globe can be informed about the program. While many developers can converse fluently in other languages, English is still expected for most developer discussions. Feel free to distribute the flyer around your local colleges and universities.

High praise and special thanks to Harry Keller (aka Saturos) for designing our 2008 GSoC flyer.

Preparing an Application

There is specific format to applications, but students should be detailed in their approach and background information about themselves. They should state specifically what they intend to deliver and any implementation details they feel relevant such as what language they intend to use. C/C++ proposals are preferred though others will be considered. Students that just submit the summaries contained below will not do very well. If you talk with us on IRC about your SoC proposal, you should include your IRC nickname somewhere in your proposal.

Early proposal submission are encouraged as it gives us more time to review your proposals in detail, comment on them, and potentially ask for additional input. Submitting closer to the deadline will not be a negative consideration as all submissions will be predominantly judged on their merit, but submitting and discussing early is an advantage for submissions that are similar to other submissions.

Students are asked to propose what they actually want to work on, how they intend to work on it, what they intend to DO, what they know about that task, some details about themselves, etc. Their ability to perform the task is outright presumed, so they are supposed to propose a task that they are comfortable and knowledgeable with performing.

Program Evaluation

All the applications we receive will be reviewed, evaluated, and critiqued. Of those applications, only a few can be selected to work on BZFlag. We expect to receive many good applications, making the selection process very competitive and difficult. This cannot be stressed enough. It will be really hard to narrow down the submissions but in the end we will have only so many slots to work with and the line will eventually need to be drawn. Every application will be read multiple times and reviewed in detail. We thank everyone that submits a proposal and hope to still see some of you become involved in our software development.

In the end, submissions will be selected according to the overall long-term impact that accepting the proposal could make for the game, perception of the submitter's abilities to complete the task within the program timeframe, general consensus on the technical approach being proposed, and overall interest in having such modifications made to BZFlag. Particular notice will be made of students that are responsive to questions and readily interactive in the IRC channel. Communication is a good thing.

While there's never any guarantee that work on any code will be integrated, this is very much the desire and intention of our participation in the Summer of Code. Students are expected to interact on the #bzflag IRC channel on the Freenode network, abide by the DEVINFO rules, agree to the development requirements, and focus on providing a clean maintainable implementation.

The final list of selected proposals will be announced on April 14, 2008 at 12:00 noon PDT.

Proposal Ideas

While there are lots of Ideas floating around of varying utility to the game, the ideas listed below are the specific areas that we are predominantly interested in seeing worked on as part of the GSoC. Please note that students are also welcome and encouraged to apply with their own ideas. They should run those ideas by one of the developers beforehand to make sure they are consistent with the scope and focus of the project, though, as there are some ideas which will not be accepted regardless of the quality of the application and applicant. We've additionally provided several project ideas important to BZFlag development that we would very much like to see proposals for, shown in following.

Ideas marked with an "*" asterisk indicate entries where we have received at least two or more applicant submissions for that idea.

Suggest your own idea

BZFlag is always open to new development ideas and is under constant improvement. If you are familiar with BZFlag's current capabilities and would like to propose some new enhancement, we'd be happy to hear about. Please discuss any new ideas with the existing core developers (on our IRC channel), if only to make sure the ideas are in-line with the spirit and constraints of the game.

Cheat preventions

This task involves making BZFlag more robust towards preventing various cheats from working in the game. This task implicitly requires adding protections on the server, moving game logic from the client to the server, and/or adding heuristics and other measures for detecting and dealing with cheat clients. The student should have a strong grasp of the variety of BZFlag cheats that are available. Please go into detail about which cheats you're interested in preventing and how you intend to employ those preventive measures. For information on known cheats, check out the Known Cheats wiki page.

Global authentication daemon

The goal of this project would be to provide global account management system daemon that the client and servers would communicate with for account, group membership, and profile information. This effort preferably be written in C++, would need to talk to an LDAP server for persistent storage on the backend, and allow chaining across multiple daemons for data replication and failover service. The daemon would need to provide a well structured simple communications API that the game client and game servers can securely talk to.

BZWorkBench world editor enhancement

As a participant in last year's program, Jude Nelson started work on BZWorkBench. It is a world file editor with a very solid foundation but much work still remains to be done, including a cross-platform GUI, mesh support, and other editor features. Ideally, two students would work on this. For example, one student could focus on improving the GUI's workflow and ease-of-use, and another could focus on finishing the back-end object manipulation. The current GUI does not conform to a specific HIG, nor does its usability resemble many other 3D editors; this should change. The back-end still lacks support for many of the objects added in BZFlag 2.0, such as Meshes, texture matrices, dynamic colors, etc.

Enhanced server listing

The game client includes a simplistic listing of publicly available servers. This task would involve significantly enhancing the listing section in BZFlag to allow for various sortings (e.g. ping time, country, name, etc), favorites, recently used, specific additional information on specific servers, and all existing information. The task would involve coming up with a user-friendly design that is fully keyboard-accessible. It could leverage external gui toolkits, use BZFlag's existing gui library, and/or extend the existing capabilities. The focus would be on creating an intuitive and informative listing enhancement within the constraints of the gaming interface.

Modularization of game logic

Much of the game logic is presently mixed in with BZFlag's graphics code. This lack of organization make it difficult to find code when necessary, and does not allow bzfs, bzrobots, or other tools to utilize the game logic. The game code should be modularized into libgame so that all that is left in the client code is the graphics subsystem. This will also ease the possible future integration of a 3D graphics engine.

Dead Reckoning and other Networking Enhancements

The basic idea is to improve BZFlag's networking by performing dead reckoning on the server along with context-sensitive packet delivery culling. Much work has gone into the game towards moving more and more of the game state to the server, but there is additional migration and protocol changes required. Similarly, network utilization can be optimized by not relaying certain packets (like miniscule position updates to distant players) based on the current game state. Some useful background reading for this task include "Fairness in Dead-Reckoning based Distributed Multi-Player Games (pdf)" and "Accuracy in Dead-Reckoning Based Distributed Multi-Player Games (pdf)".

Enhanced cross-platform multiple display support

Add the ability to effectively manage multiple display environments from within the game allowing for the detection, alignment/orientation specification, and resolution parameters for each display via menu options as well as proper full-screen and/or windowed support. An additional feature could involve allowing the user to dedicate a display to the various primary gui elements (the 3D environment, the radar, and the chat console). BZFlag's current context management is mostly handled by SDL or other platform-specific modules, so this could be taken into consideration. There's also the possibility of our move to an integrated graphics engine would similarly impact how multidisplay contexts are created and managed.

Enhanced Statistics system

The goal of this idea would be to extend the existing web based statistics system to be more robust.

Features could include:

  • Better integration with the list server.
  • Use of a plug-in or server based stat "push" system instead of the current "pull" system.
  • Better publishing of stats
  • Publishing of recorded stat data to other sites.
  • Better tracking of registered and unregistered players
  • Tracking of leagues and individual match games.
  • Generalizing the stats system to be used in other games/projects.

Integrated BZFS web interface

The BZFlag game server, BZFS, could benefit from having a browser-accessible http/https interface for viewing server statistics, setting various parameters, and otherwise controlling the server daemon while it is running. Similar to how your network router has a web interface for changing configuration parameters, this idea is simply to create this interface in a maintainable and portable manner. Please go into detail on how exactly you'd go about doing this.

Network Testing and Simulation Environment

This task should provide a controlled testing environment for simulating network behavioral characteristics, including the ability to change virtual network parameters to induce different network conditions of lag and packet loss. This environment should provide a viewer capability to observe interactions of BZFlag clients being tested from the perspective of the player, the server, and third-party observers. This simulation framework should work with the client and server directly so that testing of actual changes may be performed in a stand-alone environment.

Cross server communications system

This task would be the design and implementation of a server spanning chat system. It would allow players from one server to send chat messages to players on other servers. It should also be able to be used to allow players to know where there friends or "buddies" are playing if they are online. The system should tie into the central user name registration system. Added benefits would be the use of existing protocols or applications, such as Jabber or IRC, if they can be integrated cleanly. Support for using off-line apps for chat and friends list access as well as server management would be a plus.

In-game profile management

BZFlag allows players to specify a callsign and team in addition to other player characteristics and preferences. This enhancement would focus on allowing the user to specify and manage multiple profiles from within the game. Profiles could be linked together and should be presented in an intuitive manner (proposal should highlight how you'd go about achieving that). The profiles would need to associate with global account information as well.

Thanks & Appreciation

Thank you to the following individuals in the BZFlag community that helped prepare GSoC-related marketing materials:

  • Harry Keller (aka Saturos)
  • Julio Jiménez Borreguero (aka jujibo aka Manu)
  • Dexter Mason (aka whodaman)
  • Sean Morrison (aka learner aka brlcad)
  • Jeffrey Myers (aka JeffM)