Difference between revisions of "Google Summer of Code"

From BZFlagWiki
Jump to: navigation, search
(add a network testing and simulation environment)
m (Protected "Google Summer of Code": This page is linked to in our GSoC application [edit=autoconfirmed:move=sysop])
(No difference)

Revision as of 22:17, 12 March 2007

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

Graphics Engine Integration

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

Dead Reckoning Networking Enhancements

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

Headless Artificial Intelligence Agent

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

Global Authentication Daemon

Building upon the existing global login infrastructure, the goal of this project would be to provide global account management from within the game client. Working with the other developers, this effort involves writing an authentication daemon in C++ that the client and game servers talk to for account and group management information. The daemon in turn should talk to an LDAP server for persistent storage on the backend, and allow chaining across multiple daemons for data replication and failover service. The daemon will need to provide a well structured communications API that the game client and game servers can securely talk to to register, authenticate against for login, obtain group membership information, and statistics information.

Network Testing and Simulation Environment

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