This wiki is archived and useful information is being migrated to the main bzflag.org website

Difference between revisions of "Google Summer of Code"

From BZFlagWiki
Jump to: navigation, search
(bzflag launcher)
m (2010)
 
(57 intermediate revisions by 11 users not shown)
Line 1: Line 1:
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.
+
__NOTOC__
  
= Preparing an Application =
+
 +
=Overview=
  
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.  Please do not just submit the summaries contained below as they are high-level ideas.  Your proposal should be detailed and more specific.  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].
+
Starting in 2005, Google has run an open source software development program specifically for students called the [http://code.google.com/soc/ Google Summer of Code] (GSoC).  Under this program, Google funds students to write code for open source projects during the northern hemisphere's summer timeframe.  The student efforts are focused on projects that they themselves propose to projects such as BZFlag, sometimes catering to ideas that the project suggests or ideas entirely of the student's own conception.  Student proposals are then reviewed, evaluated, and ranked by the project.  Google allocates a certain number of slots to each participating project/organization which in turn determines how many student developers we get to work with.
  
= Proposal Ideas =
+
Students that participate with the BZFlag project are required to adhere to specified [[Google Summer of Code Acceptance|development requirements]], selected students then work on their projects through the summer.  Students are expected to be fully integrated with the BZFlag development community throughout the program, actively engaged in their work, and intently working ''with'' the other BZFlag developers throughout the design and implementation of their projects.  If the student successfully completes what they propose, they are ultimately paid $4500 for their work and the BZFlag community hopefully gains a new long-term developer.  In all, the program is a pretty darn good deal for many students, great publicity and marketing for both Google and BZFlag, and an excellent opportunity for attracting new long-term BZFlag developers.
  
Please note that you are also welcome to apply with your own original ideasYou 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.
+
'''''Attracting and mentoring new long-term developers is our primary goal.''''' If this interests you, please let us know and submit a GSoC application.
  
== Graphics Engine Integration ==
+
=2010=
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 [http://ogre3d.org/ OGRE], [http://www.crystalspace3d.org/ Crystal Space], [http://www.openscenegraph.com/ OpenSceneGraph], or [http://irrlicht.sourceforge.net/ Irrlicht].
+
BZFlag will not be applying to SOC 2010 in order to concentrate on the release of V3.
 +
==Past years==
 +
See
 +
[[Google_Summer_of_Code/2009|2009 GSoC page]]
  
== Dead Reckoning Networking Enhancements ==
+
[[Google_Summer_of_Code/2008|2008 GSoC page]]
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 "[http://www.research.ibm.com/netgames2005/papers/aggarwal.pdf Fairness in Dead-Reckoning based Distributed Multi-Player Games (pdf)]" and "[http://www.sigcomm.org/sigcomm2004/workshop_papers/net610-aggarwal.pdf Accuracy in Dead-Reckoning Based Distributed Multi-Player Games (pdf)]".
+
  
== Headless Artificial Intelligence Agent ==
+
[[Google_Summer_of_Code/2007|2007 GSoC page]]
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 [http://robocode.sourceforge.net/ Robocode] [http://www-128.ibm.com/developerworks/java/library/j-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 [http://www.swig.org/ 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 ==
+
for past projects.
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 ==
+
= Getting started =
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 ==
+
* Read this page
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.
+
* Read our [[Google Summer of Code/2009|proposal ideas]] page
 +
* Read our [[Google_Summer_of_Code/Application_Guidelines|application guidelines]]
 +
* Read our [[Google Summer of Code Acceptance|requirements]]
 +
* Read our [http://bzflag.svn.sourceforge.net/viewvc/*checkout*/bzflag/trunk/bzflag/DEVINFO DEVINFO] file
 +
* Join our [[BZFlag on IRC|#bzflag on Freenode]] IRC channel
 +
* Formulate a proposal idea, communicate with devs
 +
* [http://sourceforge.net/tracker/?group_id=3248&atid=303248 Submit a patch]
 +
* Apply!
  
== IRC communications backend ==
+
= Preparing an application =
There are plans to integrate BZFlag servers onto an IRC network such that all servers will have a shared server-to-server global communications backend as well as access from IRC.  The servers would effectively act as a filtered proxy for all clients, receiving and relying messages from/throughout the network.  The game clients themselves would not connect to IRC in order to avoid configuration issues (e.g. firewalls) and abuse.  Each BZFlag server would, however, join an IRC network ([http://freenode.net Freenode]) and act as a relay for select messages; allow for server control and message relay from within IRC; and provide server-specific channels as well as join a unified channel for all servers.  This implementation should use an existing IRC networking interface like [http://libIRC.org libIRC] instead of being home-grown.
+
  
== In-game IRC client ==
+
There is intentionally no specific format to our applications. '''BUT'''... students are '''strongly''' encouraged to be detailed, creative, and interactive with the BZFlag developers throughout the application processProposals that are detailed in their approach and contain useful background information about the individual's abilities and their ideas will generally receive more attentionApplications should specify what you intend to deliver, a reasonable development timeline, and any implementation details that are relevant such as what language(s) you intend to useC/C++ proposals are generally preferred since that is our predominant codebase and developer expertise though others are considered. See our '''[[Google_Summer_of_Code/Application_Guidelines|Application Guidelines]]''' for more details.
The basic idea is to provide a means for players to connect to BZFlag IRC channels on [http://freenode.net Freenode] from within the BZFlag clientSimilar to other games that provide this functionality, the interface is separate from the game itself usually as pre-configured menu options whereby players could join an IRC channel instead of joining a game server to communicate/collaborateThere should be measures in place to reduce IRC abuse such as channel limiting (either outright to a predetermined set of channels or via some naming convention like #bz_hepcat), flow and flood limits, and optional language/spam filteringUse of existing IRC libraries or clients such as [http://libIRC.org libIRC], [http://www.irssi.org irssi], [http://www.mirc.com mIRC], or others would be strongly preferred (with attention towards ease of integration and maintainability).
+
  
== BZFlag Launcher ==
+
Early proposal submissions are encouraged as it gives the mentors more time to review the proposal in detail, comment on it, potentially ask for additional input, and iterate with the student on your ideasIn the past, submitting closer to the deadline hasn't been a negative consideration, as all submissions are predominantly judged on merit, but submitting and discussing early do tend to be an advantage if there are others applications that have similar goals.
This task would involve implementing a BZFlag "launcher" that allows for configuration of certain game aspects prior to starting up the full client environment.  A configuration splash screen of sorts that allows selection of full-screen or windowed, video modes, performs any useful setup, perhaps server selection, or more (there are loads of options possible, see -help list)The interface should be as extensively cross-platform (as much as existing client), easy to integrate with (no introduction of complex dependencies like qt or gtk), and easy to maintain -- ideally using existing BZFlag GUI routines or some small/lightweight GUI library like [http://www.cegui.org.uk CEGUI].
+
  
== New Flag(s) ==
+
Students should propose what they actually want to work on, how you intend to work on it, what you intend to DO, what you know about that task, some details about yourself, etc.  Be detailed and articulate.  Brief proposals do not generally do very well.  Your ability to perform the task is outright presumed by the nature of submitting a detailed applicationStudents should propose a task that they are comfortable and knowledgeable with performing within the timeframe of the program and considering any extenuating circumstances.
At the core of BZFlag is the idea of game flags that enhance or modify the behavior of the gameThey can be good or bad flags with fairly arbitrary behavioral changes.  This task would involve picking one or more of the approved [[Flag Ideas]] and implementing it cleanly through to completion.
+
  
== <INSERT YOUR IDEA HERE> ==
+
You may submit more than one application (one application for each project you would enjoy working on) if you so desire.  This can help us when we receive more than one strong proposal for a single project, as generally speaking we will accept only one application for each projectHowever, please do not submit proposals for work you will not enjoy doing, and please do not sacrifice quality for quantity.  One good application makes a much better impression than two half-baked applications.
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 aboutPlease 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.
+
  
= Promotion Flyers =
+
If you talk with us on IRC about your SoC proposal, be sure to include your IRC nickname somewhere in your proposal.
  
[[Image:BZGSoC2007 small.gif]]
+
You should also [http://sourceforge.net/tracker/?group_id=3248&atid=303248 submit a patch] before you submit your application, and be sure to include a link to the tracker item in your proposal submission.  See the [[Google Summer of Code Acceptance|development requirements]] for details.
  
Feel free to use the below flyer to help spread the word about our involvement with the Google Summer of Code.  We'd love to hear about where all our flyer has been posted at through our [http://my.bzflag.org/irc/ IRC channel].  Flyers have been translated to other languages that we have mentors for, though please submit your application in English. While many developers can converse (fluently) in other languages, we do ask that developer discussions be held in English where possible.
+
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, and agree to the [[Google Summer of Code Acceptance|development requirements]] before submitting an application.
  
* English ([http://my.bzflag.org/gsoc/BZGSoC2007.pdf PDF]) ([http://my.bzflag.org/gsoc/BZGSoC2007.png PNG])
+
Thanks for your interest and we look forward to seeing you apply!
* Deutsch | German  ([http://my.bzflag.org/gsoc/BZGSoC2007_de.pdf PDF]) ([http://my.bzflag.org/gsoc/BZGSoC2007_de.png PNG])
+
* Español | Spanish ([http://my.bzflag.org/gsoc/BZGSoC2007_es.pdf PDF]) ([http://my.bzflag.org/gsoc/BZGSoC2007_es.png PNG])
+
<!-- * Italiano | Italian ([http://my.bzflag.org/gsoc/BZGSoC2007_it.pdf PDF]) ([http://my.bzflag.org/gsoc/BZGSoC2007_it.png PNG])-->
+
  
= Mentors and Credits =
+
= The application review process =
  
Thanks to the following BZFlag developers for their participation as mentors:
+
Just about every participating GSoC organization receives considerably more project proposals than can be accepted.  All the applications are reviewed, evaluated, and critiqued individually.  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 (so make sure your application is excellent).  ''This cannot be stressed enough.''  It is rather hard for most projects to narrow down the submissions but in the end there are only so many slots to work with and the line eventually has to be drawn.  Every application gets read multiple times and reviewed in detail.  We thank '''everyone''' that submits a proposal and hope to see many of you become involved in BZFlag software development regardless of acceptance.
 +
 +
In the end, submissions are selected according to the overall long-term impact that accepting the proposal can 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, how well the student communicates with other developers, the perception that the individual is interested in being a long-term BZFlag developer, and our overall interest in having the proposed modifications made to BZFlag.  Particular notice is made of students that are responsive to questions and readily interactive in the IRC channel.  Communication is one of the most important criteria.
  
* Julio Borreguero (aka jujibo aka Manu)
+
= BZFlag participation in GSoc =
* Sean Morrison (aka learner aka brlcad)
+
**  interested in AI and authentication list server services
+
* Jeffrey Myers (aka JeffM2501)
+
** interested in game editor
+
* Daniel Remenak (aka DTRemenak aka Erroneous)
+
* Mark Thomas (aka menotume)
+
* David Trowbridge (aka purple_cow)
+
* Alfredo Tupone (aka c3po)
+
** interested in Crystal Space integration
+
  
Additionally, special thanks to others in #bzflag that have provided support and feedback including:
+
== [[Google Summer of Code/2009|2009 (more details here)]] ==
  
* a_meteorite and DTRemenak
+
'''''We've been accepted.'''''
** for proofreading and copy editing the GSoC submission
+
 
* JeffM2501 and DTRemenak
+
We intend to only accept at most three student slots this year.  Our focus this year is on quality and cleanup so we can make a major release.  Cleaning up and refactoring existing code is much more important to us this year than writing new code.
** for proof editing the promotional flyer
+
 
* Saturos
+
== [[Google Summer of Code/2008|2008 (more details here)]] ==
** for translating the promotional flyer to German
+
{|align="right"
* quantumdot and Manu
+
|[[Image:BZGSoC2008_small.gif |thumb|left|128px]]
** for translating the promotional flyer to Spanish
+
|}
* others...
+
 
 +
The Google Summer of Code 2008 was announced on February 25, 2008. Given the substantial successes and opportunities provided by the program, BZFlag continues to participate in the program.  We accepted six students, five of whom were integrated into our development community.
 +
 
 +
== [[Google Summer of Code/2007|2007 (more details here)]] ==
 +
{|align="right"
 +
|[[Image:BZGSoC2007_small.gif|thumb|left|128px]]
 +
|}
 +
BZFlag first participated during GSoC's third year in 2007. A detailed after-the-fact discussion and analysis of BZFlag's first-year participation is included in the article ''[http://my.bzflag.org/gsoc/bzflag_gsoc2007_post_mortem.pdf “Postmortem” Perspectives of a First-year Participant in the 2007 Google Summer of Code for BZFlag]''.  This article was given to Google in August 2007 as a final report, per se, of our involvement (you're only a first-year participant once).
 +
 
 +
We accepted four students, three of whom were successful in their projects.
 +
 
 +
 
 +
==== [[Google Summer of Code/2007#Promotion Flyers|Promotion Flyers]] ====
  
Thanks for your interest and we look forward to seeing students apply!
 
  
 
[[Category: Development]]
 
[[Category: Development]]

Latest revision as of 16:15, 12 March 2010


Overview

Starting in 2005, Google has run an open source software development program specifically for students called the Google Summer of Code (GSoC). Under this program, Google funds students to write code for open source projects during the northern hemisphere's summer timeframe. The student efforts are focused on projects that they themselves propose to projects such as BZFlag, sometimes catering to ideas that the project suggests or ideas entirely of the student's own conception. Student proposals are then reviewed, evaluated, and ranked by the project. Google allocates a certain number of slots to each participating project/organization which in turn determines how many student developers we get to work with.

Students that participate with the BZFlag project are required to adhere to specified development requirements, selected students then work on their projects through the summer. Students are expected to be fully integrated with the BZFlag development community throughout the program, actively engaged in their work, and intently working with the other BZFlag developers throughout the design and implementation of their projects. If the student successfully completes what they propose, they are ultimately paid $4500 for their work and the BZFlag community hopefully gains a new long-term developer. In all, the program is a pretty darn good deal for many students, great publicity and marketing for both Google and BZFlag, and an excellent opportunity for attracting new long-term BZFlag developers.

Attracting and mentoring new long-term developers is our primary goal. If this interests you, please let us know and submit a GSoC application.

2010

BZFlag will not be applying to SOC 2010 in order to concentrate on the release of V3.

Past years

See 2009 GSoC page

2008 GSoC page

2007 GSoC page

for past projects.

Getting started

Preparing an application

There is intentionally no specific format to our applications. BUT... students are strongly encouraged to be detailed, creative, and interactive with the BZFlag developers throughout the application process. Proposals that are detailed in their approach and contain useful background information about the individual's abilities and their ideas will generally receive more attention. Applications should specify what you intend to deliver, a reasonable development timeline, and any implementation details that are relevant such as what language(s) you intend to use. C/C++ proposals are generally preferred since that is our predominant codebase and developer expertise though others are considered. See our Application Guidelines for more details.

Early proposal submissions are encouraged as it gives the mentors more time to review the proposal in detail, comment on it, potentially ask for additional input, and iterate with the student on your ideas. In the past, submitting closer to the deadline hasn't been a negative consideration, as all submissions are predominantly judged on merit, but submitting and discussing early do tend to be an advantage if there are others applications that have similar goals.

Students should propose what they actually want to work on, how you intend to work on it, what you intend to DO, what you know about that task, some details about yourself, etc. Be detailed and articulate. Brief proposals do not generally do very well. Your ability to perform the task is outright presumed by the nature of submitting a detailed application. Students should propose a task that they are comfortable and knowledgeable with performing within the timeframe of the program and considering any extenuating circumstances.

You may submit more than one application (one application for each project you would enjoy working on) if you so desire. This can help us when we receive more than one strong proposal for a single project, as generally speaking we will accept only one application for each project. However, please do not submit proposals for work you will not enjoy doing, and please do not sacrifice quality for quantity. One good application makes a much better impression than two half-baked applications.

If you talk with us on IRC about your SoC proposal, be sure to include your IRC nickname somewhere in your proposal.

You should also submit a patch before you submit your application, and be sure to include a link to the tracker item in your proposal submission. See the development requirements for details.

Students are expected to interact on the #bzflag IRC channel on the Freenode network, abide by the DEVINFO rules, and agree to the development requirements before submitting an application.

Thanks for your interest and we look forward to seeing you apply!

The application review process

Just about every participating GSoC organization receives considerably more project proposals than can be accepted. All the applications are reviewed, evaluated, and critiqued individually. 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 (so make sure your application is excellent). This cannot be stressed enough. It is rather hard for most projects to narrow down the submissions but in the end there are only so many slots to work with and the line eventually has to be drawn. Every application gets read multiple times and reviewed in detail. We thank everyone that submits a proposal and hope to see many of you become involved in BZFlag software development regardless of acceptance.

In the end, submissions are selected according to the overall long-term impact that accepting the proposal can 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, how well the student communicates with other developers, the perception that the individual is interested in being a long-term BZFlag developer, and our overall interest in having the proposed modifications made to BZFlag. Particular notice is made of students that are responsive to questions and readily interactive in the IRC channel. Communication is one of the most important criteria.

BZFlag participation in GSoc

2009 (more details here)

We've been accepted.

We intend to only accept at most three student slots this year. Our focus this year is on quality and cleanup so we can make a major release. Cleaning up and refactoring existing code is much more important to us this year than writing new code.

2008 (more details here)

BZGSoC2008 small.gif

The Google Summer of Code 2008 was announced on February 25, 2008. Given the substantial successes and opportunities provided by the program, BZFlag continues to participate in the program. We accepted six students, five of whom were integrated into our development community.

2007 (more details here)

BZGSoC2007 small.gif

BZFlag first participated during GSoC's third year in 2007. A detailed after-the-fact discussion and analysis of BZFlag's first-year participation is included in the article “Postmortem” Perspectives of a First-year Participant in the 2007 Google Summer of Code for BZFlag. This article was given to Google in August 2007 as a final report, per se, of our involvement (you're only a first-year participant once).

We accepted four students, three of whom were successful in their projects.


Promotion Flyers