BZFlagWiki - User contributions [en]

Google Summer of Code

2007-03-22T20:17:30Z

Jujibo: /* Mentors and Credits */

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

= Preparing an Application =

There is no specific format to applications, but you should be detailed in your approach and background information about yourself. Please state specifically what you intend to deliver and any implementation details you feel relevant such as what language you intend to use. C/C++ proposals are preferred though others will be considered. Please do not just submit the summaries contained below as they are high-level ideas. Your proposal should be detailed and more specific. Submit your application to Google [http://groups.google.com/group/google-summer-of-code-announce/web/guide-to-the-gsoc-web-app-for-student-applicants HERE].

If you have talked with us on IRC about your SoC proposal, please '''include your IRC nickname somewhere in your proposal.'''

Early proposal submission is encouraged as it gives us more time to review your proposal in detail, comment on them, and potentially ask for additional input. Submitting closer to the deadline won't necessarily be a negative consideration as all submissions will be predominantly judged on their merit, but submitting early can be an advantage if your submission is similar to someone else's submission.



= Proposal Ideas =

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

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

== 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 [http://ogre3d.org/ OGRE], [http://www.crystalspace3d.org/ Crystal Space], [http://www.openscenegraph.com/ OpenSceneGraph], or [http://irrlicht.sourceforge.net/ Irrlicht].

== 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 [http://robocode.sourceforge.net/ Robocode] [http://www-128.ibm.com/developerworks/java/library/j-robocode/ API] should be made available for controlling AI tank players so that collaboration with other AI efforts can be leveraged. A scripting interface (perhaps using [http://www.swig.org/ SWIG]) should be provided on top of that API to allow dynamic control of the AI agents from a scripting language like Python, Ruby, Lua, Tcl, or Perl.

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

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

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

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

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

== <INSERT YOUR IDEA HERE> ==
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.

= Promotion Flyers =

[[Image:BZGSoC2007 small.gif]]

Feel free to use the below flyer to help spread the word about our involvement with the Google Summer of Code. We'd love to hear about where all our flyer has been posted at through our [http://my.bzflag.org/irc/ IRC channel]. Flyers have been translated to other languages that we have mentors for, though please submit your application in English. While many developers can converse (fluently) in other languages, we do ask that developer discussions be held in English where possible.

* English ([http://my.bzflag.org/gsoc/BZGSoC2007.pdf PDF]) ([http://my.bzflag.org/gsoc/BZGSoC2007.png PNG])
* Deutsch | German ([http://my.bzflag.org/gsoc/BZGSoC2007_de.pdf PDF]) ([http://my.bzflag.org/gsoc/BZGSoC2007_de.png PNG])
* Español | Spanish ([http://my.bzflag.org/gsoc/BZGSoC2007_es.pdf PDF]) ([http://my.bzflag.org/gsoc/BZGSoC2007_es.png PNG])


= Mentors and Credits =

Thanks to the following BZFlag developers for their participation as mentors:

* Julio Jiménez Borreguero (aka jujibo aka Manu)
* Sean Morrison (aka learner aka brlcad)
** interested in AI and authentication list server services
* Jeffrey Myers (aka JeffM2501)
** interested in game editor
* Daniel Remenak (aka DTRemenak aka Erroneous)
* Mark Thomas (aka menotume)
* David Trowbridge (aka purple_cow)
* Alfredo Tupone (aka c3po)
** interested in Crystal Space integration

Additionally, special thanks to others in #bzflag that have provided support and feedback including:

* a_meteorite and DTRemenak
** for proofreading and copy editing the GSoC submission
* JeffM2501 and DTRemenak
** for proof editing the promotional flyer
* Saturos
** for translating the promotional flyer to German
* quantumdot and Manu
** for translating the promotional flyer to Spanish
* others...

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

[[Category: Development]]

CrystalSpace client

2007-02-19T20:13:51Z

Jujibo:

[[Category:Client]]
An ongoing effort is to provide bzflag with a [http://crystalspace3d.org crystalspace] client.

The version is very experimental and it is compatible with the 2.0 version. It will be only available via CVS, you can get it using the branch v2_0_cs_branch.

In the current status, the client is playable, but has less functionalities than the stable release, so don't get it unless you want to help that development.

That is the plan on the development, subject to change without any prior notification:

# Integrate bzflag client in the Crystal-Space framework, particularly regarding the event handling nature of it. (done)
# Handle the command line interface a la Crystal-Space: (done)
#* Option values separated by '=' instead of ' '
#* Own handling of -help
#* Request of option on the command line using CS API
# Joystick handling done from Crystal Space (done) This is actually having less functionality of native porting, as the force feedback is missing. I'll think I'll revert the joystick change when the work will go further.
# Let CS knows about the sdl canvas: this is probably done loading the sdl plugins and integrating the handling of CS with the own bzflag management of the window. If we stay compatible with sdl, we will have still a working bzflag.
# Crystal-Space manages the mouse, as far as possible.
# Crystal-Space manages the keyboard, as far as possible.
# Remove all the opengl from bzflag and start to render the Tank using the CS API
# Build the world element using CS API
# Build the Menu selection using the Crazy Eddie GUI
# Rewrite the collision detection code using the ode plugin
# Ship it!

My idea is to have at any stage of development a working client, so we can see the product and change the direction of development at an early stage, if that is required, or abandon this idea at all.

Actual work on this project is off line the 2.2 release. If the integration succeed, and the performance indicators are ok, only then we can think this work is good for formal release on whatever version is available at the moment. As probably crystal space is not going to be supported on ''alien'' architectures, the goal is not to substitute the old client, but to provide an enhanced version of it. We'll see.

Any developer is invited to contribute, having time and wish. I just ask to coordinate the effort with me. (atupone)

CrystalSpace client

2007-02-19T20:01:07Z

Jujibo: Enumerate TODO list

[[Category:Client]]
An ongoing effort is to provide bzflag with a crystalspace client.

The version is very experimental and it is compatible with the 2.0 version. It will be only available via CVS, you can get it using the branch v2_0_cs_branch.

In the current status, the client is playable, but has less functionalities than the stable release, so don't get it unless you want to help that development.

That is the plan on the development, subject to change without any prior notification:

<ol>
<li> Integrate bzflag client in the Crystal-Space framework,
particularly regarding the event handling nature of it. (done)
</li>
<li> Handle the command line interface a la Crystal-Space: (done)
</li>
<ul>
<li> Option values separated by '=' instead of ' '
</li>
<li> Own handling of -help
</li>
<li> Request of option on the command line using CS API
</li>
</ul>
<li> Joystick handling done from Crystal Space (done)
</li>
This is actually having less functionality of native
porting,
as the force feedback is missing. I'll think I'll revert the joystick
change when the work will go further. <li> Let CS knows about
the sdl canvas: this is probably done
loading the sdl plugins and integrating the handling of CS with the own
bzflag management of the window. If we stay compatible with sdl, we
will have still a working bzflag.
</li>
<li> Crystal-Space manages the mouse, as far as possible.
</li>
<li> Crystal-Space manages the keyboard, as far as possible.
</li>
<li> Remove all the opengl from bzflag and start to render the
Tank using the CS API
</li>
<li> Build the world element using CS API
</li>
<li> Build the Menu selection using the Crazy Eddie GUI
</li>
<li> Rewrite the collision detection code using the ode plugin
</li>
<li> Ship it!
</li>
</ol>

My idea is to have at any stage of development a working client, so we can see the product and change the direction of development at an early stage, if that is required, or abandon this idea at all.

Actual work on this project is off line the 2.2 release. If the integration succeed, and the performance indicator are ok, only then we can think this work is good for formal release on whatever version is available at the moment. As probably crystal space is not going to be supported on ''alien'' architectures, the goal is not to substitute the old client, but to provide an enhanced version of it. We'll see.

Any developer is invited to contribute, having time and wish. I just ask to coordinate the effort with me. (atupone)

CrystalSpace client

2007-02-19T19:52:59Z

Jujibo: Colourizing the (done) string

[[Category:Client]]
An ongoing effort is to provide bzflag with a crystalspace client.

The version is very experimental and it is compatible with the 2.0 version. It will be only available via CVS, you can get it using the branch v2_0_cs_branch.

In the current status, the client is playable, but has less functionalities than the stable release, so don't get it unless you want to help that development.

That is the plan on the development, subject to change without any prior notification:

* Integrate bzflag client in the Crystal-Space framework, particularly regarding the event handling nature of it. (done)

* Handle the command line interface a la Crystal-Space: (done)

** Option values separated by '=' instead of ' '
** Own handling of -help
** Request of option on the command line using CS API
* Joystick handling done from Crystal Space (done)
: This is actually having less functionality of native porting, as the force feedback is missing. I'll think I'll revert the joystick change when the work will go further.
* Let CS knows about the sdl canvas: this is probably done loading the sdl plugins and integrating the handling of CS with the own bzflag management of the window. If we stay compatible with sdl, we will have still a working bzflag.
* Crystal-Space manages the mouse, as far as possible.
* Crystal-Space manages the keyboard, as far as possible.
* Remove all the opengl from bzflag and start to render the Tank using the CS API
* Build the world element using CS API
* Build the Menu selection using the Crazy Eddie GUI
* Rewrite the collision detection code using the ode plugin
* Ship it!

My idea is to have at any stage of development a working client, so we can see the product and change the direction of development at an early stage, if that is required, or abandon this idea at all.

Actual work on this project is off line the 2.2 release. If the integration succeed, and the performance indicator are ok, only then we can think this work is good for formal release on whatever version is available at the moment. As probably crystal space is not going to be supported on ''alien'' architectures, the goal is not to substitute the old client, but to provide an enhanced version of it. We'll see.

Any developer is invited to contribute, having time and wish. I just ask to coordinate the effort with me. (atupone)

CrystalSpace client

2007-02-19T19:49:16Z

Jujibo:

[[Category:Client]]
An ongoing effort is to provide bzflag with a crystalspace client.

The version is very experimental and it is compatible with the 2.0 version. It will be only available via CVS, you can get it using the branch v2_0_cs_branch.

In the current status, the client is playable, but has less functionalities than the stable release, so don't get it unless you want to help that development.

That is the plan on the development, subject to change without any prior notification:

* Integrate bzflag client in the Crystal-Space framework, particularly regarding the event handling nature of it. (done)
* Handle the command line interface a la Crystal-Space: (done)
** Option values separated by '=' instead of ' '
** Own handling of -help
** Request of option on the command line using CS API
* Joystick handling done from Crystal Space (done): This is actually having less functionality of native porting, as the force feedback is missing. I'll think I'll revert the joystick change when the work will go further.
* Let CS knows about the sdl canvas: this is probably done loading the sdl plugins and integrating the handling of CS with the own bzflag management of the window. If we stay compatible with sdl, we will have still a working bzflag.
* Crystal-Space manages the mouse, as far as possible.
* Crystal-Space manages the keyboard, as far as possible.
* Remove all the opengl from bzflag and start to render the Tank using the CS API
* Build the world element using CS API
* Build the Menu selection using the Crazy Eddie GUI
* Rewrite the collision detection code using the ode plugin
* Ship it!

My idea is to have at any stage of development a working client, so we can see the product and change the direction of development at an early stage, if that is required, or abandon this idea at all.

Actual work on this project is off line the 2.2 release. If the integration succeed, and the performance indicator are ok, only then we can think this work is good for formal release on whatever version is available at the moment. As probably crystal space is not going to be supported on ''alien'' architectures, the goal is not to substitute the old client, but to provide an enhanced version of it. We'll see.

Any developer is invited to contribute, having time and wish. I just ask to coordinate the effort with me. (atupone)