Difference between revisions of "Google Summer of Code"

From BZFlagWiki
Jump to: navigation, search
(tense correction)
(add a section on preparing applications)
Line 1: Line 1:
BZFlag has been accepted to participate in the 2007 Google Summer of Code.  We are currently accepting applications and proposals to work on BZFlag; please apply through Google.  While there are lots of [[Ideas]] floating around of varying utility to the game, the ideas listed below are specific areas that we are interested in seeing worked on as part of the GSoC.  These tasks are selected according to the overall impact that they can make to the game, feasibility of implementation within '''two or three''' months, and overall interest in having such modifications made to BZFlag.  While there's no guarantee that work on any code will be integrated, this is very much the desire and intention -- it is expected that students will interact on the [http://my.bzflag.org/irc/ #bzflag IRC channel] on the Freenode network, abide by the [http://bzflag.cvs.sourceforge.net/*checkout*/bzflag/bzflag/DEVINFO DEVINFO] rules, and focus on providing a clean maintainable implementation.
+
BZFlag has been accepted to participate in the 2007 [http://code.google.com/soc/ Google Summer of Code].  We are currently accepting applications and proposals to work on BZFlag; please apply through Google.  While there are lots of [[Ideas]] floating around of varying utility to the game, the ideas listed below are specific areas that we are interested in seeing worked on as part of the GSoC.  These tasks are selected according to the overall impact that they can make to the game, feasibility of implementation within '''two or three''' months, and overall interest in having such modifications made to BZFlag.  While there's no guarantee that work on any code will be integrated, this is very much the desire and intention -- it is expected that students will interact on the [http://my.bzflag.org/irc/ #bzflag IRC channel] on the Freenode network, abide by the [http://bzflag.cvs.sourceforge.net/*checkout*/bzflag/bzflag/DEVINFO DEVINFO] rules, and focus on providing a clean maintainable implementation.
 +
 
 +
= Preparing an Application =
 +
 
 +
There is no specific format to applications, but you should be detailed in your approach and background information about yourself.  Please state specifically what you indend to deliver and any implementation details you feel relevant such as what language you intend to use.  C/C++ proposals are preferred though others will be considered.  Submit your application to Google [http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants here].
 +
 
 +
= Proposal Ideas =
  
 
Please note that you are also welcome to apply with your own original ideas.  You may wish to run them by one of the developers beforehand, as there are some ideas which will not be accepted regardless of the quality of the application and applicant, due to desire to preserve the scope and focus of the project.
 
Please note that you are also welcome to apply with your own original ideas.  You may wish to run them by one of the developers beforehand, as there are some ideas which will not be accepted regardless of the quality of the application and applicant, due to desire to preserve the scope and focus of the project.

Revision as of 22:26, 16 March 2007

BZFlag has been accepted to participate in the 2007 Google Summer of Code. We are currently accepting applications and proposals to work on BZFlag; please apply through Google. While there are lots of Ideas floating around of varying utility to the game, the ideas listed below are specific areas that we are interested in seeing worked on as part of the GSoC. These tasks are selected according to the overall impact that they can make to the game, feasibility of implementation within two or three months, and overall interest in having such modifications made to BZFlag. While there's no guarantee that work on any code will be integrated, this is very much the desire and intention -- it is expected that students will interact on the #bzflag IRC channel on the Freenode network, abide by the DEVINFO rules, and focus on providing a clean maintainable implementation.

Preparing an Application

There is no specific format to applications, but you should be detailed in your approach and background information about yourself. Please state specifically what you indend to deliver and any implementation details you feel relevant such as what language you intend to use. C/C++ proposals are preferred though others will be considered. Submit your application to Google here.

Proposal Ideas

Please note that you are also welcome to apply with your own original ideas. You may wish to run them by one of the developers beforehand, as there are some ideas which will not be accepted regardless of the quality of the application and applicant, due to desire to preserve the scope and focus of the project.

Graphics Engine Integration

One of the long-standing desires for BZFlag is to improve the graphics capabilities in the game by integrating with an existing rendering engine. This task would be to integrate BZFlag with a graphics engine like OGRE, Crystal Space, OpenSceneGraph, or Irrlicht.

Dead Reckoning 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)".

Headless Artificial Intelligence Agent

This task involves creating a clean stand-alone version of the game client that is headless (i.e. requires no GUI to run), programmable, and scriptable. Ideally, a programming interface that is compatible with an existing framework such as the Robocode API should be made available for controlling AI tank players so that collaboration with other AI efforts can be leveraged. A scripting interface (perhaps using SWIG) should be provided on top of that API to allow dynamic control of the AI agents from a scripting language like Python, Ruby, Lua, Tcl, or Perl.

Global Authentication Daemon

Building upon the existing global login infrastructure, the goal of this project would be to provide global account management from within the game client. Working with the other developers, this effort involves writing an authentication daemon in C++ that the client and game servers talk to for account and group management information. The daemon in turn should 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 will need to provide a well structured communications API that the game client and game servers can securely talk to to register, authenticate against for login, obtain group membership information, and statistics information.

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.

World file layout and editing application

This task should produce an application for the creation/modification/arrangement of BZW map files and objects in a visual manner. The application should be designed in a cross platform compatible manner (ether some existing cross platform framework, or a built in platform system). The application should be able to manage all the existing structures in a BZW world file. Ideally, the application should also be able to import 3d meshes from other design applications. It would not be required to be able to dynamically edit meshes in the application.