BZFlagWiki - User contributions [en]

BZFlag SVN

2010-02-23T18:42:53Z

Learner: /* Committing Code to SVN */

BZFlag SVN, is the [http://en.wikipedia.org/wiki/Subversion_(software) Subversion Revision Control System] used by the development team to maintain and store the [[BZFlag Source]] code. The SVN system is hosted by [http://www.sourceforge.net SourceForge] and is accessible by anyone with the proper software. The SVN system replaces the [[BZFlag CVS]] system that was used in the past.

==SVN clients==
To access the source code via SVN , you will need a SVN client. Most unix/linux type operating systems have the command line SVN client as an installable option. Windows users must download the Windows native [http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=91 SVN command line utility] or a third party SVN client, such as [http://tortoisesvn.tigris.org/ the Tortoise Graphical SVN Client] (highly recommended). SVN is also available to Windows users via [http://cygwin.com/ Cygwin] with SVN and other common Devel tools selected during installation.

==Getting code from SVN Access==
===Command line===
The simplest way to get the bzflag source code is to use the URL for the current ( or TRUNK ) bzflag module.

svn co <nowiki>https://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag</nowiki>

This will get you the current bzflag source code for the development version.

If you want the SVN code for the 2.0.x compatible version use the URL

svn co <nowiki>https://bzflag.svn.sourceforge.net/svnroot/bzflag/branches/v2_0branch/bzflag</nowiki>

If you wish to get all of our source code in one step, you can get the entire repository with the command.

svn co <nowiki>https://bzflag.svn.sourceforge.net/svnroot/bzflag</nowiki> bzflag

This will get all modules, branches, tags, and subdirs. Beware! This is a very large amount of data (make sure you have at least 2.7 GB of disk space available) and will take a while and will be rather useless, as it is the code for every version of bzflag. Most users will only need the code for one specific version.

The '''best''' way, is to only get the subdir for the module you are interested in. This is much more efficient and suitable for most users. The most common module to get is the bzflag module, as it is the actual game.

Please see the sections below for more information about the URLs to use for branches and modules.

===TortoiseSVN===

Windows users that use the Tortoise Graphical SVN Client simply enter the URL of the SVN path they wish to check out in the field marked ''URL of repository''. For the current version of all modules simply use the /trunk path. Note, if you want your code to be checked out into a new folder, be sure to enter that folder name in the ''Checkout directory'' field.

If you wish to get only a single module subdir, or a revision, simply use the URL specified in the sections below.

==Committing Code to SVN==

Project developers that need write access to the source code to make changes ( or [[commits]] ) need to provide their sourceforge username and password when doing a SVN commit. A sourceforge account is required for developer access, as well as approval from a project administrator.

Please make sure that your svn config file includes the correct [[Auto-props]]. If you get a [[Mime-types]] error, you either didn't enable the correct auto-props setting in your subversion config file or you need to manually set file properties.

===Command Line===
Using the command
svn commit
in a directory that has code changes will commit any changed code back to the repository. The svn client will prompt you for your username and password.

===TortoiseSVN===
Windows users that use the Tortoise Graphical SVN Client can simply choose the SVN commit item, and enter their username and password when prompted.

Tortoise users may set auto-props from the General Settings property page; click the Edit button and paste the auto-props into the correct section, then un-comment the "enable-auto-props = yes" line above it.

==Updating code from SVN to the current version==

===Command Line===
Using the command
svn up
in the directory that has checked out code will cause subversion to update that code to the current version for that branch.

===TortoiseSVN===
Windows users that use the Tortoise Graphical SVN Client can simply choose the SVN update item from their right click menus.

==Reverting local code to the server's version==

===Command Line===
Using the command
svn revert
svn up
in the directory that has checked out code will cause subversion to set flags on all modified local files, then update the code to match the code on the server. NOTE: This has the effect of wiping out all local changes, so use with caution!

===TortoiseSVN===
Right click on the file or directory you would like to revert and from the TortoiseSVN submenu, select '''Revert...'''. The menus is context sensitive, so there must be code that has been modified for the menu choice to be available.

==Module sub directories==

The source code in SVN is broken up into a number of modules for ease of use and management. When requesting the source code from the SVN system a sub-directory may be specified to limit the code that is accessed.

The current SVN modules are:
*bzflag : The main module that includes the game [[BZFlag 2.0.8|client]], [[BZFS|server]], [[plug-ins]], and [[BZAdmin]].
*admin : The [[Master Ban]] list
*bzedit : The linux version of the BZFlag map editor [[BZEdit]]
*bzeditw32 : The windows version of the BZFlag map editor [[BZEditWin32]]
*web : The main website at http://www.bzflag.org
*db : Files related to the website http://my.bzflag.org and the [[Global Registration]] system.
*pybzflag : an abandoned python implementation of BZFlag
*bzworkbench : The source code for [[BZWorkBench]]
*bzwgen: The source code for the automatic city generator.

to get the current version of a module, you would add
/trunk/MODULE_NAME
after the normal SVN URL.

so to get the current version of just the bzflag module, the URL would be

<nowiki>https://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag/</nowiki>

From the command line

svn co <nowiki>https://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag</nowiki>

==Branches==
Branches in subversion are simply subfolders.
All branches are in the /branches subdirectory off the root level of the SVN tree, listed [http://bzflag.svn.sourceforge.net/viewvc/bzflag/branches/ here].
To get the code in a branch, you simply use the branch URL in your svn client.

To get the 2.0.x branch of the BZFlag module, you'd use the following URL.
https://bzflag.svn.sourceforge.net/svnroot/bzflag/branches/v2_0branch/bzflag/

==Useful Tools==

===Windows===

'''Tortoise Graphical SVN Client''': integrates subversion into the windows explorer shell. http://tortoisesvn.tigris.org/

'''Ankh Subversion''': integrates subversion into Visual C++ as a native source control provider. http://ankhsvn.tigris.org/

'''WinMerge''': visual merge and diff tool for windows. http://winmerge.org/

==See also==
[[Versions]]

==External Links==
[http://sourceforge.net/svn/?group_id=3248 SourceForge SVN Access page]

[http://bzflag.svn.sourceforge.net/viewvc/bzflag/ BZFlag SVN Tree]

[[Category:Development]]
[[Category:Compiling]]
[[Category:Versions]]

Auto-props

2010-02-23T18:40:16Z

Learner:

Developers should make sure their Subversion auto-props are set correctly before committing to [[SVN]]. This helps preserve the correct line endings across platforms. This is the "standard" auto-props section we are using (you may of course set your own if you prefer). You'll need to edit your config file(s), which varies depending on platform and Subversion client.

For UNIX-like platforms, edit your ''~/.subversion/config'' file to set the auto-props. For Windows Vista, the path is ''C:\Users\YOUR_USERNAME\AppData\Roaming\Subversion\config'' And for Windows XP, the path is ''C:\Documents and Settings\YOUR_USERNAME\Application Data\Subversion\config'' Also, please be sure that you uncomment the '''enable-auto-props''' option and set it to yes. An example subversion config files is shown in following:

<pre>
### Section for configuring automatic properties.
[auto-props]
### The format of the entries is:
### file-name-pattern = propname[=value][;propname[=value]...]
### The file-name-pattern can contain wildcards (such as '*' and
### '?'). All entries which match will be applied to the file.
### Note that auto-props functionality must be enabled, which
### is typically done by setting the 'enable-auto-props' option.
*.c = svn:eol-style=native
*.cpp = svn:eol-style=native
*.cxx = svn:eol-style=native
*.def = svn:eol-style=native
*.h = svn:eol-style=native
*.pl = svn:eol-style=native
*.py = svn:eol-style=native
*.php = svn:eol-style=native

*.po = svn:eol-style=native
*.am = svn:eol-style=native
*.ac = svn:eol-style=native
*.in = svn:eol-style=native
*.m4 = svn:eol-style=native

*.dsp = svn:eol-style=CRLF
*.dsw = svn:eol-style=CRLF
*.sln = svn:eol-style=CRLF
*.vcproj = svn:eol-style=CRLF
*.nsi = svn:eol-style=CRLF
*.manifest = svn:eol-style=CRLF

*.sh = svn:eol-style=native;svn:executable
*.bat = svn:eol-style=native;svn:mime-type=text/plain

*.txt = svn:eol-style=native;svn:mime-type=text/plain
README = svn:eol-style=native;svn:mime-type=text/plain
*.html = svn:eol-style=native;svn:mime-type=text/html
*.css = svn:eol-style=native;svn:mime-type=text/css
*.xml = svn:eol-style=native;svn:mime-type=text/xml
*.bzw = svn:eol-style=native

*.xpm = svn:eol-style=native;svn:mime-type=image/x-xpm
*.svg = svn:eol-style=native;svn:mime-type=image/svg+xml
*.bmp = svn:mime-type=image/bmp
*.png = svn:mime-type=image/png
*.jpg = svn:mime-type=image/jpeg
*.ogg = svn:mime-type=application/ogg
*.wav = svn:mime-type=audio/x-wav
*.ttf = svn:mime-type=application/octet-stream
*.ico = svn:mime-type=application/octet-stream
*.rgb = svn:mime-type=image/x-rgb
</pre>

[[Category:Development]]

Mime-types

2010-02-23T18:39:08Z

Learner: link to the auto-props page

[[category:Design Documents]]

When a developer commits a new file to the repository, they may get an error about mime types not being set. This is because there is (intentionally) a commit hook set up that verifies that there are mime types set on all files being added to the repository.

Subversion uses file mime-types for lots of useful things like for web interface browsing of the repository. You can either set up your subversion config to [[Auto-props|auto-set mime types]] or you can directly set the mime type on the file before you commit the file using svn propset.

Sean provides a copy of his Subversion configuration that includes property settings for many file types. You can download and install it with this:

'''curl http://bzflag.org/~sean/subversion.config > ~/.subversion/config'''

Once installed, run ''svn revert'' on your new file and then add it again. The properties should be set if the config file is installed properly and it's a recognized file type.

This problem usually looks like this:

[sean@bz (Wed May 28 13:27:55) bzflag]$ svn commit some_new_file.c
Sending some_new_file.c
Transmitting file data ...svn: Commit failed (details follow):
svn: MERGE request failed on '/svnroot/bzflag/trunk/bzflag'
svn: 'pre-commit' hook failed with error output:
/var/local/mastertree/service-svn/hook-scripts/check-mime-type.pl:

bzflag/trunk/bzflag/some_new_file.c : svn:mime-type is not set

Every added file must have the svn:mime-type property set. In
addition text files must have the svn:eol-style property set.

For binary files try running
svn propset svn:mime-type application/octet-stream path/of/file

For text files try
svn propset svn:mime-type text/plain path/of/file
svn propset svn:eol-style native path/of/file

You may want to consider uncommenting the auto-props section
in your ~/.subversion/config file. Read the Subversion book
(http://svnbook.red-bean.com/), Chapter 7, Properties section,
Automatic Property Setting subsection for more help.

[sean@bz (Wed May 28 13:28:55) bzflag]$ svn revert some_new_file.c
Reverted 'some_new_file.c'
[sean@bz (Wed May 28 13:29:55) bzflag]$ curl http://bzflag.org/~sean/subversion.config > ~/.subversion/config
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 10810 100 10810 0 0 30099 0 --:--:-- --:--:-- --:--:-- 81278
[sean@bz (Wed May 28 13:30:55) bzflag]$ svn add some_new_file.c
A some_new_file.c
[sean@bz (Wed May 28 13:31:55) bzflag]$ svn commit some_new_file.c
... no mime type error ...

That said, if one wanted to manually add or change a file's properties:
[sean@bz (Wed May 29 13:50:51) bzflag]$ svn add some_file.odd
A some_new_file.c
[sean@bz (Wed May 29 13:50:51) bzflag]$ svn propset svn:mime-type text/plain some_file.odd
[sean@bz (Wed May 29 13:50:51) bzflag]$ svn propset svn:eol-style native some_file.odd

Mime-types

2010-02-23T18:33:41Z

Learner: show how to manually set properties too

[[category:Design Documents]]

When a developer commits a new file to the repository, they may get an error about mime types not being set. This is because there is (intentionally) a commit hook set up that verifies that there are mime types set on all files being added to the repository.

Subversion uses file mime-types for lots of useful things like for web interface browsing of the repository. You can either set up your subversion config to auto-set mime types or you can directly set the mime type on the file before you commit the file using svn propset.

Sean provides a copy of his Subversion configuration that includes property settings for many file types. You can download and install it with this:

'''curl http://bzflag.org/~sean/subversion.config > ~/.subversion/config'''

Once installed, run ''svn revert'' on your new file and then add it again. The properties should be set if the config file is installed properly and it's a recognized file type.

This problem usually looks like this:

[sean@bz (Wed May 28 13:27:55) bzflag]$ svn commit some_new_file.c
Sending some_new_file.c
Transmitting file data ...svn: Commit failed (details follow):
svn: MERGE request failed on '/svnroot/bzflag/trunk/bzflag'
svn: 'pre-commit' hook failed with error output:
/var/local/mastertree/service-svn/hook-scripts/check-mime-type.pl:

bzflag/trunk/bzflag/some_new_file.c : svn:mime-type is not set

Every added file must have the svn:mime-type property set. In
addition text files must have the svn:eol-style property set.

For binary files try running
svn propset svn:mime-type application/octet-stream path/of/file

For text files try
svn propset svn:mime-type text/plain path/of/file
svn propset svn:eol-style native path/of/file

You may want to consider uncommenting the auto-props section
in your ~/.subversion/config file. Read the Subversion book
(http://svnbook.red-bean.com/), Chapter 7, Properties section,
Automatic Property Setting subsection for more help.

[sean@bz (Wed May 28 13:28:55) bzflag]$ svn revert some_new_file.c
Reverted 'some_new_file.c'
[sean@bz (Wed May 28 13:29:55) bzflag]$ curl http://bzflag.org/~sean/subversion.config > ~/.subversion/config
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 10810 100 10810 0 0 30099 0 --:--:-- --:--:-- --:--:-- 81278
[sean@bz (Wed May 28 13:30:55) bzflag]$ svn add some_new_file.c
A some_new_file.c
[sean@bz (Wed May 28 13:31:55) bzflag]$ svn commit some_new_file.c
... no mime type error ...

That said, if one wanted to manually add or change a file's properties:
[sean@bz (Wed May 29 13:50:51) bzflag]$ svn add some_file.odd
A some_new_file.c
[sean@bz (Wed May 29 13:50:51) bzflag]$ svn propset svn:mime-type text/plain some_file.odd
[sean@bz (Wed May 29 13:50:51) bzflag]$ svn propset svn:eol-style native some_file.odd

Mime-types

2010-02-23T18:11:42Z

Learner: explain the mime-type issue

[[category:Design Documents]]

When a developer commits a new file to the repository, they may get an error about mime types not being set. This is because there is (intentionally) a commit hook set up that verifies that there are mime types set on all files being added to the repository.

Subversion uses file mime-types for lots of useful things like for web interface browsing of the repository. You can either set up your subversion config to auto-set mime types or you can directly set the mime type on the file before you commit the file using svn propset.

Sean provides a copy of his Subversion configuration that includes property settings for many file types. You can download and install it with this:

'''curl http://bzflag.org/~sean/subversion.config > ~/.subversion/config'''

Once installed, run ''svn revert'' on your new file and then add it again. The properties should be set if the config file is installed properly and it's a recognized file type.

This problem usually looks like this:

[sean@bz (Wed May 28 13:27:55) bzflag]$ svn commit some_new_file.c
Sending some_new_file.c
Transmitting file data ...svn: Commit failed (details follow):
svn: MERGE request failed on '/svnroot/bzflag/trunk/bzflag'
svn: 'pre-commit' hook failed with error output:
/var/local/mastertree/service-svn/hook-scripts/check-mime-type.pl:

bzflag/trunk/bzflag/some_new_file.c : svn:mime-type is not set

Every added file must have the svn:mime-type property set. In
addition text files must have the svn:eol-style property set.

For binary files try running
svn propset svn:mime-type application/octet-stream path/of/file

For text files try
svn propset svn:mime-type text/plain path/of/file
svn propset svn:eol-style native path/of/file

You may want to consider uncommenting the auto-props section
in your ~/.subversion/config file. Read the Subversion book
(http://svnbook.red-bean.com/), Chapter 7, Properties section,
Automatic Property Setting subsection for more help.

[sean@bz (Wed May 28 13:28:55) bzflag]$ svn revert some_new_file.c
Reverted 'some_new_file.c'
[sean@bz (Wed May 28 13:29:55) bzflag]$ curl http://bzflag.org/~sean/subversion.config > ~/.subversion/config
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 10810 100 10810 0 0 30099 0 --:--:-- --:--:-- --:--:-- 81278
[sean@bz (Wed May 28 13:30:55) bzflag]$ svn add some_new_file.c
A some_new_file.c
[sean@bz (Wed May 28 13:31:55) bzflag]$ svn commit some_new_file.c
... no mime type error ...

Google Summer of Code: 2009

2009-07-29T15:15:34Z

Learner: update with current info, test cianotify

The 2009 Google Summer of Code was announced in February, 2009. BZFlag is once again participating as a mentoring organization. Given our enormously successful participation in the program in 2007 and 2008, we are very excited to be participating again. We accepted 4 student project proposals for 2009.

= 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.

==High-Priority Project Ideas==

This year our focus is on quality. We need to stabilize our codebase and prepare for a major release. That being the case, a '''*very*''' strong preference will be given to cleanup and refactoring projects over ''new code'' projects. Please keep that in mind when preparing your application and do contact the developers if there are any questions.

=== 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.

'''Difficulty''': variable

=== Lots o' Bug fixing ===
'''''It is often very complicated, difficult, and sometimes not very glamorous but this is our top-priority for 2009.'''''

Basically, this project idea is right up in line with helping new developers become familiarized with the BZFlag code and to help us improve our code quality for an upcoming major release. Propose fixing bugs. You can propose fixing a lot of them or just a few, but you should be detailed and methodical in your approach. Refactoring work related to fixing a bug is great. A progressive/agile/iterative approach to identifying which bugs you intend to look into and fix would also be fantastic.

There is an extensive list of bugs that need to be addressed at https://sourceforge.net/tracker2/?group_id=3248&atid=103248 and http://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag/BUGS at your disposal.

'''Requirements''':
*Familiarity with C/C++
*Good problem solving and diagnostic skills
*(optional) Proficient with a debugger (you will be by the end)

'''Difficulty''': variable

=== 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. ''This is a high-priority idea.''

'''Requirements''':
*Strong familiarity with C/C++
*Basic familiarity with client/server networking applications

'''Difficulty''': medium

=== 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 [[DevelopmentGoals#libGame|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. ''This is a high-priority topic.''

'''Requirements''':
*Familiarity with C/C++

'''Difficulty''': low

=== Modularization of OpenGL logic===
BZFlag's graphics code is (unfortunately) spread throughout the codebase with OpenGL calls being made in thousands of places. The goal of this project would be to encapsulate *all* of the OpenGL calls into one place as a first step towards encapsulating all of the graphics code so that we can adopt a 3D rendering engine. This project should not be to integrate with an engine, though, as there's too much that needs to happen beforehand. Step one is getting all of the graphics code contained. ''This is a high-priority topic.''

'''Requirements''':
*Familiarity with C/C++
*Basic familiarity with OpenGL

'''Difficulty''': low

=== 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. ''This is a high-priority topic.''

'''Requirements''':
*Familiarity with C/C++
*Strong familiarity with networking applications and implications

'''Difficulty''': medium

==Additional Project Ideas ==

While code cleanup and refactoring projects are our top-priority, other projects will certainly be considered if the idea is well thought-out and the student is passionate about the idea. Continuing a previously successful GSoC project is also something very highly desired (even if it does entail new code).

=== BZWorkBench world editor enhancement ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Ability to read through other people's code
*Basic GUI, interaction, and usability design
*Acceptance testing

'''Difficulty''': high

=== Global authentication daemon ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with LDAP
*Familiarity with client/server networking applications

'''Difficulty''': medium

=== Enhanced server listing ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*GUI, usability, and interaction design
*Acceptance testing

'''Difficulty''': low

=== BZRobots ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

BZFlag now has a programmable game client that can be used to implement artificially intelligent (AI) computer players. More work is needeed, though, to clean up the code and deliver bzrobots as a new easy-to-use feature to users. More work is needed. BZRobots conforms to the Robocode API with a few minor (yet necessary) deviations, yet there are a few protocol actions that still need to be implemented. There is also lots of code quality and refactoring issues that need to be addressed. Presently, the code is a copy of the entire client code with user input removed so when a change or bug fix happens to the client, it has to also be manually changed in the bzrobots copy of the code. The code needs to be refactored into common logic shared by both game clients.

See [[BZRobots]] for more information on the current status as well as src/bzrobots in a source checkout.

'''Requirements''':
*Familiarity with C/C++
*Ability to read through an existing code base and refactor appropriately

'''Difficulty''': low

=== Finish server-side players ===
BZFlag includes players that can be run and managed from the server through a server-side plug-in. Unlike the client-side BZRobots project, server-side robots have entirely different issues that they have to account for and information that they have access to. This project would entail taking the work that has already been started to completion. As this is a continuation, please do contact the developers before proposing this idea to determine the current status and work required.

'''Requirements''':
*Familiarity with C/C++
*Ability to pick up a work-in-progress

'''Difficulty''': medium

=== 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 "[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)]".

'''Requirements''':
*Strong familiarity with C/C++
*Strong familiarity with networking applications

'''Difficulty''': high

=== Two-player tanks ===
This always gets some folks excited, but you will have to have already done a lot of research and make a good proposal before this idea will be considered. That said, the topic of having two-player tanks where only one player drives and the other player only shoots has come up many times over the years. BZFlag doesn't allow turret control specifically as a game design feature. An initial two-player tank arrangement would probably not deviate from that requirement initially. Lots of testing, interaction, and feedback are required for this feature to make it to release given how much it potentially would affect gameplay.

'''Requirements''':
*Familiarity with C/C++
*Strong ability to read through existing code
*Acceptance testing

'''Difficulty''': high
(the implementation itself is not hard at all, the acceptance testing will be)

=== 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 3-D 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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with SDL

'''Difficulty''': low

=== Cross-server communications system ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with networking applications
*Acceptance testing

'''Difficulty''': low

===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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with GUI, interaction, and usability design
*Acceptance testing

'''Difficulty''': low

=== Integrated BZFS web interface (aka BZ's WebAdmin plugin) ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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. There was a previous GSoC project that worked on a server-side plugin that provides this feature, but it needs a lot more work both on the interface and in the logic. Be sure to discuss this with the developers before suggesting it.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with GUI, interaction, and usability design
*Acceptance testing

'''Difficulty''': low

= Mentors =

BZFlag operates with a ''group mentoring'' approach meaning that students may (and should) call upon any developer within the community if they have questions. The mentors for 2009 are:

* Sean Morrison (brlcad/learner)
* Daniel Remenak (DTRemenak/Erroneous)
* Jeffrey Myers (JeffM/JeffM2501)
* Julio Jiménez Borreguero (Manu/jujibo)
* Scott Wichser (Blast/Blast007)
* David Wollner (JB diGriz)
* Joe VanOverberghe (joevano/Donny_Baker)
* James Lawrence (spldart)
* Bernt Hansen (Thumper_)
* Jeff Makey (BulletCatcher)
* Jørgen Pedersen Tjernø (jorgenpt)
* Joshua Bodine (Constitution)

[[Category: Development]]

Google Summer of Code: 2009

2009-03-16T16:56:50Z

Learner: server-side players

The 2009 Google Summer of Code was announced in February, 2009. BZFlag will again be applying as a mentoring organization. Given our enormously successful participation in the program in 2007 and 2008, we are very excited to be participating again. If accepted, BZFlag will be accepting student project proposals from March 23 until April 3. Hints and tips on [[Google_Summer_of_Code|getting started, preparing a submission, and the application process]] are available.

Note that for 2009, if BZFlag is accepted back, we're expecting to only accept two or three new students so that we can focus our time and attention on those individuals and our upcoming major release. That means you're really encouraged to talk with us early on and make an outstanding project proposal. The best way to get our attention at this time is to make bug fixes. We look forward to working with you!

= Promotion Flyers =

We're now soliciting designs for our 2009 GSoC promotional flyer. If you are interested in providing a design, please contact us!

= 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.

==High-Priority Project Ideas==

This year our focus is on quality. We need to stabilize our codebase and prepare for a major release. That being the case, a '''*very*''' strong preference will be given to cleanup and refactoring projects over ''new code'' projects. Please keep that in mind when preparing your application and do contact the developers if there are any questions.

=== 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.

'''Difficulty''': variable

=== Lots o' Bug fixing ===
'''''It is often very complicated, difficult, and sometimes not very glamorous but this is our top-priority for 2009.'''''

Basically, this project idea is right up in line with helping new developers become familiarized with the BZFlag code and to help us improve our code quality for an upcoming major release. Propose fixing bugs. You can propose fixing a lot of them or just a few, but you should be detailed and methodical in your approach. Refactoring work related to fixing a bug is great. A progressive/agile/iterative approach to identifying which bugs you intend to look into and fix would also be fantastic.

There is an extensive list of bugs that need to be addressed at https://sourceforge.net/tracker2/?group_id=3248&atid=103248 and http://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag/BUGS at your disposal.

'''Requirements''':
*Familiarity with C/C++
*Good problem solving and diagnostic skills
*(optional) Proficient with a debugger (you will be by the end)

'''Difficulty''': variable

=== 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. ''This is a high-priority idea.''

'''Requirements''':
*Strong familiarity with C/C++
*Basic familiarity with client/server networking applications

'''Difficulty''': medium

=== 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 [[DevelopmentGoals#libGame|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. ''This is a high-priority topic.''

'''Requirements''':
*Familiarity with C/C++

'''Difficulty''': low

=== Modularization of OpenGL logic===
BZFlag's graphics code is (unfortunately) spread throughout the codebase with OpenGL calls being made in thousands of places. The goal of this project would be to encapsulate *all* of the OpenGL calls into one place as a first step towards encapsulating all of the graphics code so that we can adopt a 3D rendering engine. This project should not be to integrate with an engine, though, as there's too much that needs to happen beforehand. Step one is getting all of the graphics code contained. ''This is a high-priority topic.''

'''Requirements''':
*Familiarity with C/C++
*Basic familiarity with OpenGL

'''Difficulty''': low

=== 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. ''This is a high-priority topic.''

'''Requirements''':
*Familiarity with C/C++
*Strong familiarity with networking applications and implications

'''Difficulty''': medium

==Additional Project Ideas ==

While code cleanup and refactoring projects are our top-priority, other projects will certainly be considered if the idea is well thought-out and the student is passionate about the idea. Continuing a previously successful GSoC project is also something very highly desired (even if it does entail new code).

=== BZWorkBench world editor enhancement ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Ability to read through other people's code
*Basic GUI, interaction, and usability design
*Acceptance testing

'''Difficulty''': high

=== Global authentication daemon ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with LDAP
*Familiarity with client/server networking applications

'''Difficulty''': medium

=== Enhanced server listing ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*GUI, usability, and interaction design
*Acceptance testing

'''Difficulty''': low

=== BZRobots ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

BZFlag now has a programmable game client that can be used to implement artificially intelligent (AI) computer players. More work is needeed, though, to clean up the code and deliver bzrobots as a new easy-to-use feature to users. More work is needed. BZRobots conforms to the Robocode API with a few minor (yet necessary) deviations, yet there are a few protocol actions that still need to be implemented. There is also lots of code quality and refactoring issues that need to be addressed. Presently, the code is a copy of the entire client code with user input removed so when a change or bug fix happens to the client, it has to also be manually changed in the bzrobots copy of the code. The code needs to be refactored into common logic shared by both game clients.

See [[BZRobots]] for more information on the current status as well as src/bzrobots in a source checkout.

'''Requirements''':
*Familiarity with C/C++
*Ability to read through an existing code base and refactor appropriately

'''Difficulty''': low

=== Finish server-side players ===
BZFlag includes players that can be run and managed from the server through a server-side plugin. Unlike the client-side BZRobots project, server-side robots have entirely different issues that they have to account for and information that they have access to. This project would entail taking the work that has already been started to completion. As this is a continuation, please do contact the developers before proposing this idea to determine the current status and work required.

'''Requirements''':
*Familiarity with C/C++
*Ability to pick up a work-in-progress

'''Difficulty''': medium

=== 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 "[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)]".

'''Requirements''':
*Strong familiarity with C/C++
*Strong familiarity with networking applications

'''Difficulty''': high

=== Two-player tanks ===
This always gets some folks excited, but you will have to have already done a lot of research and make a good proposal before this idea will be considered. That said, the topic of having two-player tanks where only one player drives and the other player only shoots has come up many times over the years. BZFlag doesn't allow turret control specifically as a game design feature. An initial two-player tank arrangement would probably not deviate from that requirement initially. Lots of testing, interaction, and feedback are required for this feature to make it to release given how much it potentially would affect gameplay.

'''Requirements''':
*Familiarity with C/C++
*Strong ability to read through existing code
*Acceptance testing

'''Difficulty''': high
(the implementation itself is not hard at all, the acceptance testing will be)

=== 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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with SDL

'''Difficulty''': low

=== Cross-server communications system ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with networking applications
*Acceptance testing

'''Difficulty''': low

===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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with GUI, interaction, and usability design
*Acceptance testing

'''Difficulty''': low

=== Integrated BZFS web interface (aka BZ's WebAdmin plugin) ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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. There was a previous GSoC project that worked on a server-side plugin that provides this feature, but it needs a lot more work both on the interface and in the logic. Be sure to discuss this with the developers before suggesting it.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with GUI, interaction, and usability design
*Acceptance testing

'''Difficulty''': low

= Mentors =

BZFlag operates with a ''group mentoring'' approach meaning that students may (and should) call upon any developer within the community if they have questions. The mentors for 2009 are:

* Sean Morrison (brlcad/learner)
* Daniel Remenak (DTRemenak/Erroneous)
* Jeffrey Myers (JeffM/JeffM2501)
* Julio Jiménez Borreguero (Manu/jujibo)
* Scott Wichser (Blast/Blast007)
* David Wollner (JB diGriz)
* Joe VanOverberghe (Donny_Baker)
* James Lawrence (spldart)

[[Category: Development]]

Google Summer of Code: 2009

2009-03-16T16:48:30Z

Learner: expecting at most three students

The 2009 Google Summer of Code was announced in February, 2009. BZFlag will again be applying as a mentoring organization. Given our enormously successful participation in the program in 2007 and 2008, we are very excited to be participating again. If accepted, BZFlag will be accepting student project proposals from March 23 until April 3. Hints and tips on [[Google_Summer_of_Code|getting started, preparing a submission, and the application process]] are available.

Note that for 2009, if BZFlag is accepted back, we're expecting to only accept two or three new students so that we can focus our time and attention on those individuals and our upcoming major release. That means you're really encouraged to talk with us early on and make an outstanding project proposal. The best way to get our attention at this time is to make bug fixes. We look forward to working with you!

= Promotion Flyers =

We're now soliciting designs for our 2009 GSoC promotional flyer. If you are interested in providing a design, please contact us!

= 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.

==High-Priority Project Ideas==

This year our focus is on quality. We need to stabilize our codebase and prepare for a major release. That being the case, a '''*very*''' strong preference will be given to cleanup and refactoring projects over ''new code'' projects. Please keep that in mind when preparing your application and do contact the developers if there are any questions.

=== 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.

'''Difficulty''': variable

=== Lots o' Bug fixing ===
'''''It is often very complicated, difficult, and sometimes not very glamorous but this is our top-priority for 2009.'''''

Basically, this project idea is right up in line with helping new developers become familiarized with the BZFlag code and to help us improve our code quality for an upcoming major release. Propose fixing bugs. You can propose fixing a lot of them or just a few, but you should be detailed and methodical in your approach. Refactoring work related to fixing a bug is great. A progressive/agile/iterative approach to identifying which bugs you intend to look into and fix would also be fantastic.

There is an extensive list of bugs that need to be addressed at https://sourceforge.net/tracker2/?group_id=3248&atid=103248 and http://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag/BUGS at your disposal.

'''Requirements''':
*Familiarity with C/C++
*Good problem solving and diagnostic skills
*(optional) Proficient with a debugger (you will be by the end)

'''Difficulty''': variable

=== 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. ''This is a high-priority idea.''

'''Requirements''':
*Strong familiarity with C/C++
*Basic familiarity with client/server networking applications

'''Difficulty''': medium

=== 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 [[DevelopmentGoals#libGame|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. ''This is a high-priority topic.''

'''Requirements''':
*Familiarity with C/C++

'''Difficulty''': low

=== Modularization of OpenGL logic===
BZFlag's graphics code is (unfortunately) spread throughout the codebase with OpenGL calls being made in thousands of places. The goal of this project would be to encapsulate *all* of the OpenGL calls into one place as a first step towards encapsulating all of the graphics code so that we can adopt a 3D rendering engine. This project should not be to integrate with an engine, though, as there's too much that needs to happen beforehand. Step one is getting all of the graphics code contained. ''This is a high-priority topic.''

'''Requirements''':
*Familiarity with C/C++
*Basic familiarity with OpenGL

'''Difficulty''': low

=== 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. ''This is a high-priority topic.''

'''Requirements''':
*Familiarity with C/C++
*Strong familiarity with networking applications and implications

'''Difficulty''': medium

==Additional Project Ideas ==

While code cleanup and refactoring projects are our top-priority, other projects will certainly be considered if the idea is well thought-out and the student is passionate about the idea. Continuing a previously successful GSoC project is also something very highly desired (even if it does entail new code).

=== BZWorkBench world editor enhancement ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Ability to read through other people's code
*Basic GUI, interaction, and usability design
*Acceptance testing

'''Difficulty''': high

=== Global authentication daemon ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with LDAP
*Familiarity with client/server networking applications

'''Difficulty''': medium

=== Enhanced server listing ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*GUI, usability, and interaction design
*Acceptance testing

'''Difficulty''': low

=== BZRobots ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

BZFlag now has a programmable game client that can be used to implement artificially intelligent (AI) computer players. More work is needeed, though, to clean up the code and deliver bzrobots as a new easy-to-use feature to users. More work is needed. BZRobots conforms to the Robocode API with a few minor (yet necessary) deviations, yet there are a few protocol actions that still need to be implemented. There is also lots of code quality and refactoring issues that need to be addressed. Presently, the code is a copy of the entire client code with user input removed so when a change or bug fix happens to the client, it has to also be manually changed in the bzrobots copy of the code. The code needs to be refactored into common logic shared by both game clients.

See [[BZRobots]] for more information on the current status as well as src/bzrobots in a source checkout.

'''Requirements''':
*Familiarity with C/C++
*Ability to read through an existing code base and refactor appropriately

'''Difficulty''': low

=== 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 "[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)]".

'''Requirements''':
*Strong familiarity with C/C++
*Strong familiarity with networking applications

'''Difficulty''': high

=== Two-player tanks ===
This always gets some folks excited, but you will have to have already done a lot of research and make a good proposal before this idea will be considered. That said, the topic of having two-player tanks where only one player drives and the other player only shoots has come up many times over the years. BZFlag doesn't allow turret control specifically as a game design feature. An initial two-player tank arrangement would probably not deviate from that requirement initially. Lots of testing, interaction, and feedback are required for this feature to make it to release given how much it potentially would affect gameplay.

'''Requirements''':
*Familiarity with C/C++
*Strong ability to read through existing code
*Acceptance testing

'''Difficulty''': high
(the implementation itself is not hard at all, the acceptance testing will be)

=== 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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with SDL

'''Difficulty''': low

=== Cross-server communications system ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with networking applications
*Acceptance testing

'''Difficulty''': low

===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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with GUI, interaction, and usability design
*Acceptance testing

'''Difficulty''': low

=== Integrated BZFS web interface (aka BZ's WebAdmin plugin) ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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. There was a previous GSoC project that worked on a server-side plugin that provides this feature, but it needs a lot more work both on the interface and in the logic. Be sure to discuss this with the developers before suggesting it.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with GUI, interaction, and usability design
*Acceptance testing

'''Difficulty''': low

= Mentors =

BZFlag operates with a ''group mentoring'' approach meaning that students may (and should) call upon any developer within the community if they have questions. The mentors for 2009 are:

* Sean Morrison (brlcad/learner)
* Daniel Remenak (DTRemenak/Erroneous)
* Jeffrey Myers (JeffM/JeffM2501)
* Julio Jiménez Borreguero (Manu/jujibo)
* Scott Wichser (Blast/Blast007)
* David Wollner (JB diGriz)
* Joe VanOverberghe (Donny_Baker)
* James Lawrence (spldart)

[[Category: Development]]

Google Summer of Code: 2009

2009-03-16T16:44:02Z

Learner: /* High-Priority Project Ideas */ emphasize that they are all much more desirable than the rest

The 2009 Google Summer of Code was announced in February, 2009. BZFlag will again be applying as a mentoring organization. Given our enormously successful participation in the program in 2007 and 2008, we're very excited to be participating again and we're very happy to see the applications that were submitted. BZFlag will be accepting student project proposals from March 23 until April 3. Hints and tips on [[Google_Summer_of_Code|getting started, preparing a submission, and the application process]] were available.

= Promotion Flyers =

We're now soliciting designs for our 2009 GSoC promotional flyer. If you are interested in providing a design, please contact us!

= 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.

==High-Priority Project Ideas==

This year our focus is on quality. We need to stabilize our codebase and prepare for a major release. That being the case, a '''*very*''' strong preference will be given to cleanup and refactoring projects over ''new code'' projects. Please keep that in mind when preparing your application and do contact the developers if there are any questions.

=== 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.

'''Difficulty''': variable

=== Lots o' Bug fixing ===
'''''It is often very complicated, difficult, and sometimes not very glamorous but this is our top-priority for 2009.'''''

Basically, this project idea is right up in line with helping new developers become familiarized with the BZFlag code and to help us improve our code quality for an upcoming major release. Propose fixing bugs. You can propose fixing a lot of them or just a few, but you should be detailed and methodical in your approach. Refactoring work related to fixing a bug is great. A progressive/agile/iterative approach to identifying which bugs you intend to look into and fix would also be fantastic.

There is an extensive list of bugs that need to be addressed at https://sourceforge.net/tracker2/?group_id=3248&atid=103248 and http://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag/BUGS at your disposal.

'''Requirements''':
*Familiarity with C/C++
*Good problem solving and diagnostic skills
*(optional) Proficient with a debugger (you will be by the end)

'''Difficulty''': variable

=== 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. ''This is a high-priority idea.''

'''Requirements''':
*Strong familiarity with C/C++
*Basic familiarity with client/server networking applications

'''Difficulty''': medium

=== 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 [[DevelopmentGoals#libGame|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. ''This is a high-priority topic.''

'''Requirements''':
*Familiarity with C/C++

'''Difficulty''': low

=== Modularization of OpenGL logic===
BZFlag's graphics code is (unfortunately) spread throughout the codebase with OpenGL calls being made in thousands of places. The goal of this project would be to encapsulate *all* of the OpenGL calls into one place as a first step towards encapsulating all of the graphics code so that we can adopt a 3D rendering engine. This project should not be to integrate with an engine, though, as there's too much that needs to happen beforehand. Step one is getting all of the graphics code contained. ''This is a high-priority topic.''

'''Requirements''':
*Familiarity with C/C++
*Basic familiarity with OpenGL

'''Difficulty''': low

=== 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. ''This is a high-priority topic.''

'''Requirements''':
*Familiarity with C/C++
*Strong familiarity with networking applications and implications

'''Difficulty''': medium

==Additional Project Ideas ==

While code cleanup and refactoring projects are our top-priority, other projects will certainly be considered if the idea is well thought-out and the student is passionate about the idea. Continuing a previously successful GSoC project is also something very highly desired (even if it does entail new code).

=== BZWorkBench world editor enhancement ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Ability to read through other people's code
*Basic GUI, interaction, and usability design
*Acceptance testing

'''Difficulty''': high

=== Global authentication daemon ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with LDAP
*Familiarity with client/server networking applications

'''Difficulty''': medium

=== Enhanced server listing ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*GUI, usability, and interaction design
*Acceptance testing

'''Difficulty''': low

=== BZRobots ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

BZFlag now has a programmable game client that can be used to implement artificially intelligent (AI) computer players. More work is needeed, though, to clean up the code and deliver bzrobots as a new easy-to-use feature to users. More work is needed. BZRobots conforms to the Robocode API with a few minor (yet necessary) deviations, yet there are a few protocol actions that still need to be implemented. There is also lots of code quality and refactoring issues that need to be addressed. Presently, the code is a copy of the entire client code with user input removed so when a change or bug fix happens to the client, it has to also be manually changed in the bzrobots copy of the code. The code needs to be refactored into common logic shared by both game clients.

See [[BZRobots]] for more information on the current status as well as src/bzrobots in a source checkout.

'''Requirements''':
*Familiarity with C/C++
*Ability to read through an existing code base and refactor appropriately

'''Difficulty''': low

=== 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 "[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)]".

'''Requirements''':
*Strong familiarity with C/C++
*Strong familiarity with networking applications

'''Difficulty''': high

=== Two-player tanks ===
This always gets some folks excited, but you will have to have already done a lot of research and make a good proposal before this idea will be considered. That said, the topic of having two-player tanks where only one player drives and the other player only shoots has come up many times over the years. BZFlag doesn't allow turret control specifically as a game design feature. An initial two-player tank arrangement would probably not deviate from that requirement initially. Lots of testing, interaction, and feedback are required for this feature to make it to release given how much it potentially would affect gameplay.

'''Requirements''':
*Familiarity with C/C++
*Strong ability to read through existing code
*Acceptance testing

'''Difficulty''': high
(the implementation itself is not hard at all, the acceptance testing will be)

=== 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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with SDL

'''Difficulty''': low

=== Cross-server communications system ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with networking applications
*Acceptance testing

'''Difficulty''': low

===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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with GUI, interaction, and usability design
*Acceptance testing

'''Difficulty''': low

=== Integrated BZFS web interface (aka BZ's WebAdmin plugin) ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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. There was a previous GSoC project that worked on a server-side plugin that provides this feature, but it needs a lot more work both on the interface and in the logic. Be sure to discuss this with the developers before suggesting it.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with GUI, interaction, and usability design
*Acceptance testing

'''Difficulty''': low

= Mentors =

BZFlag operates with a ''group mentoring'' approach meaning that students may (and should) call upon any developer within the community if they have questions. The mentors for 2009 are:

* Sean Morrison (brlcad/learner)
* Daniel Remenak (DTRemenak/Erroneous)
* Jeffrey Myers (JeffM/JeffM2501)
* Julio Jiménez Borreguero (Manu/jujibo)
* Scott Wichser (Blast/Blast007)
* David Wollner (JB diGriz)
* Joe VanOverberghe (Donny_Baker)
* James Lawrence (spldart)

[[Category: Development]]

Google Summer of Code: 2009

2009-03-16T16:42:38Z

Learner: /* Lots o' Bug fixing */ emphasize

The 2009 Google Summer of Code was announced in February, 2009. BZFlag will again be applying as a mentoring organization. Given our enormously successful participation in the program in 2007 and 2008, we're very excited to be participating again and we're very happy to see the applications that were submitted. BZFlag will be accepting student project proposals from March 23 until April 3. Hints and tips on [[Google_Summer_of_Code|getting started, preparing a submission, and the application process]] were available.

= Promotion Flyers =

We're now soliciting designs for our 2009 GSoC promotional flyer. If you are interested in providing a design, please contact us!

= 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.

==High-Priority Project Ideas==

This year our focus is on quality. We need to stabilize our codebase and prepare for a major release. That being the case, a '''*very*''' strong preference will be given to cleanup and refactoring projects over ''new code'' projects. Please keep that in mind when preparing your application and do contact the developers if there are any questions.

=== 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.

'''Difficulty''': variable

=== Lots o' Bug fixing ===
'''''It is often very complicated, difficult, and sometimes not very glamorous but this is our top-priority for 2009.'''''

Basically, this project idea is right up in line with helping new developers become familiarized with the BZFlag code and to help us improve our code quality for an upcoming major release. Propose fixing bugs. You can propose fixing a lot of them or just a few, but you should be detailed and methodical in your approach. Refactoring work related to fixing a bug is great. A progressive/agile/iterative approach to identifying which bugs you intend to look into and fix would also be fantastic.

There is an extensive list of bugs that need to be addressed at https://sourceforge.net/tracker2/?group_id=3248&atid=103248 and http://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag/BUGS at your disposal.

'''Requirements''':
*Familiarity with C/C++
*Good problem solving and diagnostic skills
*(optional) Proficient with a debugger (you will be by the end)

'''Difficulty''': variable

=== 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.

'''Requirements''':
*Strong familiarity with C/C++
*Basic familiarity with client/server networking applications

'''Difficulty''': medium

=== 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 [[DevelopmentGoals#libGame|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.

'''Requirements''':
*Familiarity with C/C++

'''Difficulty''': low

=== Modularization of OpenGL logic===
BZFlag's graphics code is (unfortunately) spread throughout the codebase with OpenGL calls being made in thousands of places. The goal of this project would be to encapsulate *all* of the OpenGL calls into one place as a first step towards encapsulating all of the graphics code so that we can adopt a 3D rendering engine. This project should not be to integrate with an engine, though, as there's too much that needs to happen beforehand. Step one is getting all of the graphics code contained.

'''Requirements''':
*Familiarity with C/C++
*Basic familiarity with OpenGL

'''Difficulty''': low

=== 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.

'''Requirements''':
*Familiarity with C/C++
*Strong familiarity with networking applications and implications

'''Difficulty''': medium

==Additional Project Ideas ==

While code cleanup and refactoring projects are our top-priority, other projects will certainly be considered if the idea is well thought-out and the student is passionate about the idea. Continuing a previously successful GSoC project is also something very highly desired (even if it does entail new code).

=== BZWorkBench world editor enhancement ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Ability to read through other people's code
*Basic GUI, interaction, and usability design
*Acceptance testing

'''Difficulty''': high

=== Global authentication daemon ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with LDAP
*Familiarity with client/server networking applications

'''Difficulty''': medium

=== Enhanced server listing ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*GUI, usability, and interaction design
*Acceptance testing

'''Difficulty''': low

=== BZRobots ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

BZFlag now has a programmable game client that can be used to implement artificially intelligent (AI) computer players. More work is needeed, though, to clean up the code and deliver bzrobots as a new easy-to-use feature to users. More work is needed. BZRobots conforms to the Robocode API with a few minor (yet necessary) deviations, yet there are a few protocol actions that still need to be implemented. There is also lots of code quality and refactoring issues that need to be addressed. Presently, the code is a copy of the entire client code with user input removed so when a change or bug fix happens to the client, it has to also be manually changed in the bzrobots copy of the code. The code needs to be refactored into common logic shared by both game clients.

See [[BZRobots]] for more information on the current status as well as src/bzrobots in a source checkout.

'''Requirements''':
*Familiarity with C/C++
*Ability to read through an existing code base and refactor appropriately

'''Difficulty''': low

=== 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 "[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)]".

'''Requirements''':
*Strong familiarity with C/C++
*Strong familiarity with networking applications

'''Difficulty''': high

=== Two-player tanks ===
This always gets some folks excited, but you will have to have already done a lot of research and make a good proposal before this idea will be considered. That said, the topic of having two-player tanks where only one player drives and the other player only shoots has come up many times over the years. BZFlag doesn't allow turret control specifically as a game design feature. An initial two-player tank arrangement would probably not deviate from that requirement initially. Lots of testing, interaction, and feedback are required for this feature to make it to release given how much it potentially would affect gameplay.

'''Requirements''':
*Familiarity with C/C++
*Strong ability to read through existing code
*Acceptance testing

'''Difficulty''': high
(the implementation itself is not hard at all, the acceptance testing will be)

=== 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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with SDL

'''Difficulty''': low

=== Cross-server communications system ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with networking applications
*Acceptance testing

'''Difficulty''': low

===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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with GUI, interaction, and usability design
*Acceptance testing

'''Difficulty''': low

=== Integrated BZFS web interface (aka BZ's WebAdmin plugin) ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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. There was a previous GSoC project that worked on a server-side plugin that provides this feature, but it needs a lot more work both on the interface and in the logic. Be sure to discuss this with the developers before suggesting it.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with GUI, interaction, and usability design
*Acceptance testing

'''Difficulty''': low

= Mentors =

BZFlag operates with a ''group mentoring'' approach meaning that students may (and should) call upon any developer within the community if they have questions. The mentors for 2009 are:

* Sean Morrison (brlcad/learner)
* Daniel Remenak (DTRemenak/Erroneous)
* Jeffrey Myers (JeffM/JeffM2501)
* Julio Jiménez Borreguero (Manu/jujibo)
* Scott Wichser (Blast/Blast007)
* David Wollner (JB diGriz)
* Joe VanOverberghe (Donny_Baker)
* James Lawrence (spldart)

[[Category: Development]]

Google Summer of Code: 2009

2009-03-16T16:41:35Z

Learner: webadmin

The 2009 Google Summer of Code was announced in February, 2009. BZFlag will again be applying as a mentoring organization. Given our enormously successful participation in the program in 2007 and 2008, we're very excited to be participating again and we're very happy to see the applications that were submitted. BZFlag will be accepting student project proposals from March 23 until April 3. Hints and tips on [[Google_Summer_of_Code|getting started, preparing a submission, and the application process]] were available.

= Promotion Flyers =

We're now soliciting designs for our 2009 GSoC promotional flyer. If you are interested in providing a design, please contact us!

= 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.

==High-Priority Project Ideas==

This year our focus is on quality. We need to stabilize our codebase and prepare for a major release. That being the case, a '''*very*''' strong preference will be given to cleanup and refactoring projects over ''new code'' projects. Please keep that in mind when preparing your application and do contact the developers if there are any questions.

=== 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.

'''Difficulty''': variable

=== Lots o' Bug fixing ===
Basically, this project idea is right up in line with helping new developers become familiarized with the BZFlag code and to help us improve our code quality for an upcoming major release. Propose fixing bugs. You can propose fixing a lot of them or just a few, but you should be detailed and methodical in your approach. Refactoring work related to fixing a bug is great. A progressive/agile/iterative approach to identifying which bugs you intend to look into and fix would also be fantastic.

It is often very complicated, difficult, and sometimes not very glamorous but this is our top-priority for 2009.

There is an extensive list of bugs that need to be addressed at https://sourceforge.net/tracker2/?group_id=3248&atid=103248 and http://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag/BUGS at your disposal.

'''Requirements''':
*Familiarity with C/C++
*Good problem solving and diagnostic skills
*(optional) Proficient with a debugger (you will be by the end)

'''Difficulty''': variable

=== 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.

'''Requirements''':
*Strong familiarity with C/C++
*Basic familiarity with client/server networking applications

'''Difficulty''': medium

=== 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 [[DevelopmentGoals#libGame|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.

'''Requirements''':
*Familiarity with C/C++

'''Difficulty''': low

=== Modularization of OpenGL logic===
BZFlag's graphics code is (unfortunately) spread throughout the codebase with OpenGL calls being made in thousands of places. The goal of this project would be to encapsulate *all* of the OpenGL calls into one place as a first step towards encapsulating all of the graphics code so that we can adopt a 3D rendering engine. This project should not be to integrate with an engine, though, as there's too much that needs to happen beforehand. Step one is getting all of the graphics code contained.

'''Requirements''':
*Familiarity with C/C++
*Basic familiarity with OpenGL

'''Difficulty''': low

=== 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.

'''Requirements''':
*Familiarity with C/C++
*Strong familiarity with networking applications and implications

'''Difficulty''': medium

==Additional Project Ideas ==

While code cleanup and refactoring projects are our top-priority, other projects will certainly be considered if the idea is well thought-out and the student is passionate about the idea. Continuing a previously successful GSoC project is also something very highly desired (even if it does entail new code).

=== BZWorkBench world editor enhancement ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Ability to read through other people's code
*Basic GUI, interaction, and usability design
*Acceptance testing

'''Difficulty''': high

=== Global authentication daemon ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with LDAP
*Familiarity with client/server networking applications

'''Difficulty''': medium

=== Enhanced server listing ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*GUI, usability, and interaction design
*Acceptance testing

'''Difficulty''': low

=== BZRobots ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

BZFlag now has a programmable game client that can be used to implement artificially intelligent (AI) computer players. More work is needeed, though, to clean up the code and deliver bzrobots as a new easy-to-use feature to users. More work is needed. BZRobots conforms to the Robocode API with a few minor (yet necessary) deviations, yet there are a few protocol actions that still need to be implemented. There is also lots of code quality and refactoring issues that need to be addressed. Presently, the code is a copy of the entire client code with user input removed so when a change or bug fix happens to the client, it has to also be manually changed in the bzrobots copy of the code. The code needs to be refactored into common logic shared by both game clients.

See [[BZRobots]] for more information on the current status as well as src/bzrobots in a source checkout.

'''Requirements''':
*Familiarity with C/C++
*Ability to read through an existing code base and refactor appropriately

'''Difficulty''': low

=== 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 "[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)]".

'''Requirements''':
*Strong familiarity with C/C++
*Strong familiarity with networking applications

'''Difficulty''': high

=== Two-player tanks ===
This always gets some folks excited, but you will have to have already done a lot of research and make a good proposal before this idea will be considered. That said, the topic of having two-player tanks where only one player drives and the other player only shoots has come up many times over the years. BZFlag doesn't allow turret control specifically as a game design feature. An initial two-player tank arrangement would probably not deviate from that requirement initially. Lots of testing, interaction, and feedback are required for this feature to make it to release given how much it potentially would affect gameplay.

'''Requirements''':
*Familiarity with C/C++
*Strong ability to read through existing code
*Acceptance testing

'''Difficulty''': high
(the implementation itself is not hard at all, the acceptance testing will be)

=== 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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with SDL

'''Difficulty''': low

=== Cross-server communications system ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with networking applications
*Acceptance testing

'''Difficulty''': low

===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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with GUI, interaction, and usability design
*Acceptance testing

'''Difficulty''': low

=== Integrated BZFS web interface (aka BZ's WebAdmin plugin) ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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. There was a previous GSoC project that worked on a server-side plugin that provides this feature, but it needs a lot more work both on the interface and in the logic. Be sure to discuss this with the developers before suggesting it.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with GUI, interaction, and usability design
*Acceptance testing

'''Difficulty''': low

= Mentors =

BZFlag operates with a ''group mentoring'' approach meaning that students may (and should) call upon any developer within the community if they have questions. The mentors for 2009 are:

* Sean Morrison (brlcad/learner)
* Daniel Remenak (DTRemenak/Erroneous)
* Jeffrey Myers (JeffM/JeffM2501)
* Julio Jiménez Borreguero (Manu/jujibo)
* Scott Wichser (Blast/Blast007)
* David Wollner (JB diGriz)
* Joe VanOverberghe (Donny_Baker)
* James Lawrence (spldart)

[[Category: Development]]

Google Summer of Code: 2009

2009-03-16T16:38:06Z

Learner: add profile management back and slew of acceptance testing

The 2009 Google Summer of Code was announced in February, 2009. BZFlag will again be applying as a mentoring organization. Given our enormously successful participation in the program in 2007 and 2008, we're very excited to be participating again and we're very happy to see the applications that were submitted. BZFlag will be accepting student project proposals from March 23 until April 3. Hints and tips on [[Google_Summer_of_Code|getting started, preparing a submission, and the application process]] were available.

= Promotion Flyers =

We're now soliciting designs for our 2009 GSoC promotional flyer. If you are interested in providing a design, please contact us!

= 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.

==High-Priority Project Ideas==

This year our focus is on quality. We need to stabilize our codebase and prepare for a major release. That being the case, a '''*very*''' strong preference will be given to cleanup and refactoring projects over ''new code'' projects. Please keep that in mind when preparing your application and do contact the developers if there are any questions.

=== 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.

'''Difficulty''': variable

=== Lots o' Bug fixing ===
Basically, this project idea is right up in line with helping new developers become familiarized with the BZFlag code and to help us improve our code quality for an upcoming major release. Propose fixing bugs. You can propose fixing a lot of them or just a few, but you should be detailed and methodical in your approach. Refactoring work related to fixing a bug is great. A progressive/agile/iterative approach to identifying which bugs you intend to look into and fix would also be fantastic.

It is often very complicated, difficult, and sometimes not very glamorous but this is our top-priority for 2009.

There is an extensive list of bugs that need to be addressed at https://sourceforge.net/tracker2/?group_id=3248&atid=103248 and http://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag/BUGS at your disposal.

'''Requirements''':
*Familiarity with C/C++
*Good problem solving and diagnostic skills
*(optional) Proficient with a debugger (you will be by the end)

'''Difficulty''': variable

=== 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.

'''Requirements''':
*Strong familiarity with C/C++
*Basic familiarity with client/server networking applications

'''Difficulty''': medium

=== 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 [[DevelopmentGoals#libGame|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.

'''Requirements''':
*Familiarity with C/C++

'''Difficulty''': low

=== Modularization of OpenGL logic===
BZFlag's graphics code is (unfortunately) spread throughout the codebase with OpenGL calls being made in thousands of places. The goal of this project would be to encapsulate *all* of the OpenGL calls into one place as a first step towards encapsulating all of the graphics code so that we can adopt a 3D rendering engine. This project should not be to integrate with an engine, though, as there's too much that needs to happen beforehand. Step one is getting all of the graphics code contained.

'''Requirements''':
*Familiarity with C/C++
*Basic familiarity with OpenGL

'''Difficulty''': low

=== 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.

'''Requirements''':
*Familiarity with C/C++
*Strong familiarity with networking applications and implications

'''Difficulty''': medium

==Additional Project Ideas ==

While code cleanup and refactoring projects are our top-priority, other projects will certainly be considered if the idea is well thought-out and the student is passionate about the idea. Continuing a previously successful GSoC project is also something very highly desired (even if it does entail new code).

=== BZWorkBench world editor enhancement ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Ability to read through other people's code
*Basic GUI, interaction, and usability design
*Acceptance testing

'''Difficulty''': high

=== Global authentication daemon ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with LDAP
*Familiarity with client/server networking applications

'''Difficulty''': medium

=== Enhanced server listing ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*GUI, usability, and interaction design
*Acceptance testing

'''Difficulty''': low

=== BZRobots ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

BZFlag now has a programmable game client that can be used to implement artificially intelligent (AI) computer players. More work is needeed, though, to clean up the code and deliver bzrobots as a new easy-to-use feature to users. More work is needed. BZRobots conforms to the Robocode API with a few minor (yet necessary) deviations, yet there are a few protocol actions that still need to be implemented. There is also lots of code quality and refactoring issues that need to be addressed. Presently, the code is a copy of the entire client code with user input removed so when a change or bug fix happens to the client, it has to also be manually changed in the bzrobots copy of the code. The code needs to be refactored into common logic shared by both game clients.

See [[BZRobots]] for more information on the current status as well as src/bzrobots in a source checkout.

'''Requirements''':
*Familiarity with C/C++
*Ability to read through an existing code base and refactor appropriately

'''Difficulty''': low

=== 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 "[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)]".

'''Requirements''':
*Strong familiarity with C/C++
*Strong familiarity with networking applications

'''Difficulty''': high

=== Two-player tanks ===
This always gets some folks excited, but you will have to have already done a lot of research and make a good proposal before this idea will be considered. That said, the topic of having two-player tanks where only one player drives and the other player only shoots has come up many times over the years. BZFlag doesn't allow turret control specifically as a game design feature. An initial two-player tank arrangement would probably not deviate from that requirement initially. Lots of testing, interaction, and feedback are required for this feature to make it to release given how much it potentially would affect gameplay.

'''Requirements''':
*Familiarity with C/C++
*Strong ability to read through existing code
*Acceptance testing

'''Difficulty''': high
(the implementation itself is not hard at all, the acceptance testing will be)

=== 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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with SDL

'''Difficulty''': low

=== Cross-server communications system ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with networking applications
*Acceptance testing

'''Difficulty''': low

===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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with GUI, interaction, and usability design
*Acceptance testing

'''Difficulty''': low

= Mentors =

BZFlag operates with a ''group mentoring'' approach meaning that students may (and should) call upon any developer within the community if they have questions. The mentors for 2009 are:

* Sean Morrison (brlcad/learner)
* Daniel Remenak (DTRemenak/Erroneous)
* Jeffrey Myers (JeffM/JeffM2501)
* Julio Jiménez Borreguero (Manu/jujibo)
* Scott Wichser (Blast/Blast007)
* David Wollner (JB diGriz)
* Joe VanOverberghe (Donny_Baker)
* James Lawrence (spldart)

[[Category: Development]]

Google Summer of Code: 2009

2009-03-16T16:35:29Z

Learner: cross-server communications

The 2009 Google Summer of Code was announced in February, 2009. BZFlag will again be applying as a mentoring organization. Given our enormously successful participation in the program in 2007 and 2008, we're very excited to be participating again and we're very happy to see the applications that were submitted. BZFlag will be accepting student project proposals from March 23 until April 3. Hints and tips on [[Google_Summer_of_Code|getting started, preparing a submission, and the application process]] were available.

= Promotion Flyers =

We're now soliciting designs for our 2009 GSoC promotional flyer. If you are interested in providing a design, please contact us!

= 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.

==High-Priority Project Ideas==

This year our focus is on quality. We need to stabilize our codebase and prepare for a major release. That being the case, a '''*very*''' strong preference will be given to cleanup and refactoring projects over ''new code'' projects. Please keep that in mind when preparing your application and do contact the developers if there are any questions.

=== 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.

'''Difficulty''': variable

=== Lots o' Bug fixing ===
Basically, this project idea is right up in line with helping new developers become familiarized with the BZFlag code and to help us improve our code quality for an upcoming major release. Propose fixing bugs. You can propose fixing a lot of them or just a few, but you should be detailed and methodical in your approach. Refactoring work related to fixing a bug is great. A progressive/agile/iterative approach to identifying which bugs you intend to look into and fix would also be fantastic.

It is often very complicated, difficult, and sometimes not very glamorous but this is our top-priority for 2009.

There is an extensive list of bugs that need to be addressed at https://sourceforge.net/tracker2/?group_id=3248&atid=103248 and http://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag/BUGS at your disposal.

'''Requirements''':
*Familiarity with C/C++
*Good problem solving and diagnostic skills
*(optional) Proficient with a debugger (you will be by the end)

'''Difficulty''': variable

=== 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.

'''Requirements''':
*Strong familiarity with C/C++
*Basic familiarity with client/server networking applications

'''Difficulty''': medium

=== 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 [[DevelopmentGoals#libGame|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.

'''Requirements''':
*Familiarity with C/C++

'''Difficulty''': low

=== Modularization of OpenGL logic===
BZFlag's graphics code is (unfortunately) spread throughout the codebase with OpenGL calls being made in thousands of places. The goal of this project would be to encapsulate *all* of the OpenGL calls into one place as a first step towards encapsulating all of the graphics code so that we can adopt a 3D rendering engine. This project should not be to integrate with an engine, though, as there's too much that needs to happen beforehand. Step one is getting all of the graphics code contained.

'''Requirements''':
*Familiarity with C/C++
*Basic familiarity with OpenGL

'''Difficulty''': low

=== 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.

'''Requirements''':
*Familiarity with C/C++
*Strong familiarity with networking applications and implications

'''Difficulty''': medium

==Additional Project Ideas ==

While code cleanup and refactoring projects are our top-priority, other projects will certainly be considered if the idea is well thought-out and the student is passionate about the idea. Continuing a previously successful GSoC project is also something very highly desired (even if it does entail new code).

=== BZWorkBench world editor enhancement ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Ability to read through other people's code
*Basic GUI and usability design

'''Difficulty''': high

=== Global authentication daemon ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with LDAP
*Familiarity with client/server networking applications

'''Difficulty''': medium

=== Enhanced server listing ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*GUI, usability, and interaction design

'''Difficulty''': low

=== BZRobots ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

BZFlag now has a programmable game client that can be used to implement artificially intelligent (AI) computer players. More work is needeed, though, to clean up the code and deliver bzrobots as a new easy-to-use feature to users. More work is needed. BZRobots conforms to the Robocode API with a few minor (yet necessary) deviations, yet there are a few protocol actions that still need to be implemented. There is also lots of code quality and refactoring issues that need to be addressed. Presently, the code is a copy of the entire client code with user input removed so when a change or bug fix happens to the client, it has to also be manually changed in the bzrobots copy of the code. The code needs to be refactored into common logic shared by both game clients.

See [[BZRobots]] for more information on the current status as well as src/bzrobots in a source checkout.

'''Requirements''':
*Familiarity with C/C++
*Ability to read through an existing code base and refactor appropriately

'''Difficulty''': low

=== 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 "[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)]".

'''Requirements''':
*Strong familiarity with C/C++
*Strong familiarity with networking applications

'''Difficulty''': high

=== Two-player tanks ===
This always gets some folks excited, but you will have to have already done a lot of research and make a good proposal before this idea will be considered. That said, the topic of having two-player tanks where only one player drives and the other player only shoots has come up many times over the years. BZFlag doesn't allow turret control specifically as a game design feature. An initial two-player tank arrangement would probably not deviate from that requirement initially. Lots of testing, interaction, and feedback are required for this feature to make it to release given how much it potentially would affect gameplay.

'''Requirements''':
*Familiarity with C/C++
*Strong ability to read through existing code

'''Difficulty''': high
(the implementation itself is not hard at all, the acceptance testing will be)

=== 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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with SDL

'''Difficulty''': low

=== Cross-server communications system ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with networking applications

'''Difficulty''': low

= Mentors =

BZFlag operates with a ''group mentoring'' approach meaning that students may (and should) call upon any developer within the community if they have questions. The mentors for 2009 are:

* Sean Morrison (brlcad/learner)
* Daniel Remenak (DTRemenak/Erroneous)
* Jeffrey Myers (JeffM/JeffM2501)
* Julio Jiménez Borreguero (Manu/jujibo)
* Scott Wichser (Blast/Blast007)
* David Wollner (JB diGriz)
* Joe VanOverberghe (Donny_Baker)
* James Lawrence (spldart)

[[Category: Development]]

Google Summer of Code: 2009

2009-03-16T16:33:20Z

Learner: multiple display support

The 2009 Google Summer of Code was announced in February, 2009. BZFlag will again be applying as a mentoring organization. Given our enormously successful participation in the program in 2007 and 2008, we're very excited to be participating again and we're very happy to see the applications that were submitted. BZFlag will be accepting student project proposals from March 23 until April 3. Hints and tips on [[Google_Summer_of_Code|getting started, preparing a submission, and the application process]] were available.

= Promotion Flyers =

We're now soliciting designs for our 2009 GSoC promotional flyer. If you are interested in providing a design, please contact us!

= 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.

==High-Priority Project Ideas==

This year our focus is on quality. We need to stabilize our codebase and prepare for a major release. That being the case, a '''*very*''' strong preference will be given to cleanup and refactoring projects over ''new code'' projects. Please keep that in mind when preparing your application and do contact the developers if there are any questions.

=== 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.

'''Difficulty''': variable

=== Lots o' Bug fixing ===
Basically, this project idea is right up in line with helping new developers become familiarized with the BZFlag code and to help us improve our code quality for an upcoming major release. Propose fixing bugs. You can propose fixing a lot of them or just a few, but you should be detailed and methodical in your approach. Refactoring work related to fixing a bug is great. A progressive/agile/iterative approach to identifying which bugs you intend to look into and fix would also be fantastic.

It is often very complicated, difficult, and sometimes not very glamorous but this is our top-priority for 2009.

There is an extensive list of bugs that need to be addressed at https://sourceforge.net/tracker2/?group_id=3248&atid=103248 and http://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag/BUGS at your disposal.

'''Requirements''':
*Familiarity with C/C++
*Good problem solving and diagnostic skills
*(optional) Proficient with a debugger (you will be by the end)

'''Difficulty''': variable

=== 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.

'''Requirements''':
*Strong familiarity with C/C++
*Basic familiarity with client/server networking applications

'''Difficulty''': medium

=== 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 [[DevelopmentGoals#libGame|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.

'''Requirements''':
*Familiarity with C/C++

'''Difficulty''': low

=== Modularization of OpenGL logic===
BZFlag's graphics code is (unfortunately) spread throughout the codebase with OpenGL calls being made in thousands of places. The goal of this project would be to encapsulate *all* of the OpenGL calls into one place as a first step towards encapsulating all of the graphics code so that we can adopt a 3D rendering engine. This project should not be to integrate with an engine, though, as there's too much that needs to happen beforehand. Step one is getting all of the graphics code contained.

'''Requirements''':
*Familiarity with C/C++
*Basic familiarity with OpenGL

'''Difficulty''': low

=== 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.

'''Requirements''':
*Familiarity with C/C++
*Strong familiarity with networking applications and implications

'''Difficulty''': medium

==Additional Project Ideas ==

While code cleanup and refactoring projects are our top-priority, other projects will certainly be considered if the idea is well thought-out and the student is passionate about the idea. Continuing a previously successful GSoC project is also something very highly desired (even if it does entail new code).

=== BZWorkBench world editor enhancement ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Ability to read through other people's code
*Basic GUI and usability design

'''Difficulty''': high

=== Global authentication daemon ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with LDAP
*Familiarity with client/server networking applications

'''Difficulty''': medium

=== Enhanced server listing ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*GUI, usability, and interaction design

'''Difficulty''': low

=== BZRobots ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

BZFlag now has a programmable game client that can be used to implement artificially intelligent (AI) computer players. More work is needeed, though, to clean up the code and deliver bzrobots as a new easy-to-use feature to users. More work is needed. BZRobots conforms to the Robocode API with a few minor (yet necessary) deviations, yet there are a few protocol actions that still need to be implemented. There is also lots of code quality and refactoring issues that need to be addressed. Presently, the code is a copy of the entire client code with user input removed so when a change or bug fix happens to the client, it has to also be manually changed in the bzrobots copy of the code. The code needs to be refactored into common logic shared by both game clients.

See [[BZRobots]] for more information on the current status as well as src/bzrobots in a source checkout.

'''Requirements''':
*Familiarity with C/C++
*Ability to read through an existing code base and refactor appropriately

'''Difficulty''': low

=== 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 "[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)]".

'''Requirements''':
*Strong familiarity with C/C++
*Strong familiarity with networking applications

'''Difficulty''': high

=== Two-player tanks ===
This always gets some folks excited, but you will have to have already done a lot of research and make a good proposal before this idea will be considered. That said, the topic of having two-player tanks where only one player drives and the other player only shoots has come up many times over the years. BZFlag doesn't allow turret control specifically as a game design feature. An initial two-player tank arrangement would probably not deviate from that requirement initially. Lots of testing, interaction, and feedback are required for this feature to make it to release given how much it potentially would affect gameplay.

'''Requirements''':
*Familiarity with C/C++
*Strong ability to read through existing code

'''Difficulty''': high
(the implementation itself is not hard at all, the acceptance testing will be)

=== 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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with SDL

'''Difficulty''': low

= Mentors =

BZFlag operates with a ''group mentoring'' approach meaning that students may (and should) call upon any developer within the community if they have questions. The mentors for 2009 are:

* Sean Morrison (brlcad/learner)
* Daniel Remenak (DTRemenak/Erroneous)
* Jeffrey Myers (JeffM/JeffM2501)
* Julio Jiménez Borreguero (Manu/jujibo)
* Scott Wichser (Blast/Blast007)
* David Wollner (JB diGriz)
* Joe VanOverberghe (Donny_Baker)
* James Lawrence (spldart)

[[Category: Development]]

Google Summer of Code: 2009

2009-03-16T16:29:59Z

Learner: the venerable two-tank idea returns

The 2009 Google Summer of Code was announced in February, 2009. BZFlag will again be applying as a mentoring organization. Given our enormously successful participation in the program in 2007 and 2008, we're very excited to be participating again and we're very happy to see the applications that were submitted. BZFlag will be accepting student project proposals from March 23 until April 3. Hints and tips on [[Google_Summer_of_Code|getting started, preparing a submission, and the application process]] were available.

= Promotion Flyers =

We're now soliciting designs for our 2009 GSoC promotional flyer. If you are interested in providing a design, please contact us!

= 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.

==High-Priority Project Ideas==

This year our focus is on quality. We need to stabilize our codebase and prepare for a major release. That being the case, a '''*very*''' strong preference will be given to cleanup and refactoring projects over ''new code'' projects. Please keep that in mind when preparing your application and do contact the developers if there are any questions.

=== 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.

'''Difficulty''': variable

=== Lots o' Bug fixing ===
Basically, this project idea is right up in line with helping new developers become familiarized with the BZFlag code and to help us improve our code quality for an upcoming major release. Propose fixing bugs. You can propose fixing a lot of them or just a few, but you should be detailed and methodical in your approach. Refactoring work related to fixing a bug is great. A progressive/agile/iterative approach to identifying which bugs you intend to look into and fix would also be fantastic.

It is often very complicated, difficult, and sometimes not very glamorous but this is our top-priority for 2009.

There is an extensive list of bugs that need to be addressed at https://sourceforge.net/tracker2/?group_id=3248&atid=103248 and http://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag/BUGS at your disposal.

'''Requirements''':
*Familiarity with C/C++
*Good problem solving and diagnostic skills
*(optional) Proficient with a debugger (you will be by the end)

'''Difficulty''': variable

=== 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.

'''Requirements''':
*Strong familiarity with C/C++
*Basic familiarity with client/server networking applications

'''Difficulty''': medium

=== 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 [[DevelopmentGoals#libGame|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.

'''Requirements''':
*Familiarity with C/C++

'''Difficulty''': low

=== Modularization of OpenGL logic===
BZFlag's graphics code is (unfortunately) spread throughout the codebase with OpenGL calls being made in thousands of places. The goal of this project would be to encapsulate *all* of the OpenGL calls into one place as a first step towards encapsulating all of the graphics code so that we can adopt a 3D rendering engine. This project should not be to integrate with an engine, though, as there's too much that needs to happen beforehand. Step one is getting all of the graphics code contained.

'''Requirements''':
*Familiarity with C/C++
*Basic familiarity with OpenGL

'''Difficulty''': low

=== 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.

'''Requirements''':
*Familiarity with C/C++
*Strong familiarity with networking applications and implications

'''Difficulty''': medium

==Additional Project Ideas ==

While code cleanup and refactoring projects are our top-priority, other projects will certainly be considered if the idea is well thought-out and the student is passionate about the idea. Continuing a previously successful GSoC project is also something very highly desired (even if it does entail new code).

=== BZWorkBench world editor enhancement ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Ability to read through other people's code
*Basic GUI and usability design

'''Difficulty''': high

=== Global authentication daemon ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with LDAP
*Familiarity with client/server networking applications

'''Difficulty''': medium

=== Enhanced server listing ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*GUI, usability, and interaction design

'''Difficulty''': low

=== BZRobots ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

BZFlag now has a programmable game client that can be used to implement artificially intelligent (AI) computer players. More work is needeed, though, to clean up the code and deliver bzrobots as a new easy-to-use feature to users. More work is needed. BZRobots conforms to the Robocode API with a few minor (yet necessary) deviations, yet there are a few protocol actions that still need to be implemented. There is also lots of code quality and refactoring issues that need to be addressed. Presently, the code is a copy of the entire client code with user input removed so when a change or bug fix happens to the client, it has to also be manually changed in the bzrobots copy of the code. The code needs to be refactored into common logic shared by both game clients.

See [[BZRobots]] for more information on the current status as well as src/bzrobots in a source checkout.

'''Requirements''':
*Familiarity with C/C++
*Ability to read through an existing code base and refactor appropriately

'''Difficulty''': low

=== 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 "[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)]".

'''Requirements''':
*Strong familiarity with C/C++
*Strong familiarity with networking applications

'''Difficulty''': high

=== Two-player tanks ===
This always gets some folks excited, but you will have to have already done a lot of research and make a good proposal before this idea will be considered. That said, the topic of having two-player tanks where only one player drives and the other player only shoots has come up many times over the years. BZFlag doesn't allow turret control specifically as a game design feature. An initial two-player tank arrangement would probably not deviate from that requirement initially. Lots of testing, interaction, and feedback are required for this feature to make it to release given how much it potentially would affect gameplay.

'''Requirements''':
*Familiarity with C/C++
*Strong ability to read through existing code

'''Difficulty''': high
(the implementation itself is not hard at all, the acceptance testing will be)

= Mentors =

BZFlag operates with a ''group mentoring'' approach meaning that students may (and should) call upon any developer within the community if they have questions. The mentors for 2009 are:

* Sean Morrison (brlcad/learner)
* Daniel Remenak (DTRemenak/Erroneous)
* Jeffrey Myers (JeffM/JeffM2501)
* Julio Jiménez Borreguero (Manu/jujibo)
* Scott Wichser (Blast/Blast007)
* David Wollner (JB diGriz)
* Joe VanOverberghe (Donny_Baker)
* James Lawrence (spldart)

[[Category: Development]]

Google Summer of Code: 2009

2009-03-16T16:11:54Z

Learner: /* Additional Project Ideas */ bzrobots continuation

The 2009 Google Summer of Code was announced in February, 2009. BZFlag will again be applying as a mentoring organization. Given our enormously successful participation in the program in 2007 and 2008, we're very excited to be participating again and we're very happy to see the applications that were submitted. BZFlag will be accepting student project proposals from March 23 until April 3. Hints and tips on [[Google_Summer_of_Code|getting started, preparing a submission, and the application process]] were available.

= Promotion Flyers =

We're now soliciting designs for our 2009 GSoC promotional flyer. If you are interested in providing a design, please contact us!

= 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.

==High-Priority Project Ideas==

This year our focus is on quality. We need to stabilize our codebase and prepare for a major release. That being the case, a '''*very*''' strong preference will be given to cleanup and refactoring projects over ''new code'' projects. Please keep that in mind when preparing your application and do contact the developers if there are any questions.

=== 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.

'''Difficulty''': variable

=== 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.

'''Requirements''':
*Strong familiarity with C/C++
*Basic familiarity with client/server networking applications

'''Difficulty''': medium

=== 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 [[DevelopmentGoals#libGame|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.

'''Requirements''':
*Familiarity with C/C++

'''Difficulty''': low

=== Modularization of OpenGL logic===
BZFlag's graphics code is (unfortunately) spread throughout the codebase with OpenGL calls being made in thousands of places. The goal of this project would be to encapsulate *all* of the OpenGL calls into one place as a first step towards encapsulating all of the graphics code so that we can adopt a 3D rendering engine. This project should not be to integrate with an engine, though, as there's too much that needs to happen beforehand. Step one is getting all of the graphics code contained.

'''Requirements''':
*Familiarity with C/C++
*Basic familiarity with OpenGL

'''Difficulty''': low

=== 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.

'''Requirements''':
*Familiarity with C/C++
*Strong familiarity with networking applications and implications

'''Difficulty''': medium

=== Lots o' Bug hunting ===
Basically, this project idea is right up in line with helping new developers become familiarized with the BZFlag code and to help us improve our code quality for an upcoming major release. Propose fixing bugs. You can propose fixing a lot of them or just a few, but you should be detailed and methodical in your approach. Refactoring to fix a bug is fantastic. A progressive/agile/iterative approach to identifying which bugs you intend to look into and fix would also be great.

There is an extensive list of bugs that need to be addressed at https://sourceforge.net/tracker2/?group_id=3248&atid=103248 and http://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag/BUGS at your disposal.

'''Requirements''':
*Familiarity with C/C++
*Good problem solving and diagnostic skills
*(optional) Proficient with a debugger (you will be by the end)

'''Difficulty''': variable

==Additional Project Ideas ==

While code cleanup and refactoring projects are our top-priority, other projects will certainly be considered if the idea is well thought-out and the student is passionate about the idea. Continuing a previously successful GSoC project is also something very highly desired (even if it does entail new code).

=== BZWorkBench world editor enhancement ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Ability to read through other people's code
*Basic GUI and usability design

'''Difficulty''': high

=== Global authentication daemon ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with LDAP
*Familiarity with client/server networking applications

'''Difficulty''': medium

=== Enhanced server listing ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*GUI, usability, and interaction design

'''Difficulty''': low

=== BZRobots ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

BZFlag now has a programmable game client that can be used to implement artificially intelligent (AI) computer players. More work is needeed, though, to clean up the code and deliver bzrobots as a new easy-to-use feature to users. More work is needed. BZRobots conforms to the Robocode API with a few minor (yet necessary) deviations, yet there are a few protocol actions that still need to be implemented. There is also lots of code quality and refactoring issues that need to be addressed. Presently, the code is a copy of the entire client code with user input removed so when a change or bug fix happens to the client, it has to also be manually changed in the bzrobots copy of the code. The code needs to be refactored into common logic shared by both game clients.

See [[BZRobots]] for more information on the current status as well as src/bzrobots in a source checkout.

'''Requirements''':
*Familiarity with C/C++
*Ability to read through an existing code base and refactor appropriately

'''Difficulty''': low

=== 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 "[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)]".

'''Requirements''':
*Strong familiarity with C/C++
*Strong familiarity with networking applications

'''Difficulty''': high

= Mentors =

BZFlag operates with a ''group mentoring'' approach meaning that students may (and should) call upon any developer within the community if they have questions. The mentors for 2009 are:

* Sean Morrison (brlcad/learner)
* Daniel Remenak (DTRemenak/Erroneous)
* Jeffrey Myers (JeffM/JeffM2501)
* Julio Jiménez Borreguero (Manu/jujibo)
* Scott Wichser (Blast/Blast007)
* David Wollner (JB diGriz)
* Joe VanOverberghe (Donny_Baker)
* James Lawrence (spldart)

[[Category: Development]]

Google Summer of Code: 2009

2009-03-16T15:52:42Z

Learner: emphasize the labels

The 2009 Google Summer of Code was announced in February, 2009. BZFlag will again be applying as a mentoring organization. Given our enormously successful participation in the program in 2007 and 2008, we're very excited to be participating again and we're very happy to see the applications that were submitted. BZFlag will be accepting student project proposals from March 23 until April 3. Hints and tips on [[Google_Summer_of_Code|getting started, preparing a submission, and the application process]] were available.

= Promotion Flyers =

We're now soliciting designs for our 2009 GSoC promotional flyer. If you are interested in providing a design, please contact us!

= 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.

==High-Priority Project Ideas==

This year our focus is on quality. We need to stabilize our codebase and prepare for a major release. That being the case, a '''*very*''' strong preference will be given to cleanup and refactoring projects over ''new code'' projects. Please keep that in mind when preparing your application and do contact the developers if there are any questions.

=== 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.

'''Difficulty''': variable

=== 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.

'''Requirements''':
*Strong familiarity with C/C++
*Basic familiarity with client/server networking applications

'''Difficulty''': medium

=== 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 [[DevelopmentGoals#libGame|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.

'''Requirements''':
*Familiarity with C/C++

'''Difficulty''': low

=== Modularization of OpenGL logic===
BZFlag's graphics code is (unfortunately) spread throughout the codebase with OpenGL calls being made in thousands of places. The goal of this project would be to encapsulate *all* of the OpenGL calls into one place as a first step towards encapsulating all of the graphics code so that we can adopt a 3D rendering engine. This project should not be to integrate with an engine, though, as there's too much that needs to happen beforehand. Step one is getting all of the graphics code contained.

'''Requirements''':
*Familiarity with C/C++
*Basic familiarity with OpenGL

'''Difficulty''': low

=== 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.

'''Requirements''':
*Familiarity with C/C++
*Strong familiarity with networking applications and implications

'''Difficulty''': medium

=== Lots o' Bug hunting ===
Basically, this project idea is right up in line with helping new developers become familiarized with the BZFlag code and to help us improve our code quality for an upcoming major release. Propose fixing bugs. You can propose fixing a lot of them or just a few, but you should be detailed and methodical in your approach. Refactoring to fix a bug is fantastic. A progressive/agile/iterative approach to identifying which bugs you intend to look into and fix would also be great.

There is an extensive list of bugs that need to be addressed at https://sourceforge.net/tracker2/?group_id=3248&atid=103248 and http://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag/BUGS at your disposal.

'''Requirements''':
*Familiarity with C/C++
*Good problem solving and diagnostic skills
*(optional) Proficient with a debugger (you will be by the end)

'''Difficulty''': variable

==Additional Project Ideas ==

While code cleanup and refactoring projects are our top-priority, other projects will certainly be considered if the idea is well thought-out and the student is passionate about the idea. Continuing a previously successful GSoC project is also something very highly desired (even if it does entail new code).

=== BZWorkBench world editor enhancement ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Ability to read through other people's code
*Basic GUI and usability design

'''Difficulty''': high

=== Global authentication daemon ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*Familiarity with LDAP
*Familiarity with client/server networking applications

'''Difficulty''': medium

=== Enhanced server listing ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

'''Requirements''':
*Familiarity with C/C++
*GUI, usability, and interaction design

'''Difficulty''': low

=== 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 "[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)]".

'''Requirements''':
*Strong familiarity with C/C++
*Strong familiarity with networking applications

'''Difficulty''': high

= Mentors =

BZFlag operates with a ''group mentoring'' approach meaning that students may (and should) call upon any developer within the community if they have questions. The mentors for 2009 are:

* Sean Morrison (brlcad/learner)
* Daniel Remenak (DTRemenak/Erroneous)
* Jeffrey Myers (JeffM/JeffM2501)
* Julio Jiménez Borreguero (Manu/jujibo)
* Scott Wichser (Blast/Blast007)
* David Wollner (JB diGriz)
* Joe VanOverberghe (Donny_Baker)
* James Lawrence (spldart)

[[Category: Development]]

Google Summer of Code: 2009

2009-03-16T15:49:57Z

Learner: expand on some of the implied requirements

The 2009 Google Summer of Code was announced in February, 2009. BZFlag will again be applying as a mentoring organization. Given our enormously successful participation in the program in 2007 and 2008, we're very excited to be participating again and we're very happy to see the applications that were submitted. BZFlag will be accepting student project proposals from March 23 until April 3. Hints and tips on [[Google_Summer_of_Code|getting started, preparing a submission, and the application process]] were available.

= Promotion Flyers =

We're now soliciting designs for our 2009 GSoC promotional flyer. If you are interested in providing a design, please contact us!

= 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.

==High-Priority Project Ideas==

This year our focus is on quality. We need to stabilize our codebase and prepare for a major release. That being the case, a '''*very*''' strong preference will be given to cleanup and refactoring projects over ''new code'' projects. Please keep that in mind when preparing your application and do contact the developers if there are any questions.

=== 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.

Difficulty: variable

=== 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.

Requirements:
*Strong familiarity with C/C++
*Basic familiarity with client/server networking applications

Difficulty: medium

=== 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 [[DevelopmentGoals#libGame|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.

Requirements:
*Familiarity with C/C++

Difficulty: low

=== Modularization of OpenGL logic===
BZFlag's graphics code is (unfortunately) spread throughout the codebase with OpenGL calls being made in thousands of places. The goal of this project would be to encapsulate *all* of the OpenGL calls into one place as a first step towards encapsulating all of the graphics code so that we can adopt a 3D rendering engine. This project should not be to integrate with an engine, though, as there's too much that needs to happen beforehand. Step one is getting all of the graphics code contained.

Requirements:
*Familiarity with C/C++
*Basic familiarity with OpenGL

Difficulty: low

=== 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.

Requirements:
*Familiarity with C/C++
*Strong familiarity with networking applications and implications

Difficulty: medium

=== Lots o' Bug hunting ===
Basically, this project idea is right up in line with helping new developers become familiarized with the BZFlag code and to help us improve our code quality for an upcoming major release. Propose fixing bugs. You can propose fixing a lot of them or just a few, but you should be detailed and methodical in your approach. Refactoring to fix a bug is fantastic. A progressive/agile/iterative approach to identifying which bugs you intend to look into and fix would also be great.

There is an extensive list of bugs that need to be addressed at https://sourceforge.net/tracker2/?group_id=3248&atid=103248 and http://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag/BUGS at your disposal.

Requirements:
*Familiarity with C/C++
*Good problem solving and diagnostic skills
*(optional) Proficient with a debugger (you will be by the end)

Difficulty: variable

==Additional Project Ideas ==

While code cleanup and refactoring projects are our top-priority, other projects will certainly be considered if the idea is well thought-out and the student is passionate about the idea. Continuing a previously successful GSoC project is also something very highly desired (even if it does entail new code).

=== BZWorkBench world editor enhancement ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

Requirements:
*Familiarity with C/C++
*Ability to read through other people's code
*Basic GUI and usability design

Difficulty: high

=== Global authentication daemon ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

Requirements:
*Familiarity with C/C++
*Familiarity with LDAP
*Familiarity with client/server networking applications

Difficulty: medium

=== Enhanced server listing ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

Requirements:
*Familiarity with C/C++
*GUI, usability, and interaction design

Difficulty: low

=== 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 "[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)]".

Requirements:
*Strong familiarity with C/C++
*Strong familiarity with networking applications

Difficulty: high

= Mentors =

BZFlag operates with a ''group mentoring'' approach meaning that students may (and should) call upon any developer within the community if they have questions. The mentors for 2009 are:

* Sean Morrison (brlcad/learner)
* Daniel Remenak (DTRemenak/Erroneous)
* Jeffrey Myers (JeffM/JeffM2501)
* Julio Jiménez Borreguero (Manu/jujibo)
* Scott Wichser (Blast/Blast007)
* David Wollner (JB diGriz)
* Joe VanOverberghe (Donny_Baker)
* James Lawrence (spldart)

[[Category: Development]]

Google Summer of Code: 2009

2009-03-16T15:44:10Z

Learner: note previous projects

The 2009 Google Summer of Code was announced in February, 2009. BZFlag will again be applying as a mentoring organization. Given our enormously successful participation in the program in 2007 and 2008, we're very excited to be participating again and we're very happy to see the applications that were submitted. BZFlag will be accepting student project proposals from March 23 until April 3. Hints and tips on [[Google_Summer_of_Code|getting started, preparing a submission, and the application process]] were available.

= Promotion Flyers =

We're now soliciting designs for our 2009 GSoC promotional flyer. If you are interested in providing a design, please contact us!

= 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.

==High-Priority Project Ideas==

This year our focus is on quality. We need to stabilize our codebase and prepare for a major release. That being the case, a '''*very*''' strong preference will be given to cleanup and refactoring projects over ''new code'' projects. Please keep that in mind when preparing your application and do contact the developers if there are any questions.

=== 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.

Difficulty: variable

=== 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.

Difficulty: medium

=== 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 [[DevelopmentGoals#libGame|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.

Difficulty: low

=== Modularization of OpenGL logic===
BZFlag's graphics code is (unfortunately) spread throughout the codebase with OpenGL calls being made in thousands of places. The goal of this project would be to encapsulate *all* of the OpenGL calls into one place as a first step towards encapsulating all of the graphics code so that we can adopt a 3D rendering engine. This project should not be to integrate with an engine, though, as there's too much that needs to happen beforehand. Step one is getting all of the graphics code contained.

Difficulty: low

=== 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.

Difficulty: low

=== Lots o' Bug hunting ===
Basically, this project idea is right up in line with helping new developers become familiarized with the BZFlag code and to help us improve our code quality for an upcoming major release. Propose fixing bugs. You can propose fixing a lot of them or just a few, but you should be detailed and methodical in your approach. Refactoring to fix a bug is fantastic. A progressive/agile/iterative approach to identifying which bugs you intend to look into and fix would also be great.

There is an extensive list of bugs that need to be addressed at https://sourceforge.net/tracker2/?group_id=3248&atid=103248 and http://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag/BUGS at your disposal.

Difficulty: variable

==Additional Project Ideas ==

While code cleanup and refactoring projects are our top-priority, other projects will certainly be considered if the idea is well thought-out and the student is passionate about the idea. Continuing a previously successful GSoC project is also something very highly desired (even if it does entail new code).

=== BZWorkBench world editor enhancement ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

Difficulty: high

=== Global authentication daemon ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

Difficulty: medium

=== Enhanced server listing ===
''This project is a continuation of a previous GSoC project. Please contact the developers before proposing this idea to determine the current status of the work and how you can help continue the effort.''

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.

Difficulty: low

=== 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 "[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)]".

Difficulty: high

= Mentors =

BZFlag operates with a ''group mentoring'' approach meaning that students may (and should) call upon any developer within the community if they have questions. The mentors for 2009 are:

* Sean Morrison (brlcad/learner)
* Daniel Remenak (DTRemenak/Erroneous)
* Jeffrey Myers (JeffM/JeffM2501)
* Julio Jiménez Borreguero (Manu/jujibo)
* Scott Wichser (Blast/Blast007)
* David Wollner (JB diGriz)
* Joe VanOverberghe (Donny_Baker)
* James Lawrence (spldart)

[[Category: Development]]

Google Summer of Code: 2009

2009-03-16T15:41:53Z

Learner: modularization of the graphics code

The 2009 Google Summer of Code was announced in February, 2009. BZFlag will again be applying as a mentoring organization. Given our enormously successful participation in the program in 2007 and 2008, we're very excited to be participating again and we're very happy to see the applications that were submitted. BZFlag will be accepting student project proposals from March 23 until April 3. Hints and tips on [[Google_Summer_of_Code|getting started, preparing a submission, and the application process]] were available.

= Promotion Flyers =

We're now soliciting designs for our 2009 GSoC promotional flyer. If you are interested in providing a design, please contact us!

= 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.

==High-Priority Project Ideas==

This year our focus is on quality. We need to stabilize our codebase and prepare for a major release. That being the case, a '''*very*''' strong preference will be given to cleanup and refactoring projects over ''new code'' projects. Please keep that in mind when preparing your application and do contact the developers if there are any questions.

=== 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.

Difficulty: variable

=== 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.

Difficulty: medium

=== 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 [[DevelopmentGoals#libGame|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.

Difficulty: low

=== Modularization of OpenGL logic===
BZFlag's graphics code is (unfortunately) spread throughout the codebase with OpenGL calls being made in thousands of places. The goal of this project would be to encapsulate *all* of the OpenGL calls into one place as a first step towards encapsulating all of the graphics code so that we can adopt a 3D rendering engine. This project should not be to integrate with an engine, though, as there's too much that needs to happen beforehand. Step one is getting all of the graphics code contained.

Difficulty: low

=== 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.

Difficulty: low

=== Lots o' Bug hunting ===
Basically, this project idea is right up in line with helping new developers become familiarized with the BZFlag code and to help us improve our code quality for an upcoming major release. Propose fixing bugs. You can propose fixing a lot of them or just a few, but you should be detailed and methodical in your approach. Refactoring to fix a bug is fantastic. A progressive/agile/iterative approach to identifying which bugs you intend to look into and fix would also be great.

There is an extensive list of bugs that need to be addressed at https://sourceforge.net/tracker2/?group_id=3248&atid=103248 and http://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag/BUGS at your disposal.

Difficulty: variable

==Additional Project Ideas ==

While code cleanup and refactoring projects are our top-priority, other projects will certainly be considered if the idea is well thought-out and the student is passionate about the idea. Continuing a previously successful GSoC project is also something very highly desired (even if it does entail new code).

=== 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.

Difficulty: high

=== 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.

Difficulty: medium

=== 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.

Difficulty: low

=== 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 "[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)]".

Difficulty: high

= Mentors =

BZFlag operates with a ''group mentoring'' approach meaning that students may (and should) call upon any developer within the community if they have questions. The mentors for 2009 are:

* Sean Morrison (brlcad/learner)
* Daniel Remenak (DTRemenak/Erroneous)
* Jeffrey Myers (JeffM/JeffM2501)
* Julio Jiménez Borreguero (Manu/jujibo)
* Scott Wichser (Blast/Blast007)
* David Wollner (JB diGriz)
* Joe VanOverberghe (Donny_Baker)
* James Lawrence (spldart)

[[Category: Development]]

Google Summer of Code: 2009

2009-03-16T15:36:09Z

Learner: add a rough difficulty measure

The 2009 Google Summer of Code was announced in February, 2009. BZFlag will again be applying as a mentoring organization. Given our enormously successful participation in the program in 2007 and 2008, we're very excited to be participating again and we're very happy to see the applications that were submitted. BZFlag will be accepting student project proposals from March 23 until April 3. Hints and tips on [[Google_Summer_of_Code|getting started, preparing a submission, and the application process]] were available.

= Promotion Flyers =

We're now soliciting designs for our 2009 GSoC promotional flyer. If you are interested in providing a design, please contact us!

= 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.

==High-Priority Project Ideas==

This year our focus is on quality. We need to stabilize our codebase and prepare for a major release. That being the case, a '''*very*''' strong preference will be given to cleanup and refactoring projects over ''new code'' projects. Please keep that in mind when preparing your application and do contact the developers if there are any questions.

=== 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.

Difficulty: variable

=== 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.

Difficulty: medium

=== 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 [[DevelopmentGoals#libGame|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.

Difficulty: medium

=== 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.

Difficulty: low

=== Lots o' Bug hunting ===
Basically, this project idea is right up in line with helping new developers become familiarized with the BZFlag code and to help us improve our code quality for an upcoming major release. Propose fixing bugs. You can propose fixing a lot of them or just a few, but you should be detailed and methodical in your approach. Refactoring to fix a bug is fantastic. A progressive/agile/iterative approach to identifying which bugs you intend to look into and fix would also be great.

There is an extensive list of bugs that need to be addressed at https://sourceforge.net/tracker2/?group_id=3248&atid=103248 and http://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag/BUGS at your disposal.

Difficulty: variable

==Additional Project Ideas ==

While code cleanup and refactoring projects are our top-priority, other projects will certainly be considered if the idea is well thought-out and the student is passionate about the idea. Continuing a previously successful GSoC project is also something very highly desired (even if it does entail new code).

=== 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.

Difficulty: high

=== 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.

Difficulty: medium

=== 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.

Difficulty: low

=== 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 "[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)]".

Difficulty: high

= Mentors =

BZFlag operates with a ''group mentoring'' approach meaning that students may (and should) call upon any developer within the community if they have questions. The mentors for 2009 are:

* Sean Morrison (brlcad/learner)
* Daniel Remenak (DTRemenak/Erroneous)
* Jeffrey Myers (JeffM/JeffM2501)
* Julio Jiménez Borreguero (Manu/jujibo)
* Scott Wichser (Blast/Blast007)
* David Wollner (JB diGriz)
* Joe VanOverberghe (Donny_Baker)
* James Lawrence (spldart)

[[Category: Development]]

Google Summer of Code: 2009

2009-03-16T15:34:26Z

Learner: add bug hunting/fixing specifically

The 2009 Google Summer of Code was announced in February, 2009. BZFlag will again be applying as a mentoring organization. Given our enormously successful participation in the program in 2007 and 2008, we're very excited to be participating again and we're very happy to see the applications that were submitted. BZFlag will be accepting student project proposals from March 23 until April 3. Hints and tips on [[Google_Summer_of_Code|getting started, preparing a submission, and the application process]] were available.

= Promotion Flyers =

We're now soliciting designs for our 2009 GSoC promotional flyer. If you are interested in providing a design, please contact us!

= 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.

==High-Priority Project Ideas==

This year our focus is on quality. We need to stabilize our codebase and prepare for a major release. That being the case, a '''*very*''' strong preference will be given to cleanup and refactoring projects over ''new code'' projects. Please keep that in mind when preparing your application and do contact the developers if there are any questions.

=== 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.

=== 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 [[DevelopmentGoals#libGame|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.

=== 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.

=== Lots o' Bug hunting ===
Basically, this project idea is right up in line with helping new developers become familiarized with the BZFlag code and to help us improve our code quality for an upcoming major release. Propose fixing bugs. You can propose fixing a lot of them or just a few, but you should be detailed and methodical in your approach. Refactoring to fix a bug is fantastic. A progressive/agile/iterative approach to identifying which bugs you intend to look into and fix would also be great.

There is an extensive list of bugs that need to be addressed at https://sourceforge.net/tracker2/?group_id=3248&atid=103248 and http://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag/BUGS at your disposal.

==Additional Project Ideas ==

While code cleanup and refactoring projects are our top-priority, other projects will certainly be considered if the idea is well thought-out and the student is passionate about the idea. Continuing a previously successful GSoC project is also something very highly desired (even if it does entail new code).

=== 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.

=== 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.

=== 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.

=== 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 "[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)]".

= Mentors =

BZFlag operates with a ''group mentoring'' approach meaning that students may (and should) call upon any developer within the community if they have questions. The mentors for 2009 are:

* Sean Morrison (brlcad/learner)
* Daniel Remenak (DTRemenak/Erroneous)
* Jeffrey Myers (JeffM/JeffM2501)
* Julio Jiménez Borreguero (Manu/jujibo)
* Scott Wichser (Blast/Blast007)
* David Wollner (JB diGriz)
* Joe VanOverberghe (Donny_Baker)
* James Lawrence (spldart)

[[Category: Development]]

Google Summer of Code: 2009

2009-03-16T15:28:41Z

Learner: organize into high and other priority projects, emphasize code cleanup and refactoring over new code projects

The 2009 Google Summer of Code was announced in February, 2009. BZFlag will again be applying as a mentoring organization. Given our enormously successful participation in the program in 2007 and 2008, we're very excited to be participating again and we're very happy to see the applications that were submitted. BZFlag will be accepting student project proposals from March 23 until April 3. Hints and tips on [[Google_Summer_of_Code|getting started, preparing a submission, and the application process]] were available.

= Promotion Flyers =

We're now soliciting designs for our 2009 GSoC promotional flyer. If you are interested in providing a design, please contact us!

= 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.

==High-Priority Project Ideas==

This year our focus is on quality. We need to stabilize our codebase and prepare for a major release. That being the case, a '''*very*''' strong preference will be given to cleanup and refactoring projects over ''new code'' projects. Please keep that in mind when preparing your application and do contact the developers if there are any questions.

=== 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.

=== 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 [[DevelopmentGoals#libGame|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.

=== 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.

==Additional Project Ideas ==

While code cleanup and refactoring projects are our top-priority, other projects will certainly be considered if the idea is well thought-out and the student is passionate about the idea. Continuing a previously successful GSoC project is also something very highly desired (even if it does entail new code).

=== 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.

=== 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.

=== 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.

=== 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 "[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)]".

= Mentors =

BZFlag operates with a ''group mentoring'' approach meaning that students may (and should) call upon any developer within the community if they have questions. The mentors for 2009 are:

* Sean Morrison (brlcad/learner)
* Daniel Remenak (DTRemenak/Erroneous)
* Jeffrey Myers (JeffM/JeffM2501)
* Julio Jiménez Borreguero (Manu/jujibo)
* Scott Wichser (Blast/Blast007)
* David Wollner (JB diGriz)
* Joe VanOverberghe (Donny_Baker)
* James Lawrence (spldart)

[[Category: Development]]

Google Summer of Code

2009-03-16T15:19:36Z

Learner: remove toc, add header with 2009 info

__NOTOC__

'''For the third year in a row, BZFlag has applied to participate in the [http://code.google.com/soc Google Summer of Code]!

=== Organization selections for 2009 will be announced on March 18th.===
If we are accepted, a notice will be made first to our IRC channel.

===See our [[Google_Summer_of_Code/2009|2009 GSoC page]] for anticipatory details.===

Please see our [[Google Summer of Code/2009#Proposal Ideas|Proposal Ideas]] for a list of the projects that are of interest. Student applications will be accepted via the GSoC website between March 23 and April 3.

=Overview=

Since 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.

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.

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

= Getting started =

* Read this page
* 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!

= 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 '''[[Google_Summer_of_Code/Application_Guidelines|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 [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.

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.

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 =

== [[Google Summer of Code/2009|2009 (more details here)]] ==

'''''We've applied! We're waiting.'''''

If we're 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.

== [[Google Summer of Code/2008|2008 (more details here)]] ==
{|align="right"
|[[Image:BZGSoC2008_small.gif |thumb|left|128px]]
|}

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 which were successfully passed and 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 which were successful in their projects.

==== [[Google Summer of Code/2007#Promotion Flyers|Promotion Flyers]] ====

[[Category: Development]]

Google Summer of Code

2009-03-16T15:15:37Z

Learner: /* The application review process */ old date

'''For the third year in a row, BZFlag has applied to participate in the [http://code.google.com/soc Google Summer of Code]!

Please see our [[Google Summer of Code/2009#Proposal Ideas|Proposal Ideas]] for a list of the project that are currently of interest to the BZFlag developers. Student applications will be accepted via the GSoC website between March 23 and April 3.

Since 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.

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.

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

= Getting started =

* Read this page
* 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!

= 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 '''[[Google_Summer_of_Code/Application_Guidelines|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 [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.

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.

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 =

== [[Google Summer of Code/2009|2009 (more details here)]] ==

'''''We've applied! We're waiting.'''''

If we're 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.

== [[Google Summer of Code/2008|2008 (more details here)]] ==
{|align="right"
|[[Image:BZGSoC2008_small.gif |thumb|left|128px]]
|}

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 which were successfully passed and 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 which were successful in their projects.

==== [[Google Summer of Code/2007#Promotion Flyers|Promotion Flyers]] ====

[[Category: Development]]

Google Summer of Code

2009-03-16T15:15:11Z

Learner: /* BZFlag participation in GSoc */ note the slot counts, note that we really don't want new code

'''For the third year in a row, BZFlag has applied to participate in the [http://code.google.com/soc Google Summer of Code]!

Please see our [[Google Summer of Code/2009#Proposal Ideas|Proposal Ideas]] for a list of the project that are currently of interest to the BZFlag developers. Student applications will be accepted via the GSoC website between March 23 and April 3.

Since 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.

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.

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

= Getting started =

* Read this page
* 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!

= 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 '''[[Google_Summer_of_Code/Application_Guidelines|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 [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.

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.

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.

Be sure to follow the aforementioned application preparation steps mentioned above. The final list of selected proposals will be announced on April 14, 2008 at 12:00 noon PDT.

= BZFlag participation in GSoc =

== [[Google Summer of Code/2009|2009 (more details here)]] ==

'''''We've applied! We're waiting.'''''

If we're 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.

== [[Google Summer of Code/2008|2008 (more details here)]] ==
{|align="right"
|[[Image:BZGSoC2008_small.gif |thumb|left|128px]]
|}

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 which were successfully passed and 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 which were successful in their projects.

==== [[Google Summer of Code/2007#Promotion Flyers|Promotion Flyers]] ====

[[Category: Development]]

Google Summer of Code

2009-03-16T15:09:47Z

Learner: /* 2009 (more details here) */ show some excitement

'''For the third year in a row, BZFlag has applied to participate in the [http://code.google.com/soc Google Summer of Code]!

Please see our [[Google Summer of Code/2009#Proposal Ideas|Proposal Ideas]] for a list of the project that are currently of interest to the BZFlag developers. Student applications will be accepted via the GSoC website between March 23 and April 3.

Since 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.

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.

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

= Getting started =

* Read this page
* 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!

= 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 '''[[Google_Summer_of_Code/Application_Guidelines|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 [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.

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.

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.

Be sure to follow the aforementioned application preparation steps mentioned above. The final list of selected proposals will be announced on April 14, 2008 at 12:00 noon PDT.

= BZFlag participation in GSoc =

== [[Google Summer of Code/2009|2009 (more details here)]] ==

We've applied! We're waiting.

== [[Google Summer of Code/2008|2008 (more details here)]] ==
{|align="right"
|[[Image:BZGSoC2008_small.gif |thumb|left|128px]]
|}

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.

== [[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).

==== [[Google Summer of Code/2007#Promotion Flyers|Promotion Flyers]] ====

[[Category: Development]]

Main Page

2009-03-14T04:06:09Z

Learner: Changed protection level for "Main Page" [edit=autoconfirmed:move=autoconfirmed]

__NOTOC__
[[Image:BZFlag_2010_shiny.png|center]]
{|style="width:100%;margin-top:+.7em;background-color:#fcfcfc;border:1px solid #ccc"
|style="width:56%;color:#000"|
{|style="width:280px;border:solid 0px;background:none"
|-
|style="width:280px;text-align:center;white-space:nowrap;color:#000" |
[[Image:Bzflag-48x48.png|left]]
<div style="font-size:162%;border:none;margin: 0;padding:.1em;color:#000">Welcome to the BZFlag Wiki,</div>
<div style="top:+0.2em;font-size: 95%">The source for community information on most things related to BZFlag!</div>
<div style="font-size:162%;border:none;margin: 0;padding:.1em;color:#000">The BZFlag Wiki motto: [[BZFlagWiki:Be_bold|'''Be Bold!!''']]</div>
<div id="articlecount" style="width:100%;text-align:center;font-size:85%;">[[Special:Statistics|{{NUMBEROFARTICLES}}]] articles available</div>
|}
|style="width:15%;font-size:95%"|
[[Image:Bzflag-48x48.png|right]]
*[http://my.bzflag.org/bb The Forums]
*[http://my.bzflag.org BZFlag Stats]
*[http://sourceforge.net/projects/bzflag/ BZFlag on SourceForge]

|}
Welcome to the BZFlag Wiki. The number of articles is growing, but there is much more to do. Please see the section '''Things To Do''' at the bottom of this page if you would like to help. The intention of this site is to draw together all of the great information about BZFlag and BZFlag related items that is currently scattered in many different places. Bringing all of this information together will make it easier for people to understand and answer all of the questions they have about running a server (options, permissions, set-up, etc.), configuring their client, coding plug-ins, compiling the source code, and anything else they can think of. All are welcome to contribute and may edit most pages. With everyone's help we can make this site a great resource to the BZFlag community. Please remember the BZFlag Wiki's new motto, [[BZFlagWiki:Be_bold|'''Be Bold''']] (click the link for a full explanation of the motto), when editing articles.

If you are unsure of how to edit or add pages, there is always a link to the [[Help:Contents|'''Help''']] section on the links to the left no matter where you are on the site. Don't be shy; give editing the site a try and be proud of your contributions! You can edit whether or not you have an account created. The advantage of having an account is that you will be credited with the contribution on the ''History'' link/tab of the page. Please take a look at the [[BZFlagWiki:Content Policy|Content Policy]] page for an overview of adding articles.

==Google Summer of Code ==
BZFlag has applied to once again be a mentor organization in the Google Summer of Code. For details, please see the [[Google Summer of Code/2009|2009 Summer of Code wiki page]].

==General Information==
*[[Getting Help]]
*[[:Category:BZFlagWiki_Policy|BZFlag Wiki Policy]]

==Areas of Interest==
*[[:Category:Client|Client]]
*[[:Category:Compiling|Compiling]]
*[[:Category:Concepts|Concepts]]
*[[:Category:Development|Development]]
*[[:Category:Gameplay|Gameplay]]
*[[:Category:Installing|Installing]]
*[[:Category:Leagues|Leagues]]
*[[:Category:Map Making|Map Making]]
*[[:Category:Maps|Maps]]
*[[:Category:Plug-Ins|Plug-ins]]
*[[Releases]]
*[[:Category:Server|Server]]
*[[:Category:Support|Support]]
*[[:Category:Tactics|Tactics]]
*[[Versions]]

==Things To Do==
*[[:Category:Stubs|Stubs]] These are short pages. You can help by expanding the content and adding more detail.
*[[:Special:Wantedpages|Wanted pages]] These are pages which don't exist yet but are pointed to from other pages. You can help by creating them.
*[[:Category:Items to be merged|Pages to merge]] These are pages which are similar. It is suggested that similar pages be merged. You can help by reviewing the pairs of pages and commenting on any proposals by using the "Discussion" tab at the top of each page.
*[[:Category:Old|Pages with old info]] You can help by updating these pages.
*[[:Category:Inaccurate|Inaccurate pages]] You can help by updating these pages.
*[[:Category:Pending Deletions|Pending deletions]] These are pages which have been nominated for deletion. You can help by reviewing these pages and commenting on any proposals by using the "Discussion" tab at the top of each page.

Main Page

2009-03-14T04:04:53Z

Learner:

Google Summer of Code: 2009

2009-03-14T04:03:04Z

Learner: remove 2008 flyer

The 2009 Google Summer of Code was announced in February, 2009. BZFlag will again be applying as a mentoring organization. Given our enormously successful participation in the program in 2007 and 2008, we're very excited to be participating again and we're very happy to see the applications that were submitted. BZFlag will be accepting student project proposals from March 23 until April 3. Hints and tips on [[Google_Summer_of_Code|getting started, preparing a submission, and the application process]] were available.

= Promotion Flyers =

We're now soliciting designs for our 2009 GSoC promotional flyer. If you are interested in providing a design, please contact us!

= 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.

== 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 [[DevelopmentGoals#libGame|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 "[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)]".

== 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.

= Mentors =
The mentors for 2009 are:

* Sean Morrison (brlcad/learner)
* Daniel Remenak (DTRemenak/Erroneous)
* Jeffrey Myers (JeffM/JeffM2501)
* Julio Jiménez Borreguero (Manu/jujibo)
* Scott Wichser (Blast/Blast007)
* David Wollner (JB diGriz)
* Joe VanOverberghe (Donny_Baker)
* James Lawrence (spldart)

[[Category: Development]]

Google Summer of Code

2009-03-14T04:02:20Z

Learner: 2009

'''For the third year in a row, BZFlag has applied to participate in the [http://code.google.com/soc Google Summer of Code]!

Please see our [[Google Summer of Code/2009#Proposal Ideas|Proposal Ideas]] for a list of the project that are currently of interest to the BZFlag developers. Student applications will be accepted via the GSoC website between March 23 and April 3.

Since 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.

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.

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

= Getting started =

* Read this page
* 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!

= 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 '''[[Google_Summer_of_Code/Application_Guidelines|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 [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.

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.

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.

Be sure to follow the aforementioned application preparation steps mentioned above. The final list of selected proposals will be announced on April 14, 2008 at 12:00 noon PDT.

= BZFlag participation in GSoc =

== [[Google Summer of Code/2009|2009 (more details here)]] ==

We've applied. We're waiting.

== [[Google Summer of Code/2008|2008 (more details here)]] ==
{|align="right"
|[[Image:BZGSoC2008_small.gif |thumb|left|128px]]
|}

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.

== [[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).

==== [[Google Summer of Code/2007#Promotion Flyers|Promotion Flyers]] ====

[[Category: Development]]

Google Summer of Code: 2009:OrgApplication

2009-03-13T17:15:15Z

Learner: stub in initial answers, building upon previous year's answers

= Description =
BZFlag is a free online multiplayer cross-platform open source 3D tank battle game that is maintained by an active community of individuals distributed all around the world.. It is one of the most successful and sustained cross-platform open source games ever with an active developer, administrative, and player community. There have been more than a million downloads in the last five years alone and our user base presently consists of more than 200 players online at any time of day or night. The project has actually become more popular over the years as we continue to improve and enhance the game. BZFlag has been under active development since 1992.

Our organization is presently comprised of a rather disparate group of individuals that work on BZFlag because they love the game and the community that surrounds it. There are presently 71 individuals entrusted with access to BZFlag core resources including 46 individuals that have committed source code modifications over the project's life span. Our developer base presently consists of 9 documented core developers that have made extensive contributions to the game and remained active over many years, along with about a dozen apprentice-level developers that are coming up in the ranks, and about two dozen peripheral/casual developers, extension developers, and web integration programmers. Additionally, there are several dozen trusted staffers, server operators, and graphic artists that assist in the day-to-day operations needed by the game for keeping servers up and running, providing server list services, designing artwork, providing network statistics, image hosting, web hosting, and much more.

All of our project developers almost exclusively collaborate on the #bzflag Freenode IRC channel, which is the central hub for most of our development discussions, decision planning meetings, game operations, and network infrastructure administration. We operate via a benevolent dictatorship combined with a meritocracy that strives for consensus between the core developers and other involved community members. Extensive discussions are held for any changes to BZFlag that affect the game's traditional "spirit", mood of gameplay, tone of the user environment, and types of interactions possible in the game. These discussions also include considerations whenever there are new features being added such as new flags, enhanced graphics, or changes to the gameplay. We also serve as a support arm to our user community assisting them with anything from how to get started playing to providing assistance with setting up their own server or even helping them write their own new extensions to the game.

From IRC, we administer network operations for the approximate 18638 registered player base and for the tens of thousands of unregistered players that engage in more than 10000 daily player sessions across more than 250 public servers. As we are a globally distributed network-oriented game, we also maintain the public server listings, provide player tracking, network statistics, global authentication, user and group management, abuse and ban controls, player conflict resolution, competitive league management, and user community support.

= Why is your group applying to participate? What do you hope to gain by participating =

Our primary intention for participating in GSoC 2009 is to hopefully attract new developers. We already have visibility, popularity, familiarity, and a very active community. The strongest factor in our long-term development initiatives, however, is the number of active developers that we have at any given time.

GSoC has shown to provide an exceptional opportunity for us to entice new developers to our community and keep them working with us over the long term. It's been a great program for attracting new talent, inspiring new development initiatives, and even for getting our own developers more organized and collaborating more effectively.

We've enjoyed collaborating on experimental efforts that have had strong academic and research goals, while helping promote and improve BZFlag in the process. BZFlag is used by several universities (e.g., Brigham-Young University) as an artificial intelligence framework and has also been the subject of several academic research projects related to network communications (ACM-published research papers). Just this past year, Indiana University worked with our staff to use BZFlag as a platform for conducting a social network analysis. We'd particularly like to improve these facilities to help encourage even wider use of BZFlag for academic and research purposes.

Task-wise, we hope to work with these new developers to implement several enhancements to BZFlag that we know will have a big impact on those that play the game. We found out last year that participating in GSoC simulates our project development activities and forces us to become more organized, collaborative, and deliberate in our focus. Our community is simply filled with great ideas on how to improve the game in wide impacting ways and we would like to encourage these developments. GSoC provides a mutually beneficial means to that end, particularly for students that we can attract to our project as new developers that stay with the project.

= What criteria do you use to select the members of your group? Please be as specific as possible. =

All of the mentors listed are actively engaged in the BZFlag community as core developers, apprentice developers, web service developers, and network operators. Mentors were selected from among our core community of project contributors that are actively engaged on a day-to-day basis . All mentors needed to have gained enough rapport and trust with those already actively involved to the extent that they've been entrusted with source code access, decision-making authority, and that have sustained activity for months or years on end. The mentors also needed to show competency in the BZFlag source code, our project directions, our operating philosophies, and a basic familiarity with our social dynamic.

Several of our apprentice developers were specifically chosen due to the unique perspective that they bring to the development processes. Those individuals help bridge the player-developer gap as those new developers tend to come straight out of the player community and/or are heavily involved and familiar with the needs of our users. They form a critical part of our technical support infrastructure.

Cumulatively, the #bzflag IRC channel provides even more insight, interaction, and mentoring support as our community spans several domains of software development expertise including game development, computer-aided design, computer-aided machining, software testing, web development, computer graphics development, systems and kernel development, and general application development. As our channel is constantly (24/7) engaged in user and developer support to a global community, the channel will be our predominant means of interaction for all mentors and students. Each individual listed can also dedicate a minimum of 10 hours a week on average with an understanding that there are additional demands on their time at the start, midterm, and final evaluation periods of the program.

= Has your group participated previously? If so, please summarize your involvement and any past successes and failures. =

Yes, we participated for the first time in 2007 and again in 2008. We quickly found that being involved in GSoC requires considerable time and resources necessitating massive amounts of coordination, communication, and progress tracking. Our developers spent many hours mentoring students, reviewing their code, and discussing implementation details.

We found that being involved in GSoC encouraged our community to become more organized and accountable than usual. It also instigated other developer activity and interest throughout our community, particularly amongst players that were eagerly interested in trying out the new facilities being developed by the students.

The experience taught our mentors a great deal in terms of managing different personalities, expectations we had of their abilities to work with minimal process overhead, and how to respond quickly and effectively to inadequate levels of effort. In our view, we did very well in managing our students but will need to dedicate even more time and attention to the students if we are allowed to participate again. We intend to focus more on integrating the students quickly, engaging them more in the design and testing process throughout development, and making sure they follow our development criteria from start to finish so that we can help establish them as long-term developers in our community.

= What is your plan for dealing with disappearing contributors? =

If a student's interest or availability to participate in the summer project seems to be diverging or otherwise waning, efforts will be made to motivate the student through discussions and hands-on interactive development intended to stimulate their progress. Being a 3D graphics-oriented game, we have the benefit of most tasks actually resulting in something "fun" that rather easily captures and maintains interest. However, should the student's focus still remain diminished or should the student unexpectedly disappear without notice, the administrator will relay this status with Google after repeated attempts to contact the student fail.

Also, as a learned measure from last year, the students are going to be required to make very frequent commits. If they're not committing, then they are not working. At least they won't be working effectively. Having them commit frequently gives us a very good estimate of their activity level as well as where they are in the development process. We strongly adhere to "commit early, commit often".

If the student is not around or is not working as much as they need to be, we will have discussions with them, see what's going on, and do so proactively. We learned from one of our students last year when they were in serious danger of failing that a simple change in their accountability can have a massive impact on their motivation. We will strive to recognize our students' personalities quickly, so that we can impose as much or as little process overhead as it required for them to be effective developers. Additional process requirements (such as daily or weekly reports and commit quotas) may then be imposed for students that slip consistently fall behind schedule.

Similarly, by interacting with the students on a daily basis and preferably by having them be joined to our IRC channel while they are working on BZFlag, it allows mentors to keep a careful eye on all student progress and readily discuss issues with them. As is done for any developer, having them be readily available for interactive discussion on IRC frequently helps avoid misunderstandings, disagreements, and frustrations and at worst makes any issues apparent as soon as possible. The IRC channel is the hub of our primary development activity providing source commit announcements, developer access, user insight, interactive discussions, and near immediate response to questions and comments.

Other than that, the formula for dealing with disappearing students really just boils down to communication. It's a very organic process and we don't believe that there is one answer for all students. The measures described above help us focus on having the most effective communication that works with our development team but will necessarily be tailored to each student individually. Issues that we cannot resolve will be brought forward to Google for guidance, as was done last year.

= What is your plan for dealing with disappearing members? =

BZFlag contains an active community that is constantly engaged in providing assistance for any level of questions whether they are introductory user support questions or technical source code development questions. The predominance of BZFlag's active software development interactions are discussed *entirely* on the #bzflag Freenode IRC channel. We require that developers participate and interact on the IRC channel with other developers to their fullest capacity, and preferably without them relying on any single individual so that they may receive assistance and perspective from a variety of developers (it's not like all our developers always agree and, ultimately, our meritocracy prevails over decisions and directions).

One of the main reasons for requiring developers to be on the IRC channel is to help mitigate issues whereby a student might encounter difficulties interacting with any particular individual. It also exposes them to all developers so that they can become more quickly in-tune with which developers are presently active and the politics of our development practices.

The students will be encouraged to interact on the IRC channel at all times to provide a continued on-going dialog with the other BZFlag developers as well so that everyone is informed of progress and development directions. If a given mentor is not responding to the student, whether intentional or incapable, or if a mentor is unreachable for more than a couple days, one of several backup mentors are available to step in.

Should some situation arise that incapacitates a mentor from being able to participate, several backup mentors are available that can be assigned to the student on the spot and immediately pick up where other mentors leave off. Several of our mentors and administrators also know each other in person and have physical access to one another, so we can go smack them if they're not participating effectively or should they try to disappear online. That said, all mentors selected based on their activity this year to help minimize any issues.

This year, we have also set up a mentor's blog to help our mentors make announcements more effectively and to provide suggestions for other GSoC projects. This blog has already shown to be rather effective in making GSoC-specific announcements and for coordinating information amongst the mentors. Once the students get started with their projects, we also plan to use the blog as a centralized information resource for developers to see the latest commits from the students and the status of their project progress.

= What steps will you take to encourage contributors to interact with your community before, during, and after the program? =

Being a game, i.e. an entertainment application, we have a somewhat unique benefit of actually being enjoyable before, during, and after the student's participation in the program and are even often "addictive". Most people enjoy playing BZFlag and often after they play the game for a little while, they can "get hooked" on the game. "Quick to learn, difficult to master" is our motto and this holds true both in the game and for development. Once new developers see the impact they're having on such a large user community, they quickly become addicted to the development aspects and making things more enjoyable for our players. We encourage our developers to play so that they understand the needs of the game and the needs of the existing player community in addition to becoming familiar with how various portions of the source code relate to behaviors in the game.

Before the program, we have a specific checklist of tasks that we have prepared to give them definitive actions that they need to perform. These steps include introducing themselves to our IRC channel, having a Sourceforge account, becoming familiar with Subversion if they are not already, checking out the BZFlag sources, compiling their own version of BZFlag, playing the game with that version, registering with our global account services, becoming familiar with our websites and on-line services, and publishing their list of goals milestones for the community to see.

As our IRC infrastructure and developer operations are already well established, we can (and frequently do) readily point new developer interests to our documentation and engage them in discussion. We have lots of existing documentation, web infrastructure, and network resources available to get new developers familiar and interested in development directions quickly. Given our involvement with GSoC last year, we now also have an established mindset of successful interaction criteria that gets students quickly involved in our user community so that they feel like part of the family.

One of the interactions that worked very well last year was having the students directly interact with the users, letting them represent their efforts, and having their efforts be strongly supported and promoted by the other developers. We intend to take additional steps this year to continuously integrate the students code throughout the program and work on introducing our player community to the features being developed even more early on. The goal will be to instill a since of belonging and giving them a sense of appreciation for the hard-work they are putting into their code.

= What will you do to ensure that your accepted contributors stick with the project after the program concludes? =

It is our responsibility to not neglect or abandon the students. We have to give them the time and attention that they deserve, and we need to share with the students the respect and appreciation we have of their efforts so that they remain interested and involved. BZFlag is fortunate to have not had any significant issues with attrition; many of our developers tend to remain involved with the project for a long time. There is natural turn-over as interests shift and general fluctuations from year to year, but we sustain a relatively stable development rate and that is in no small part due to our interactive and friendly development environment.

New developers are often enticed to stick around and contribute simply because we actively promote their changes to the user community when releases are made, and the user community responds vocally to just about every single modification that gets made to the game no matter how small. For the topics that we are soliciting ideas, the efforts of the student have the ability to make a major impact on the game that will be exceedingly visible, and will encourage continued development not only by the student and other developers as well. We will necessarily encourage students to remain involved with the project by welcoming them to our development team, integrating them as quickly as possible, giving them development responsibilities, and showing them the rewards and impact of their efforts.

It's our job to encourage their passion for BZFlag development long after GSoC concludes.

Google Summer of Code: 2009

2009-03-13T17:06:42Z

Learner: New page: The 2009 Google Summer of Code was announced in February, 2009. BZFlag will again be applying as a mentoring organization. Given our enormously successful participation in the program in...

The 2009 Google Summer of Code was announced in February, 2009. BZFlag will again be applying as a mentoring organization. Given our enormously successful participation in the program in 2007 and 2008, we're very excited to be participating again and we're very happy to see the applications that were submitted. BZFlag will be accepting student project proposals from March 23 until April 3. Hints and tips on [[Google_Summer_of_Code|getting started, preparing a submission, and the application process]] were available.

= Promotion Flyers =

{|align="right"
|[[Image:BZGSoC2008_small.gif|thumb|left|512px]]
|}

We're now soliciting designs for our 2009 GSoC promotional flyer. If you are interested in providing a design, please contact us!

= 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.

== 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 [[DevelopmentGoals#libGame|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 "[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)]".

== 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.

= Mentors =
The mentors for 2009 are:

* Sean Morrison (brlcad/learner)
* Daniel Remenak (DTRemenak/Erroneous)
* Jeffrey Myers (JeffM/JeffM2501)
* Julio Jiménez Borreguero (Manu/jujibo)
* Scott Wichser (Blast/Blast007)
* David Wollner (JB diGriz)
* Joe VanOverberghe (Donny_Baker)
* James Lawrence (spldart)

[[Category: Development]]

Main Page

2009-01-31T20:02:24Z

Learner: update the gsoc section to past tense (testing snazzy new cia notifier)

__NOTOC__
[[Image:BZFlag_2010_shiny.png|center]]
{|style="width:100%;margin-top:+.7em;background-color:#fcfcfc;border:1px solid #ccc"
|style="width:56%;color:#000"|
{|style="width:280px;border:solid 0px;background:none"
|-
|style="width:280px;text-align:center;white-space:nowrap;color:#000" |
[[Image:Bzflag-48x48.png|left]]
<div style="font-size:162%;border:none;margin: 0;padding:.1em;color:#000">Welcome to the BZFlag Wiki,</div>
<div style="top:+0.2em;font-size: 95%">The source for community information on most things related to BZFlag!</div>
<div style="font-size:162%;border:none;margin: 0;padding:.1em;color:#000">The BZFlag Wiki motto: [[BZFlagWiki:Be_bold|'''Be Bold!!''']]</div>
<div id="articlecount" style="width:100%;text-align:center;font-size:85%;">[[Special:Statistics|{{NUMBEROFARTICLES}}]] articles available</div>
|}
|style="width:15%;font-size:95%"|
[[Image:Bzflag-48x48.png|right]]
*[http://my.bzflag.org/bb The Forums]
*[http://my.bzflag.org BZFlag Stats]
*[http://sourceforge.net/projects/bzflag/ BZFlag on SourceForge]

|}
Welcome to the newly launched BZFlag Wiki. The number of articles is growing, but there is much more to do. Please see the section '''Things To Do''' at the bottom of this page if you would like to help. The intention of this site is to draw together all of the great information about BZFlag and BZFlag related items that is currently scattered in many different places. Bringing all of this information together will make it easier for people to understand and answer all of the questions they have about running a server (options, permissions, set-up, etc.), configuring their client, coding plug-ins, compiling the source code, and anything else they can think of. All are welcome to contribute and may edit most pages. With everyone's help we can make this site a great resource to the BZFlag community. Please remember the BZFlag Wiki's new motto, [[BZFlagWiki:Be_bold|'''Be Bold''']] (click the link for a full explanation of the motto), when editing articles.

If you are unsure of how to edit or add pages, there is always a link to the [[Help:Contents|'''Help''']] section on the links to the left no matter where you are on the site. Don't be shy; give editing the site a try and be proud of your contributions! You can edit whether or not you have an account created. The advantage of having an account is that you will be credited with the contribution on the ''History'' link/tab of the page. Please take a look at the [[BZFlagWiki:Content Policy|Content Policy]] page for an overview of adding articles.

==Google Summer of Code 2008==
BZFlag participated as a mentor organization in the 2008 Google Summer of Code. For details, please see the [[Google Summer of Code/2008|2008 Summer of Code wiki page]]. The following applications were accepted:

* [[Enhanced Server Listing]] - [[User:KingofCamelot|David Sanders]], mentored by [[User:DonnyBaker|Joseph Van Overberghe]]
* [[BZAuthd]] - [[User:Wyk3d|Istvan Szakats]], mentored by David Wollner
* Collision code modularization and transfer to server - Joshua Charles Bodine, mentored by [[User:JeffM2501|Jeff Myers]]
* [[LibBZW|Creating and Implementing a libBZW]] - [[User:Lukstr|Luke Rewega]], mentored by [[User:DTRemenak|Daniel Remenak ]]
* [[BZWGen revisited]] - Kornel Kisielewicz, mentored by Julio Jiménez Borreguero
* [[BZFWeb|BZFWeb, a web-based BZFS admin interface]] - [[User:BugQ|Harrison Reiser]], mentored by [[User:Spldart|James R Lawrence]]

==General Information==
*[[Getting Help]]
*[[:Category:BZFlagWiki_Policy|BZFlag Wiki Policy]]

==Areas of Interest==
*[[:Category:Client|Client]]
*[[:Category:Compiling|Compiling]]
*[[:Category:Concepts|Concepts]]
*[[:Category:Development|Development]]
*[[:Category:Gameplay|Gameplay]]
*[[:Category:Installing|Installing]]
*[[:Category:Leagues|Leagues]]
*[[:Category:Map Making|Map Making]]
*[[:Category:Maps|Maps]]
*[[:Category:Plug-Ins|Plug-ins]]
*[[Releases]]
*[[:Category:Server|Server]]
*[[:Category:Support|Support]]
*[[:Category:Tactics|Tactics]]
*[[Versions]]

==Things To Do==
*[[:Category:Stubs|Stubs]] These are short pages. You can help by expanding the content and adding more detail.
*[[:Special:Wantedpages|Wanted pages]] These are pages which don't exist yet but are pointed to from other pages. You can help by creating them.
*[[:Category:Items to be merged|Pages to merge]] These are pages which are similar. It is suggested that similar pages be merged. You can help by reviewing the pairs of pages and commenting on any proposals by using the "Discussion" tab at the top of each page.
*[[:Category:Old|Pages with old info]] You can help by updating these pages.
*[[:Category:Inaccurate|Inaccurate pages]] You can help by updating these pages.
*[[:Category:Pending Deletions|Pending deletions]] These are pages which have been nominated for deletion. You can help by reviewing these pages and commenting on any proposals by using the "Discussion" tab at the top of each page.

IRC Cloaks

2008-10-09T07:09:14Z

Learner: /* Cloak Format */

==Overview==
Since BZFlag is a registered project with the Freenode IRC network, we are able to give you IRC cloaks (custom hostmasks) for the project.

They are available to developers, server owners, and players that have helped the project out or been affiliated for a significant time.

==Process==
Cloaks must be requested with one of the project administrators (TimRiker, JeffM, and brlcad). It is the sole discretion of the project administrators on the use and distribution of cloaks.

They must (only) be requested in person on IRC. Do not send requests via BZBB or via E-mail. Send one of the project administrators a private message on IRC stating that you'd like to have a cloak and what you think that cloak should be.

Users that request cloaks must be registered on BZBB and have a valid E-Mail address attached to the name.

==Usage==

Users that have a BZFlag cloak must conduct themselves in a mature and civil manner at all times on Freenode. The cloak associates you as a representative of the project and your behavior should not reflect poorly upon the BZFlag community. Users that do not conduct themselves in a reasonable manner will have their cloaks removed.

==Cloak Format==

All BZFlag cloaks follow a standard format.

Long-time players in good standing can request a player cloak. Long-time means you've been playing for at least 6 months. You should have an established BZFlag callsign that you've been using over that timeframe.

'''/bzflag/player/BZ_NAME/IRC_NAME'''

Users that are contributors to the project in other ways can get a contributors cloak

'''/bzflag/contributor/BZ_NAME/IRC_NAME'''

Server owners that run major servers that fully support global services, and promote good clean play can get a server owner cloak

'''/bzflag/serverop/BZ_NAME/IRC_NAME'''

Users that are developers (i.e., have commit access) can get a developer cloak:

'''/bzflag/developer/BZ_NAME/IRC_NAME'''

Project administrators are allowed a project admin cloak

'''/bzflag/projectadmin/BZ_NAME/IRC_NAME'''

'''BZ_NAME''' is your registered BZBB username. '''IRC_NAME''' is any one of your registered IRC nicknames. If your BZ_NAME and IRC_NAME are the same, it can be listed just once.

==Examples==
Player: /bzflag/player/SportChick/essy
Contributor: /bzflag/contributor/ibot
Server Op: /bzflag/serverop/Manu
Developer: /bzflag/developer/Chestal
Admin: /bzflag/projectadmin/learner/brlcad

IRC Cloaks

2008-10-09T07:00:59Z

Learner: cleanup diction and spelling, add examples and emphasis

==Overview==
Since BZFlag is a registered project with the Freenode IRC network, we are able to give you IRC cloaks (custom hostmasks) for the project.

They are available to developers, server owners, and players that have helped the project out or been affiliated for a significant time.

==Process==
Cloaks must be requested with one of the project administrators (TimRiker, JeffM, and brlcad). It is the sole discretion of the project administrators on the use and distribution of cloaks.

They must (only) be requested in person on IRC. Do not send requests via BZBB or via E-mail. Send one of the project administrators a private message on IRC stating that you'd like to have a cloak and what you think that cloak should be.

Users that request cloaks must be registered on BZBB and have a valid E-Mail address attached to the name.

==Usage==

Users that have a BZFlag cloak must conduct themselves in a mature and civil manner at all times on Freenode. The cloak associates you as a representative of the project and your behavior should not reflect poorly upon the BZFlag community. Users that do not conduct themselves in a reasonable manner will have their cloaks removed.

==Cloak Format==

All BZFlag cloaks follow a standard format.

Long time players in good standing can request a player cloak

'''/bzflag/player/BZ_NAME/IRC_NAME'''

Users that are contributors to the project in other ways can get a contributors cloak

'''/bzflag/contributor/BZ_NAME/IRC_NAME'''

Server owners that run major servers that fully support global services, and promote good clean play can get a server owner cloak

'''/bzflag/serverop/BZ_NAME/IRC_NAME'''

Users that are developers (i.e., have commit access) can get a developer cloak:

'''/bzflag/developer/BZ_NAME/IRC_NAME'''

Project administrators are allowed a project admin cloak

'''/bzflag/projectadmin/BZ_NAME/IRC_NAME'''

'''BZ_NAME''' is your registered BZBB username. '''IRC_NAME''' is any one of your registered IRC nicknames. If your BZ_NAME and IRC_NAME are the same, it can be listed just once.

==Examples==
Player: /bzflag/player/SportChick/essy
Contributor: /bzflag/contributor/ibot
Server Op: /bzflag/serverop/Manu
Developer: /bzflag/developer/Chestal
Admin: /bzflag/projectadmin/learner/brlcad

Help:Contents

2008-07-12T11:53:54Z

Learner: Undo revision 4763 by HzoWdh (Talk)

To many people a wiki is a new and interesting concept. A wiki is a web site where everyone is allowed, and even encouraged, to add, edit, and/or correct any page. While this would seem to lead to mass chaos, the concept surprisingly works. As you are editing pages, others are reading them and making corrections. So with an active and vibrant community the wiki becomes a better and better place, all of the time. We encourage everyone to contribute (please read the [[BZFlagWiki:Content Policy|Content Policy]]) and remember the BZFlag Wiki motto: [[BZFlagWiki:Be_bold|'''Be Bold''']]
;Reading
:[[Help:Navigation|Navigation]]
:[[Help:Searching|Searching]]
:[[Help:Tracking changes|Tracking changes]]
;Editing
:[[Help:Editing pages|Editing pages]]
:[[Help:Starting a new page|Starting a new page]]
:[[Help:Formatting|Formatting]]
:[[Help:Links|Links]]
:[[Help:Categories|Categories]]
;Advanced Editing
:[[Help:Images|Images]]
:[[Help:Tables|Tables]]
:[[Help:Templates|Templates]]
:[[Help:Variables|Variables]]
:[[Help:Managing files|Managing files]]
;Customizing
:[[Help:Preferences|Preferences]]
:[[Help:Skins|Skins]]
;Administration
:[[Help:Interwiki linking|Interwiki linking]]
:[[Help:Namespaces|Namespaces]]

[[Category:Help| ]]

List Server Usage Policy

2008-07-09T06:41:15Z

Learner:

==Overview==
The list server usage policy describes the intended use of the BZFlag [[List Server]] service that is provided by the project administration. It also describes the acceptable behavior for the users of the system.

==Policy==
The BZFlag List Server provides listing services along with other game-related functionality to the BZFlag players and server owners at no charge. Use of the list server, however, is provided under stipulations of what is fair and reasonable for being non-disruptive to the game and our community. The primary goal of the list server is to support the community and the game project by providing a list of games for players to use. Abuses of the list server that do not promote this same goal will not be tolerated.

For players the list server provides a list of compatible internet games, public service messages, and an account verification system that can tie a player to their BZFlag discussion forum account ( also known as their 'Global Login' and their BZBB account ). All interactions with the list server are potentially logged or monitored. All information sent to the list server is kept confidential and is only used by the project staff for administration and development purposes.

Players who are disruptive or fraudulent to any of BZFlag's public services including (but not limited to) project and league services, multiple servers, or large groups of individuals may be denied access to the public list servers at any time, and at the sole discretion of the BZFlag list server administrators. Players who have been known to cheat or abuse the game on multiple public servers may also be denied access. Similarly, anyone engaging in denial-of-service attacks or are otherwise detrimentally impacting the public services may have their access blocked.

For server owners, the list server provides public listing of any number of BZFlag game server ([[BZFS]]) instances, as well as token and permission group verification for global login services. No player personal information is sent from the list server to the game servers other than the player's callsign and their global login status.

Server owners who run servers that are cheat servers ( publicly advertised or not ), use disruptive server modifications, use "bot" clients to artificially inflate their list position, or have disruptive or slanderous names or descriptions may be removed from the list and/or have access to other BZFlag public services revoked.

The project itself does not have anything to do with exactly how specific servers are run or administered.

It is important to understand that usage of pubic services is provided to the comunict at the project's sole discretion. Neither the data contained in it, nor the service of hosting it is in any way "open source" and no user has any inherent "right" to use any of the public services. The project administrators provide these services for the betterment of the community and abuse will not be tolerated.

The project reserves the right to allow or disallow access to any public or project service to any user at any time without notice and without reason.

==See also==
[[List Server]]

[[Global Registration]]

[[Category:Public Services]]

Google Summer of Code: 2008

2008-04-22T07:12:00Z

Learner: /* Proposal Ideas */

The 2008 Google Summer of Code 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, we're very excited to be participating again and we're very happy to see the applications that were submitted. BZFlag accepted student project proposals from March 24 until April 7 ending at 5:00 PDT (0:00 April 8 GMT). Further information on our proposal ideas are below. Hints and tips on [[Google_Summer_of_Code|getting started, preparing a submission, and the application process]] were available. '''''Accepted student proposals will be announced here and on the Google Summer of Code homepage on April 21 at around 12:00 PM PDT (19:00 GMT).'''''

= Promotion Flyers =

{|align="right"
|[[Image:BZGSoC2008_small.gif|thumb|left|512px]]
|}

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.

* English ([http://my.bzflag.org/gsoc/BZGSoC2008.pdf PDF]) ([http://my.bzflag.org/gsoc/BZGSoC2008.png PNG])
* Deutsch | German ([http://my.bzflag.org/gsoc/BZGSoC2008_de.pdf PDF]) ([http://my.bzflag.org/gsoc/BZGSoC2008_de.png PNG])
* Español | Spanish ([http://my.bzflag.org/gsoc/BZGSoC2008_es.pdf PDF]) ([http://my.bzflag.org/gsoc/BZGSoC2008_es.png PNG])

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

= 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.

== 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 [[DevelopmentGoals#libGame|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 "[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)]".

== 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.

= Mentors =
The mentors for 2008 are;
* Sean Morrison (brlcad/learner)
* Daniel Remenak (DTRemenak/Erroneous)
* Jeffrey Myers (JeffM/JeffM2501)
* Julio Jiménez Borreguero (Manu/jujibo)
* Scott Wichser (Blast/Blast007)
* David Wollner (JB diGriz)
* Joe VanOverberghe (Donny_Baker)
* James Lawrence (spldart)

= 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)

[[Category: Development]]

Google Summer of Code: Evaluation

2008-04-09T05:23:53Z

Learner: Completely replace the evaluation criteria from 2007. There were too many points of confusion and the criteria were poorly defined. This year their are 6 specific categories.

In order to help consistently, effectively, and efficiently evaluate GSoC student applications, specific evaluation criteria should be used by project mentors. GSoC applications are to be scored on a scale of '''0 to 6''' where 0 is a ''poor candidate'' that meets no evaluation criteria and 6 would indicate a ''perfect candidate'' that fulfills all criteria.

In order to score applications, each mentor needs to indicate the project(s) they would be willing to mentor by selecting the "I am willing to Mentor" button on the mentor dashboard. For scoring an application, apply the below 6 evaluation criteria and evaluate a judgement scoring between 0.0 and 1.0 for each. Round the cumulative score to the closest integer when ranking. '''''Only rank applications you are willing to mentor.'''''

= Evaluation Criteria =

* '''Significance:''' Application Impact and Relevance
** How many people would the proposal prospectively benefit?
** Does it have benefits outside of our community?
* '''Approach:''' Application Quality and Feasibility
** How well is their application written?
** Does what they propose seem reasonable?
* '''Visibility:''' Responsive and Engaging
** Have they been active in the channel?
** Do they respond to questions and engage in discussions?
* '''Charisma:''' Personality and Ease-of-Interaction
** Are they easy to talk to?
** How well do they interact with others?
* '''Potential:''' Long Term Developer Karma
** Are they excited about working on BZFlag?
** Perceived chance that they will stick around and keep coding?
* '''Ability:''' Technical Coding Aptitude
** How impressive is their patch?
** Can they actually write code?

= Notes =

The Google mentor evaluation form allows for three positive and two negative evaluation levels (in addition to unevaluated/zero): '''+4 +2 +1 -1 -2'''. The sum of all your rank selections should equal more than 0 and less than 7. Additionally:

* Do not use negative scores except to correct or adjust your own evaluation.
* Do not adjust or compensate for other mentor scores (up or down) even to correct an obvious mistake.
* Do not evaluate them if you don't care for their proposal and/or don't really intend to mentor that student.
* Do not base your evaluation on the evaluations and comments of others.

Scores for each application will be '''averaged''' and ''weighted by mentor assignments'' after evaluations are complete and plugged into a spreadsheet for group review before the final ordering.

Google Summer of Code

2008-03-31T23:37:19Z

Learner: use the flyer for both

'''For the second year in a row, BZFlag has been accepted to participate in the [http://code.google.com/soc/2008 2008 Google Summer of Code]!

Please see our [[Google Summer of Code/2008#Proposal Ideas|Proposal Ideas]] for a list of the project that are currently of interest to the BZFlag developers. Student applications for GSoC 2008 will be accepted via the GSoC website between March 24 and March 31 at http://code.google.com/soc/2008

Since 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.

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.

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

= Getting started =

* Read this page
* Read our [[Google Summer of Code/2008|proposal ideas]] page
* Read our [[Google_Summer_of_Code/Application_Guidelines|application guidelines]]
* Read our [[Google Summer of Code Acceptance|development 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]
* [http://code.google.com/soc/2008 Apply] between March 24th and '''April 7th''' (was March 31st)

= 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 '''[[Google_Summer_of_Code/Application_Guidelines|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.

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 [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.

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.

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.

Be sure to follow the aforementioned application preparation steps mentioned above. The final list of selected proposals will be announced on April 14, 2008 at 12:00 noon PDT.

= BZFlag participation in GSoc =

== [[Google Summer of Code/2008|2008 (more details here)]] ==
{|align="right"
|[[Image:BZGSoC2008_small.gif |thumb|left|128px]]
|}

The Google Summer of Code 2008 was announced on February 25, 2008. Given the substantial successes and opportunities provided by the program, BZFlag will continue to participate in the program. BZFlag has been accepted as a mentoring organization, and will accept student project proposals from March 24 to March 31. Please click the link above for more information and for project proposal ideas.

== [[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).

==== [[Google Summer of Code/2007#Promotion Flyers|Promotion Flyers]] ====

[[Category: Development]]

Google Summer of Code

2008-03-31T23:30:20Z

Learner: extension

'''For the second year in a row, BZFlag has been accepted to participate in the [http://code.google.com/soc/2008 2008 Google Summer of Code]!

Please see our [[Google Summer of Code/2008#Proposal Ideas|Proposal Ideas]] for a list of the project that are currently of interest to the BZFlag developers. Student applications for GSoC 2008 will be accepted via the GSoC website between March 24 and March 31 at http://code.google.com/soc/2008

Since 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.

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.

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

= Getting started =

* Read this page
* Read our [[Google Summer of Code/2008|proposal ideas]] page
* Read our [[Google_Summer_of_Code/Application_Guidelines|application guidelines]]
* Read our [[Google Summer of Code Acceptance|development 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]
* [http://code.google.com/soc/2008 Apply] between March 24th and '''April 7th''' (was March 31st)

= 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 '''[[Google_Summer_of_Code/Application_Guidelines|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.

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 [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.

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.

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.

Be sure to follow the aforementioned application preparation steps mentioned above. The final list of selected proposals will be announced on April 14, 2008 at 12:00 noon PDT.

= BZFlag participation in GSoc =

== [[Google Summer of Code/2008|2008 (more details here)]] ==
{|align="right"
|[[Image:BZGSoC2008_small.gif |thumb|left|128px]]
|}

The Google Summer of Code 2008 was announced on February 25, 2008. Given the substantial successes and opportunities provided by the program, BZFlag will continue to participate in the program. BZFlag has been accepted as a mentoring organization, and will accept student project proposals from March 24 to March 31. Please click the link above for more information and for project proposal ideas.

== [[Google Summer of Code/2007|2007 (more details here)]] ==
{|align="right"
|[[Image:Gsoc_postmortem_preview.png|thumb|left|128px|http://my.bzflag.org/gsoc/bzflag_gsoc2007_post_mortem.pdf]]
|}
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).

==== [[Google Summer of Code/2007#Promotion Flyers|Promotion Flyers]] ====

[[Category: Development]]

Google Summer of Code

2008-03-22T05:23:29Z

Learner: image for 2008

'''For the second year in a row, BZFlag has been accepted to participate in the [http://code.google.com/soc/2008 2008 Google Summer of Code]!

Please see our [[Google Summer of Code/2008#Proposal Ideas|Proposal Ideas]] for a list of the project that are currently of interest to the BZFlag developers. Student applications for GSoC 2008 will be accepted via the GSoC website between March 24 and March 31 at http://code.google.com/soc/2008

Since 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.

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.

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

= Getting started =

* Read this page
* Read our [[Google Summer of Code/2008|proposal ideas]] page
* Read our [[Google_Summer_of_Code/Application_Guidelines|application guidelines]]
* Read our [[Google Summer of Code Acceptance|development 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]
* [http://code.google.com/soc/2008 Apply] between March 24 and March 31

= 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 '''[[Google_Summer_of_Code/Application_Guidelines|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.

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 [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.

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.

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.

Be sure to follow the aforementioned application preparation steps mentioned above. The final list of selected proposals will be announced on April 14, 2008 at 12:00 noon PDT.

= BZFlag participation in GSoc =

== [[Google Summer of Code/2008|2008 (more details here)]] ==
{|align="right"
|[[Image:BZGSoC2008_small.gif |thumb|left|128px]]
|}

The Google Summer of Code 2008 was announced on February 25, 2008. Given the substantial successes and opportunities provided by the program, BZFlag will continue to participate in the program. BZFlag has been accepted as a mentoring organization, and will accept student project proposals from March 24 to March 31. Please click the link above for more information and for project proposal ideas.

== [[Google Summer of Code/2007|2007 (more details here)]] ==
{|align="right"
|[[Image:Gsoc_postmortem_preview.png|thumb|left|128px|http://my.bzflag.org/gsoc/bzflag_gsoc2007_post_mortem.pdf]]
|}
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).

==== [[Google Summer of Code/2007#Promotion Flyers|Promotion Flyers]] ====

[[Category: Development]]

Google Summer of Code: 2008

2008-03-22T05:18:36Z

Learner:

The 2008 Google Summer of Code 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, we're very excited to be participating again and look forward to seeing the student submissions. 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 our proposal ideas are below. '''''Candidate students should be sure to read our suggestions for [[Google_Summer_of_Code|getting started, preparing a submission, and the application process]].'''''

= Promotion Flyers =

{|align="right"
|[[Image:BZGSoC2008_small.gif|thumb|left|512px]]
|}

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.

* English ([http://my.bzflag.org/gsoc/BZGSoC2008.pdf PDF]) ([http://my.bzflag.org/gsoc/BZGSoC2008.png PNG])
* Deutsch | German ([http://my.bzflag.org/gsoc/BZGSoC2008_de.pdf PDF]) ([http://my.bzflag.org/gsoc/BZGSoC2008_de.png PNG])
* Español | Spanish ([http://my.bzflag.org/gsoc/BZGSoC2008_es.pdf PDF]) ([http://my.bzflag.org/gsoc/BZGSoC2008_es.png PNG])

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

= 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 [[DevelopmentGoals#libGame|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 "[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)]".

== 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)

[[Category: Development]]

Google Summer of Code: Acceptance

2008-03-22T05:10:41Z

Learner: separate application preparation and participation sections

This page is intended to lay out the basic "'''rules and requirements'''" that the BZFlag project is going to require of all [[Google Summer of Code]] students whose project proposals are accepted. Unless otherwise arranged with the BZFlag GSoC administrator (contact brlcad via IRC on irc.freenode.net), it will be expected that all students comply with the requirements outlined below.

== Application requirements ==

=== Make a patch ===
We want to make sure that you have rudimentary skills in compiling code, reading other people's code, and can even simply get BZFlag to compile. Prepare and submit a patch to our [http://sourceforge.net/tracker/?group_id=3248&atid=303248 Sourceforge patches tracker].

Don't fret. The patch can be almost anything just so long as it is can be applied to the BZFlag sources with very minimal hassle. It should be something actually useful. The patch should ''not'' just be whitespace, indent, or style changes as we automate those periodically. It ''should'' be a functional patch such as fixing a known bug (see our BUGS file or sf bug tracker) or implementing some very minor uncontroversial feature (see our TODO file). Bug fixes are generally the preferred scope but even something as trivial as fixing typos can make an acceptable patch. This is one of several opportunities to impress us, so feel free to be creative.

Be sure to include a link to the Sourceforge patch tracker item in your application.

=== Play BZFlag with the mentors ===
We will schedule several open gaming gatherings during the application process and ask that serious applicants come play a round of BZFlag with us. You should compile your own client using the latest BZFlag trunk sources (which is incompatible with the latest public release) when you come to the gaming session. We will work out available times to play with you after you've submitted an application.

You should ''play the game'' from a binary you've built yourself before beginning any work. You should do this ''at least once'' before the gathering if not more if you are so inclined. Being able to compile the sources on your own equipment is a very ''basic task'' that is beyond the scope of GSoC and will be an expected unassisted capacity of all students once the summer coding begins. Additionally, understanding the existing player community, what they like and dislike, and seeing how they interact is all '''very important''' for most developers to have at least a basic familiarity with. In the end, your changes will (hopefully) be pushed out to the community and you be cognizant of what that will ''mean''.

We'll be glad to help you the first time if you run into trouble. Talk to the developers.

=== Come talk to us ===
You '''''really''''' should be talking to the BZFlag developers long before submitting your application. Discuss your ideas with us on the IRC channel. Communication is a huge part of our evaluation criteria.

== Participation requirements ==

=== Assign copyright and license under the LGPL ===
Per the GSoC [http://code.google.com/support/bin/answer.py?answer=60328&topic=10728 FAQ], BZFlag requires that any work performed and provided while participating in BZFlag development will be in accordance with BZFlag's existing [http://bzflag.cvs.sourceforge.net/*checkout*/bzflag/bzflag/COPYING license] ('''LGPL''') and that full nonexclusive copyright will be assigned to Tim Riker, the project copyright holder.

=== Provide weekly progress reports ===
In addition to any communications you hold with a given mentor, the administrator, or any of the developers, it will be expected of all students that they will ''submit a brief progress report'' on a '''weekly''' basis. These reports won't need to be more than a few sentences (or at most a couple of paragraphs, whatever is appropriate) but the reports should give an indication of your overall progress, things you discover, tasks completed, difficulties encountered, milestones reached, and other similar details on your activities. You will be expected to complete a report every week, at least once a week. More information on the exact method for providing these reports will be provided after the projects commence.

=== List your milestones ===
All projects will be required to submit a '''minimum''' of three and a maximum of ten ''milestones'' for your project. These are not deliverables but, rather, are overall tasks that should be completed throughout the duration of your work. These should be necessary implementation steps and not include any research or familiarity phases. In the end, there is code that must be produced and your milestones should be a (very) rough breakdown for estimating your actual implementation progress. These milestones should be '''published in your first progress report,''' that is, at the beginning of code development (before, on or very soon after May 28).

=== Be available via IRC ===
All students will be expected to '''join the #bzflag IRC channel''' on irc.freenode.net while they are working. Students are expected to '''be on''' the channel so they can be responsive and available to the questions, inquiries, and suggestions of other BZFlag developers. BZFlag development occurs ''entirely'' over IRC as it is the central gathering forum for core development activities, developer discussions, and more. See [http://irchelp.org here] if you are new to IRC and need assistance finding a client (or just do a search). Interaction via IRC is '''required'''.

=== Create a Sourceforge account ===
BZFlag sources live in a Subversion repository on Sourceforge. You will need a Sourceforge account and will be expected to abide by the same coding requirements of the other existing developers. You will similarly be expected to know the basics of how to work with SVN and check in changes, resolve conflicts, and apply patches as needed. SVN has a nearly identical interface to CVS -- if you're familiar with CVS, then you should be fine. If you don't have a Sourceforge account, be sure to get one and familiarize yourself with BZFlag's sourceforge [http://sf.net/projects/bzflag/ account]. Whether students work on a branch or on the mainline will vary depending on the student and the project.

=== Evaluate your performance ===
Particularly for projects that interact with the client or server run-loop or affect networking (but also for others), '''quantitatively evaluate your performance''' and the impact your modifications will make. Don't prematurely optimize and don't over-architect, but also don't make guesses or assumptions either. Use a performance profiler, test your code, add temporary debug timers, have a peer review your approach, etc. Modifications to the game client and network code that detrimentally impact performance in non-optional ways will likely be rejected outright.

=== Write maintainable code ===
This requirement cannot be stressed enough. One of the primary evaluation criteria for all students is how maintainable is the end result. This is not only maintainability from the stand-point of source code longevity as it stands written, but also involves other higher-level maintainability and integration aspects. Does your implementation use interfaces, languages, tools, or techniques that introduce some new requirement to widespread BZFlag development? If so, that choice needs to be discussed and '''justified''' or otherwise mitigated as a concern. Any usage of external dependencies needs to be consensus approved by the core developers. Is your code comprehensive and comprehensible? Well-documented? Organized? You are required to follow BZFlag's [http://bzflag.cvs.sourceforge.net/*checkout*/bzflag/bzflag/DEVINFO existing] developer guidelines, existing code style, and established conventions.

=== Write portable code ===
BZFlag has an extensive heritage of being as portable as reasonably possible with effort continually being taken to make sure the entire codebase works on a vareity of compilation and run-time environments. While each developer's perception of what is ''reasonable'' certainly fluctuates over the years and from developer to developer, the general intention is that code written for BZFlag should function the '''same''' on most moderately popular operating system environments as much as possible including Linux, Mac OS X, and Windows as well as other platforms. It is each developer's responsibility to either make sure their code isn't platform-specific or that equivalent functionality is provided on other maintained platforms. You are expected to interact with other developers when portability issues are raised to resolve any problems. Portability of any dependencies being used must similarly be taken into account and relates to the aforementioned maintainability requirement.

=== Write complete code ===
Perhaps treat each week like it is your last. You should be able to hand over functional code over just about any time during development (within a day or so) to another developer. Focus on completing tasks, completing code features, and working on keeping your code functional at '''all''' stages of development. That way, no matter how far you get on your milestones or deliverable(s), other developers will be able to review, test, and readily integrate your code. Plan your development approach accordingly. You should generally not "stub" code functionality (though comments are good), but instead focus on coding "deep" instead of "wide". It's generally preferred to have 2 features that work fully, than 5 features that half-work or even 20 features that are all 90% complete.

== Pre-Flight Participation Checklist ==

* Read and agree to the above requirements
* Join the #bzflag IRC channel and introduce yourself
* Create a Sourceforge account
* Be familiar with the basics of Subversion (aka SVN).
* Compile and run BZFlag from source
* Prepare a patch
** [http://my.bzflag.org/w/BZFlag_SVN Checkout sources] from SVN
** Familiarize yourself with the basic [http://my.bzflag.org/w/BZFlag_Source source layout]
** Compile
** Play
* Familiarize yourself with BZFlag's on-line websites and services
** http://bzflag.org
** http://my.bzflag.org
** http://my.bzflag.org/bb/
** http://my.bzflag.org/w/
** http://sf.net/projects/bzflag
* Create a list of 3 to 10 milestones
* Document your milestones
* Submit your application
** Include a link to your patch
** Include your IRC handle

Google Summer of Code

2008-03-22T04:38:16Z

Learner: primary goal

'''For the second year in a row, BZFlag has been accepted to participate in the [http://code.google.com/soc/2008 2008 Google Summer of Code]!

Please see our [[Google Summer of Code/2008#Proposal Ideas|Proposal Ideas]] for a list of the project that are currently of interest to the BZFlag developers. Student applications for GSoC 2008 will be accepted via the GSoC website between March 24 and March 31 at http://code.google.com/soc/2008

Since 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.

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.

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

= Getting started =

* Read this page
* Read our [[Google Summer of Code/2008|proposal ideas]] page
* Read our [[Google_Summer_of_Code/Application_Guidelines|application guidelines]]
* Read our [[Google Summer of Code Acceptance|development 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]
* [http://code.google.com/soc/2008 Apply] between March 24 and March 31

= 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 '''[[Google_Summer_of_Code/Application_Guidelines|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.

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 [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.

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.

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.

Be sure to follow the aforementioned application preparation steps mentioned above. The final list of selected proposals will be announced on April 14, 2008 at 12:00 noon PDT.

= BZFlag participation in GSoc =

== [[Google Summer of Code/2008|2008 (more details here)]] ==

The Google Summer of Code 2008 was announced on February 25, 2008. Given the substantial successes and opportunities provided by the program, BZFlag will continue to participate in the program. BZFlag has been accepted as a mentoring organization, and will accept student project proposals from March 24 to March 31. Please click the link above for more information and for project proposal ideas.

== [[Google Summer of Code/2007|2007 (more details here)]] ==
{|align="right"
|[[Image:Gsoc_postmortem_preview.png|thumb|left|128px|http://my.bzflag.org/gsoc/bzflag_gsoc2007_post_mortem.pdf]]
|}
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).

==== [[Google Summer of Code/2007#Promotion Flyers|Promotion Flyers]] ====

[[Category: Development]]

Google Summer of Code

2008-03-22T04:33:29Z

Learner: add a getting started section, and merge in application detail sections

'''For the second year in a row, BZFlag has been accepted to participate in the [http://code.google.com/soc/2008 2008 Google Summer of Code]!

Please see our [[Google Summer of Code/2008#Proposal Ideas|Proposal Ideas]] for a list of the project that are currently of interest to the BZFlag developers. Student applications for GSoC 2008 will be accepted via the GSoC website between March 24 and March 31 at http://code.google.com/soc/2008

Since 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.

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 a great opportunity for BZFlag development initiatives.

= Getting started =

* Read this page
* Read our [[Google Summer of Code/2008|proposal ideas]] page
* Read our [[Google_Summer_of_Code/Application_Guidelines|application guidelines]]
* Read our [[Google Summer of Code Acceptance|development 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]
* [http://code.google.com/soc/2008 Apply] between March 24 and March 31

= 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 '''[[Google_Summer_of_Code/Application_Guidelines|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.

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 [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.

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.

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.

Be sure to follow the aforementioned application preparation steps mentioned above. The final list of selected proposals will be announced on April 14, 2008 at 12:00 noon PDT.

= BZFlag participation in GSoc =

== [[Google Summer of Code/2008|2008 (more details here)]] ==

The Google Summer of Code 2008 was announced on February 25, 2008. Given the substantial successes and opportunities provided by the program, BZFlag will continue to participate in the program. BZFlag has been accepted as a mentoring organization, and will accept student project proposals from March 24 to March 31. Please click the link above for more information and for project proposal ideas.

== [[Google Summer of Code/2007|2007 (more details here)]] ==
{|align="right"
|[[Image:Gsoc_postmortem_preview.png|thumb|left|128px|http://my.bzflag.org/gsoc/bzflag_gsoc2007_post_mortem.pdf]]
|}
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).

==== [[Google Summer of Code/2007#Promotion Flyers|Promotion Flyers]] ====

[[Category: Development]]

Google Summer of Code: 2008

2008-03-22T04:07:55Z

Learner: move the application sections up to the main gsoc page since it's not 2008-specific

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 =

{|align="right"
|[[Image:BZGSoC2008_small.gif|thumb|left|512px]]
|}

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.

* English ([http://my.bzflag.org/gsoc/BZGSoC2008.pdf PDF]) ([http://my.bzflag.org/gsoc/BZGSoC2008.png PNG])
* Deutsch | German ([http://my.bzflag.org/gsoc/BZGSoC2008_de.pdf PDF]) ([http://my.bzflag.org/gsoc/BZGSoC2008_de.png PNG])
* Español | Spanish ([http://my.bzflag.org/gsoc/BZGSoC2008_es.pdf PDF]) ([http://my.bzflag.org/gsoc/BZGSoC2008_es.png PNG])

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

= 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 [[DevelopmentGoals#libGame|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 "[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)]".

== 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)

[[Category: Development]]

Google Summer of Code: 2008

2008-03-22T04:05:55Z

Learner: /* Program Evaluation */

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 =

{|align="right"
|[[Image:BZGSoC2008_small.gif|thumb|left|512px]]
|}

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.

* English ([http://my.bzflag.org/gsoc/BZGSoC2008.pdf PDF]) ([http://my.bzflag.org/gsoc/BZGSoC2008.png PNG])
* Deutsch | German ([http://my.bzflag.org/gsoc/BZGSoC2008_de.pdf PDF]) ([http://my.bzflag.org/gsoc/BZGSoC2008_de.png PNG])
* Español | Spanish ([http://my.bzflag.org/gsoc/BZGSoC2008_es.pdf PDF]) ([http://my.bzflag.org/gsoc/BZGSoC2008_es.png PNG])

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 [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.

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 [[DevelopmentGoals#libGame|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 "[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)]".

== 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)

[[Category: Development]]

BZFlagWiki - User contributions [en]

BZFlag SVN

Auto-props

Mime-types

Mime-types

Mime-types

Google Summer of Code: 2009

Google Summer of Code: 2009

Google Summer of Code: 2009

Google Summer of Code: 2009

Google Summer of Code: 2009

Google Summer of Code: 2009

Google Summer of Code: 2009

Google Summer of Code: 2009

Google Summer of Code: 2009

Google Summer of Code: 2009

Google Summer of Code: 2009

Google Summer of Code: 2009

Google Summer of Code: 2009

Google Summer of Code: 2009

Google Summer of Code: 2009

Google Summer of Code: 2009

Google Summer of Code: 2009

Google Summer of Code: 2009

Google Summer of Code

Google Summer of Code

Google Summer of Code

Google Summer of Code

Main Page

Main Page

Google Summer of Code: 2009

Google Summer of Code

Google Summer of Code: 2009:OrgApplication

Google Summer of Code: 2009

Main Page

IRC Cloaks

IRC Cloaks

Other Links

Help:Contents

List Server Usage Policy

Google Summer of Code: 2008

Google Summer of Code: Evaluation

Google Summer of Code

Google Summer of Code

Google Summer of Code

Google Summer of Code: 2008

Google Summer of Code: Acceptance

Google Summer of Code

Google Summer of Code

Google Summer of Code: 2008

Google Summer of Code: 2008