BZFlagWiki - User contributions [en]

Bz allowJumping

2025-12-15T05:06:49Z

Zehra: merging pages, so it's easier to find details

#REDIRECT [[BZW]]

Shootthrough

2025-12-15T05:05:52Z

Zehra: good page, but we'll probably confuse users if everything is vastly spread accross the whole wiki

#REDIRECT [[BZW]]

Jwir3:csproposal

2025-12-15T05:01:58Z

Zehra: Zehra moved page Jwir3:csproposal to GSoC: Jwir3:csproposal: relates to GSoC proposals, so prefixed with '''GSoC:'''

#REDIRECT [[GSoC: Jwir3:csproposal]]

GSoC: Jwir3:csproposal

2025-12-15T05:01:58Z

Zehra: Zehra moved page Jwir3:csproposal to GSoC: Jwir3:csproposal: relates to GSoC proposals, so prefixed with '''GSoC:'''

= Integration of Crystal Space into BZFlag =
Scott Johnson 
email: scottj@cs.umn.edu 
irc nick: jwir3 
 
== Synopsis ==
Crystal Space is a 3D SDK for game development. One of the long standing goals of the BZFlag project has been to integrate with an existing rendering engine, in order to improve graphics capabilities. This project seeks to utilize the benefits of Crystal Space as a game engine in order to improve the BZFlag project, and make it extensible for future enhancements using Crystal Space.

== Benefits to the BZFlag Community ==
Integration of BZFlag into the Crystal Space environment will allow for more realistic graphics to be placed into the game. In addition, the community will see the benefit of cleaner, easier to understand code, as well as additional functionality included with Crystal Space as windowing tools and plugins. Since Crystal Space is an application framework, it will be able to handle normal game application details, such as opening windows and drawing user interfaces, without the BZFlag application needing to clutter its code up with these items. Finally, the Crystal Space libraries are designed with speed and real-time gameplay in mind, and optimized for many different platforms, so render times may see a slight increase.

== Deliverables ==
According to [1], several of the integration details for Crystal Space have already been accomplished. This project would seek to build upon these foundations, helping Tupone and [darek] with their integration tasks. Functionality will be added for the radar renderer and debugging capabilities to the BZFlag client. The world element will be completed using Crystal Space, and menu selection will be implemented using Crystal Space's CEGui plugin. Improvements will be made to graphics including: addition of shadows, better shading capabilities, and lightmaps. Finally, additional tasks will be taken on as needed and assigned by the mentors and community. Since the Crystal Space integration project is ongoing, and is a project not limited to a single developer, much of this could (and probably will) change. The overall goal will be to help make sure that bzflag is integrated well with the Crystal Space engine, so that the power of Crystal Space can be used in the game.

== Functionality Details ==
The focus of what has been done up to now in the Crystal Space integration has focused on reconstructing what is currently available in the 2.0 version of BZFlag, except using Crystal Space. Additional functionality will be added to support better shading and lighting, including shadows. Since Crystal Space has the ability to support more complex graphical operations on a variety of platforms, there are a vast number of opportunities for extension once the initial integration is completed. Thus, the major focus of the project will be to finish the integration of Crystal Space into BZFlag, and achieve what is already available in the 2.0 version.

== Implementation Details ==
Since Crystal Space is a C++ library, the integration will be in C++. Crystal Space's CEgui plugin will be used to re-implement DisplayMenu. World will be redeveloped, entirely created using Crystal Space's format and API. Focus will be first on getting the client using Crystal Space to be as close to the current 2.0 version as possible. Once this is completed, additional features will be added. Playability of the game will be maintained at all times, so when a new feature is to be added to CVS, it will not compromise the ability of others to play the Crystal Space Client branch in CVS. Shading will be addressed, utilizing interfaces in Crystal Space's SCF system. Improvements in overall lighting and effects will be made, as deemed necessary by the mentors. Interface design will be taken into consideration, and it is possible that functionality and/or updated visual aesthetics will be added, as the community feels is necessary. Debugging will be re-implemented, using Crystal Space's bugplug plugin. Finally, the overall design will be reevaluated to determine if CEL can be used as an additional layer to improve object-oriented design later on.

== Development Methodology ==
The development will proceed according to a flexible iterative software engineering design process. At the beginning of the process, specifications will be designed outlining exactly what will be added, and this functionality will be broken into disjoint sets of functions. The sets will be added to the code, one by one, and then tested and debugged. Once complete, the procedure will move to the next set of functions to be added, until there are none remaining. Once this process is complete, the entire system will be tested rigorously, and submitted to the community for an initial evaluation. Any final bugs will then be eliminated from the system-wide test before final release of the code. At each stage, complete documentation on how each function works, the design considerations, and possible avenues for future work will be written and added to the BZFlag wiki.

== Project Schedule ==
The first task will be to integrate the bugplug plugin, in order to facilitate debugging of other items of the code. When this is complete and tested, the functionality will be broken into iterations as described in the development methodology. Implementation, testing/debugging, and documentation will take up the largest portion of the project, and is estimated to take roughly 1.5 months. Once complete, the project will be delivered to the BZFlag community for evaluation and initial recommendations. Final testing and debugging will then be done before final submission to Google. The initial project schedule will be:

* May 28 - Jun 10: Integration of bugplug
* Jun 11 - Jun 16: Development of Specifications
* Jun 17 - Jul 25: Implementation of Specified Functionality
* Jul 26 - Aug 1: System-Wide Debugging, Initial Release
* Aug 2 - Aug 13: Final Debugging
* Aug 14 - Aug 19 Final Code Documentation and Code Polishing
* Aug 20: Final Release to Google and Community

It is possible that this schedule will change, due to the nature of the project. As was previously stated, some of the code has already been developed for this integration, and I would be working as a member of a team in order to ensure its completion by the end of the summer. Thus, there may be situations where a patch or feature will need to be added which wasn't described in this project outline. The schedule is definitely flexible and open to change.

== Bio ==
I am currently attending the University of Minnesota as a PhD student in the Computer Science department. My specialization/research area is in Graphics and Visualization. I have roughly 4 years experience working with Computer Graphics. I have 10+ years of experience working with C/C++ programming, and have a passion for software engineering, especially when it comes to games and other entertainment software. I am an advocate of open source software, because I believe it gives inexperienced software engineers the chance to work with those who have had years of prior experience in design, development, and debugging of code which they would not otherwise have had. In my free time I enjoy playing the violin and practicing martial arts.

== References ==
[1] http://my.bzflag.org/w/Google_Summer_of_Code#Graphics_Engine_Integration

Web Services/Home Page

2025-12-15T05:00:08Z

Zehra: Zehra moved page Web Services/Home Page to Web Services: Home Page: standardize a layout for pages and content

#REDIRECT [[Web Services: Home Page]]

Web Services: Home Page

2025-12-15T05:00:08Z

Zehra: Zehra moved page Web Services/Home Page to Web Services: Home Page: standardize a layout for pages and content

{{DesignDocument}}

==Overview==

The current website while functional' does not do a good job of showing game and community activity. It as also not very friendly to new users.

This document will be used to lay out the requirements and design of a possible replacement site. No coding should be done until the design is accepted.

==Requirements==
===Functional===

* Have a news section and show the latest news to users in the main page, (dev blog?)
* RSS feeds for releases and news
* Have some kind if announcement/warning system
* Show current player / server count and maybe the top 5 players online now.
* Download link to correct version for browser
* Links to community sites
* Registration / or registration help
* Normal self promotion ( screenshots, reviews, description,history)
* Links / display of store items
* Active forum topics
* Links to dev pages, helping out, roadmap, etc...
* Show "preview release" for beta versions
* Links to docs and help
* Webchat?

===Operational===
* Lightweight, most hit site
* Secure
* Translateable?

==Optional/Extended Features==

These features don't have to
* User manager
* Group manager
* Server key manager
* Display of push stats data
* Common league pages with front page announcement of events/ league news

==Design==
===Focus===
The design should be focused on the following qualities of bz;
* Free to play
* Great Community
* Play now with your friends
* Online play
* Challenge of real people

The main idea to pass across is that the player is joining a community not just getting a single player game. Bz is not the best looking game in the world so large in-game visuals are not the most helpful. The main thing people are going to do is hit the main page and then download the game to try it. They should be able to learn everything they need to start the game from the main page or the download page. This means it has to have text info on it, not just icons. The main page is not a 'splash' page that's you have to click past. Navigation for more information can require a click but it should aways be for expansion of a topic or idea.

Layout should not assume full screen browser and probably work in an 800 x 600 window. Dynamic width is preferred.

The web site itself doesn't need to have That many pages as most of the content is links to other places, forums, wiki, SF, etc....
The web code should not duplicate the features of any other site or service if possible. When snippits of other sections are needed they should Be pulled for a clean API.

==Website Managers==
Blast007 and JoeVano should be considered the website/services management team and have aproval of all code/frameworks that are used.

Web Services/Player Portal

2025-12-15T04:59:42Z

Zehra: Zehra moved page Web Services/Player Portal to Web Services: Player Portal: standardize a layout for pages and content

#REDIRECT [[Web Services: Player Portal]]

Web Services: Player Portal

2025-12-15T04:59:42Z

Zehra: Zehra moved page Web Services/Player Portal to Web Services: Player Portal: standardize a layout for pages and content

{{DesignDocument}}

==Overview==

The Player Portal will consist of user management, group management, and server key management. It will also contain the weblogin page. It may or may not be secured via SSL.

==Design Overview==

* Player portal
** User management
*** Registration
*** User profile
*** Enable various other services (forum, wiki, API)
** Weblogin System
** Group management
*** Create/modify/remove groups
*** View where groups are being used (?)
*** View group membership
** Server key management

==Detailed Objective==

This section will detail the expected final product in the ideal implementation. This may, of course, need to change in the future to accommodate limitations.

===User Management===

From this area, new users will be able to register global accounts for use in the game and with the various web services. The registration will require a unique email address, a password, and the first game callsign. Additionally, it needs to handle COPPA for users under the age of 13. Registration will be protected via at least one anti-spam system, such as KeyCAPTCHA, a question, and DNSBLs.

It will be possible to update the user's email, password, and callsigns using the user portal. Some operations, such as changing the email address, will require that the user confirm the request before it will be applied. In the case of changing the email, this will make it less likely that a user will change their email incorrectly and lose access to their account.

It will also be possible to enable other services and have them be tied to this global account. For instance, the user could enable a forum or wiki account. Once an additional service is enabled, it would not be possible to disable. If the user profile is updated, any associated data in the enabled web services will be updated as well.

This area will also contain the weblogin system. Currently we allow users to enable automatic logins for a specific host. However, we do not provide a way to remove this automatic login. Users currently have to manually delete the cookie that we create. In this player portal, the user should be able to control automatic logins and remove them if they wish.

===Group Management===

Groups are used primarily for assigning user rights to specific users in-game. They are also used by various web services when checking a token generated from weblogin.

Group names consist of two parts. The format is ORGANIZATION.GROUP with the period separating the two parts. There will be two or three reserved organizations. The DEVELOPERS organization is reserved for official BZFlag developers. The LOCAL organization is reserved for local groups on individual servers. This organization cannot be managed through the web interface. The last one that may be reserved is the BZFLAG organization. However, there is already several groups that are using that namespace, so that would have to be worked out with the owner of those groups.

The organization will be registered first and will then be reserved for use by that user. The user that registers a organization will be the '''founder''' of that organization. They can add additional '''co-founders''' or even transfer the founder right to another user.

Once an organization is registered, groups can be created within the organization. These will be created by the founder or co-founders. Once created, each group can be assigned one or more '''managers''' that will be able to add or remove users from the groups.

There will be various options for each group which the founders can modify. The founders can rename the group, add a description, and delete a group. There will also be a visibility setting and a setting to control how users can join the group.

For the visibility setting, there will be two options: public, protected, and private. If the group is public, anyone can see the group and the member list. If the group is protected, anyone can see the group, but only members can see the member list. If the group is private, only members can see the group and the member list.

There will also be settings to control how users can be added to or removed from the group. For this, there will be three modes: open, request, and closed. If the group is set to open, users can join or leave the group without any interaction from the organization founders or the group managers. The request mode requires users to request to be added to a group, but they can leave or cancel their request at any time. The founders or managers can approve or deny the user's request. The last mode is closed, which allows only the founders or managers to add or remove users from the group.

This may differ slightly from the original plan for the [[Group Management System]].

===Server Key Management===

Starting with BZFlag 3.0.0 (technically, with 2.99.x) and 2.4.x, a list server key is required to host a server on the official server list. Typically, the owner of the server will generate this key. Keys are tied to a hostname or an IP address. The website will provide management for these keys. A registered user can create new keys and delete existing keys.

There is more information on the [[Server authentication]] wiki page.

==Planned Milestones==

In order to complete this section of the web services, a number of things need to happen. It is infeasible to complete them all at once, so a gradual process is expected. These milestones will be fleshed out a bit more later.

===Milestone 1 - Planning and Design===

Goals:
* Determine the data that will be stored
* Describe any specific restrictions or limitations that should be in place
* Create a complete set of database schema for all areas of the portal
* Determine the kind of queries that will be run and plan indexes and other optimizations as needed.

It should be determined what data needs to be stored, how it references other data, and what kind of data is necessary to integrate with systems such as MediaWiki and phpBB3. There should be some planning for the future to reduce the likelihood/necessity of major database structure changes later. For instance, we should ensure that IPv4 and IPv6 addresses can be stored in any area that tracks IP addresses. PostgreSQL supports storing network addresses, so that may be something to look into. We should also have any restrictions (such as limiting the characters and length of callsigns) clearly defined. This will enable us to create a consistent experience across all web services and in the game itself.

The schema we generate should be database agnostic as it is not yet known what data will be stored in what database. It may be MySQL, OpenLDAP, a mix of the two, or some other database that we have not tried yet (such as PostgreSQL).

We should also determine the types of queries that will be run in order to determine ways to optimize performance. For instance, we will be looking up a specific user by callsign quite often. So it would make sense to have an index on the callsign.

Of course, it's not possible to think of everything right away, so it's inevitable that we will have to make some changes later.

===Milestone 2 - Weblogin and Server Authentication===

Goals:
* Migrate the server authentication key system
* Migrate the weblogin system

The easiest thing to migrate over is the server key management system and weblogin. These items are not tied in to many other areas like groups and registration are.

The server key management code is currently in SVN under [http://bzflag.svn.sourceforge.net/viewvc/bzflag/trunk/web/listkeymgr/ /trunk/web/listkeymgr]. Parts of this code could be adapted or used with the player portal. This will still need to integrate with the existing list server (or vice versa) until the list server is heavily updated or rewritten.

The weblogin system will just be the current weblogin.php script. This may retain the same visual look or we may integrate the look into the rest of the website. A long term goal is to have all our web services have the same visual look.

===Milestone 3 - Group Management===

Goals:
* Create the group management system
* Migrate the organizations/groups from the forum into the new group management system

...

===Milestone 4 - Registration===

Goals:
* Create the registration system
* Allow users to modify their profile from the player portal
* Enable activation of a forum account

...

===Milestone 5 - ...===

...

AptRepo

2025-12-15T04:04:14Z

Zehra: I think we already got there, so redirect to main page for now

#REDIRECT [[Main Page]]

Map FAQ

2025-12-15T04:01:42Z

Zehra: merged content into Map making

#REDIRECT [[Map making]]

Map making

2025-12-15T04:00:57Z

Zehra: redirected Map FAQ and merged page contents here

BZFlag uses its own map file format, [[BZW]] (BZ World). BZW files are text based and contain a list of objects and map options that are read by the [[BZFS]] server. There is a [[Map FAQ]] that deals with several frequently asked map making questions.

==Map Creation Methods==
BZFlag has several well practiced methods for the design of maps, from simple text editing, custom editors, to exporters for 3D modeling software. While basic dedicated map editors, such as BZEdit, can often only create simple objects, 3D modeling software can create complex custom [[mesh]] objects, but have a much steeper learning curve.

===Dedicated Map editors===
Dedicated BZFlag map editors (i.e. written specifically for graphically editing BZW files) generally go by the name BZEdit. There are a number of versions of BZEdit that have been developed over the years. Each editor has its own level of support for various map features. At this time there is no custom editor that supports every feature of the BZW format. In general, these will only support simple version 1.10 objects, like boxes, pyramids, bases, and teleporters.

Editors supporting BZW 1.10 features:
*[[BZEdit]]
*[[BZEditWin32]]
*[[BZFed]]

Editors supporting some BZW 2.0 features.
*[[iBZEdit]]
*[[pyBZEdit]]

===Non-dedicated editors===
Technically, you can use any 3D modeling package that can export to .obj format. You can then either use [[modeltool]] or Wings3D to convert that file to BZW format.

====Blender====
The [http://www.blender.org/ blender] 3D modeling application features a plug-in called [[BZWTools]], which enables blender to read and write the BZW file format and to create BZW specific objects. Tutorials on using blender (not specific to BZFlag) can be found on the [http://www.blender.org/tutorials-help/tutorials/ blender web tutorials] pages.

Mostly, though, it is easier to use blender, scale your map correctly (there are four default blender units to two [[World units]]. Then run the [[modeltool]] to convert it. Note that exporting from blender default obj will have the whole model tilted -90 0 0.

====Wings 3D====
[http://www.wings3d.com/ Wings 3D] is a good modeler to use if you're new modeling. It has a much smaller learning curve than Blender, although it doesn't have as many features. [[Wings3D]] allows you to export wings objects to a BZW file. Tutorials on using wings (not specific to BZFlag) can be found on the [http://www.wings3d.com/tutorials.php wings web tutorials] pages, as well as a useful tutorial on [http://www.geocities.com/peterchov/BarrelUV.html UV mapping]

====Getting Maps In .obj Format====
It is not widely known that you can export a bzflag map from the actual bzflag client in .obj format. To do so, you must connect to a server hosting the BZW map you would like to download and type ''/saveworld -o "mapname.obj"''. This will allow you to then import the .obj file into a modeler and edit the map.

===Creating BZW files via scripting or programming===
Writing programs to output map files can be a very effective and efficient way of creating maps. One may, for instance, use variables to represent key heights or distances within maps (so that, for example, anyone at a given level may shoot someone at the same level), or to create composites based on collections of basic objects, co-located programmatically. Basic objects may be stretched/scaled to fit specific spaces; they may be programmatically varied in texture, color, and position; software may (internally) represent objects and work with them so that they don't collide or overlap. AI-based software may compose maps based on specific design principles, aiming for particular play styles or tactical challenges.

The core of software map generation is the creation of the basic BZFlag elements, whether the simple boxes, pyramids, etc., or complete meshes, by outputting map element statements to a file. The objects are typically output as sequences of text strings to a .bzw model file, which may then be read by the bzfs server. While simple objects may be fairly easily edited by hand, more complex objects, such as meshes, are more readily generated by software.

Mesh generation, while it may be done with Blender, etc., as above, may be done equally as well by constructing programs to output the faces required within a mesh. For example, a program may take a curve and spin it about an axis to create a 3D surface (a sort of "lathe" in the virtual world), outputting faces at each increment of rotation. Hand-written scripting software may fit irregular polygons together, defining a sequence of mesh objects that seamlessly create, for example a roadway. Writing such software usually requires very careful testing to guarantee that the bzfs server interprets the objects as the author intends.

Software map creation provides the map maker with the ability to customize objects in detail, such as whether the faces of the object allow bullets or tanks to pass, or the level of transparency to assign to any specific face, at a level of detail often hard to achieve within other 3D modeling tools. Abstractions within map generation software are often defined to create basic tactically-relevant map elements - these then may be scaled, shifted, textured, or otherwise modified to fit a particular designer's tastes or constraints.

The disadvantages in using this are that the underlying representation of the work is not available directly from the map file. The underlying intended abstractions are missing because only the resulting object primitives are in the generated map file, and there is no straightforward way to recover this (though software may be used to parse existing map files with the goal of augmenting them). This lack of directly-accessible abstraction is of course true of any tool used to generate a map, there being no standard way to encode this within a .bzw file.

===Map making by Hand===
The last method of creating maps is simply coding them by hand as text files using the raw BZW structures. This is still one of the most common ways that people create and edit maps, and can be very fun and challenging. This is easily done in any text editor, for example NotePad on Windows, and TextEdit on Mac OS X.

Most maps made by hand tend to be fairly simple, though experienced mappers have made some extraordinary maps in this way. The reason for the popularity of the "hand made" approach is partly because of the simple structure of the BZW code, but also the fact that, until recently, there were no graphical editors available for operating systems like Mac OS X. A detailed explanation about creating a map by hand can be found on the [[Map making by Hand]] page.

Maps that contain 2.0 objects (such as [[mesh]]) tend to have been either completely made in a text editor, or partly modeled in 3D modeling software, and later manipulated in text format.

This page is an aim at answering some frequently asked questions regarding map creation, and to help people new to mapping.

==Common Misconceptions==
First off let's clear up some common terms and misconceptions:

• The word '''"map"''' is not synonymous to the word '''"server"'''. They are different things. A map is run on a server.

• When we say 'server' we mean 'BZFS', the BZFlag server application that comes with every stable binary release of BZFlag. BZFS allows you to host a BZFlag game, with either a randomly generated map, or a custom map.

• The standard extension for a BZFlag map is ".bzw". There are a variety of ways for making maps, and this can be done on any platform [[BZFlag]] runs on.

• You will often hear the different types of map objects referred to by the first version of [[BZFS]] they appeared in. "1.x" objects are simple boxes, pyramids and teleporters. "2.0" or "2.x" objects are objects such as [[mesh|meshes]], [[arc|arcs]], [[material|materials]], etc. With skill, these can be textured to look like almost anything you want.

• Textures '''must''' be in the .png format.

• Team numbering occurs frequently in BZW. Each team is given a number, and these are as follows: 0 = rogue; 1 = red; 2 = green; 3 = blue; 4 = purple.

• '''Think carefully about the layout of your map: Is it going to be fun to play?''' This is a factor that many people call 'playability'. This is probably the most important thing for a map that is intended to be played on. It may seem obvious, but you'd be surprised at the number of maps that are either too full of eye candy, or just badly thought out. You want to think about, among other things, distribution of obstacles, how balanced it is for CTF, concentration of ricochet bullets and sloped surfaces to rebound lasers.

==Frequently Asked Questions==

===How Do I Make a Map/World for BZFlag?===
'''There are many ways to do this:'''

• You can use a dedicated map editor such as [[BZEdit]], [[iBZEdit]] or [[BZFed]]. In general, dedicated editors will only support simple map objects such as a box, a pyramid or a teleporter, and there are none in active development. On the whole, this is the easiest way to create maps for most people. See [[Category:Map_Making]] for more.

• You can use a 3D modeling application, such as Blender or Wings3D. There are plugins available for each. With a 3D modeler, you can create much more complex maps, but there is a much steeper learning curve.
The blender plugin, [[BZWTools]], can be found [http://my.bzflag.org/bb/viewtopic.php?t=5862 here].
The wings plugin can be found [http://my.bzflag.org/bb/viewtopic.php?t=3652 here].

• Lastly, you can edit maps by hand in your favorite plain text editor. Most maps made by hand tend to be fairly simple, though experienced mappers have made some extraordinary maps in this way. It is a good idea to be familiar with the structure of BZW code, as often exported meshes from 3D modelers will require 'touching up' in a text editor. Even the most experienced 3D modeler user needs to know how to text edit.

===Making 2.0 Objects===
'''How do I make a cylinder/cone/sphere etc.?'''

You can't do it in BZEdit. You will need to add them by hand in a text editor.

See [[Category:Map_Making]] and [[BZW]] for more in depth info.

===Adding Textures===
'''I created a map in BZEdit, how do I add my own colors and textures?'''

BZEdit will '''not''' create colored, complex objects. If you want to texture a map made in bzedit, you will need to do so in a text editor such as NotePad. You must change the boxes you want texturing to meshboxes, and define your textures with the [[material]] object.

'''Where can I host textures that I have made for my map?'''

BZFlag offers a free texture hosting service at http://images.bzflag.org . To qualify to be hosted, you need to own the rights to use those textures (i.e. you made it, or you have permission to use it from the creator).
You can submit images via the [http://images.bzflag.org/submitimages submissions page], and they will be moderated. Be patient - the moderation can take some time. Remember - this service is a privilege, not a right.

===Moving Objects===
'''Can I make moving objects in BZFlag?'''

The short answer is no, and there probably never will be moving objects that tanks can interact with. You can, however make moving textures with the textureMatrix object.

The long answer is yes, simple moving objects have been made that move in a circle around the central Z axis using a method of mesh drawing called DrawInfo, however these objects are always shootthrough and drivethrough, and tanks cannot interact with them in any way - in other words decorative only. The DrawInfo code was never fully documented, but is relatively easy to generate using [[modeltool]]. If you can make an object in wavefront.obj format, you can make drawinfo.

===BZEdit For Mac OS X===
'''Can I get BZEdit for Mac OS X?'''

Yes, it's called [[iBZEdit]]
Alternatively, you could use Wings 3D, or Blender if you're prepared for a steep learning curve - or you could go for plain text editing in the TextEdit application that came with your OS.

===Flag and Tank Spawns===
'''How can I get a flag to spawn in a specific place in my map?'''

Use the following simple code:
zone
size 0.1 0.1 0.1 ## Size of the zone
pos 0 0 0 ## Position of the zone (i.e. the place it will spawn)
zoneflag GM 2 ## For example, this will create two GM flags.
end
Note this does '''not''' require you to use the +f bzfs option. If you use zoneflag, the flag will be created automaticaly.

'''How can I get a tank to spawn in a specific place in my map?'''

Use the following simple code:
zone
size 10 10 10 ## Size of the zone
pos 0 0 0 ## Position of the zone (i.e. the place it will spawn)
team 0 1 2 3 4 ## Every team will spawn here..
end
Next to 'team' you put the numbers of the teams you wish to spawn. See above for more details.

===Death Physics===
'''I want tanks to die when a tank touches this box... How?'''

You can create boxes that kill tanks when they are touched by using a [[physics|physics driver]]. A physics driver can be applied to any 2.0 object. Specifically, we need the 'death' function.
physics
name myDeath ## Name of physics driver.
death You Died! ## Message displayed on death.
end
Then you add the reference to the object or mesh face:
phydrv myDeath

===World Weapons===
'''How do I add automatically-shooting weapons in my map?'''

See [[Weapon (object)|World Weapon]]. You can configure the weapon to fire on a flag capture, like on all your favorite CTF servers.

===Starting a Server===
'''How do I start a server to host my map?'''

http://my.bzflag.org/bb/viewtopic.php?t=2915

[[BZFS]]

==Getting Your Map Out There==
There is a forum dedicated entirely to this on the [http://my.bzflag.org/bb BZBB]. It's the 'Map Releases' forum. Please bear the following in mind when you release your map.

• '''Releasing you map does not necessarily mean you will get hosting for your map''', so do not post "OMGZ this map is sooo good i spent like 2 hours making it and it's like amazing all my friends think it rawks!!!!!!11". It's not going appeal to many people. Instead give about a paragraph to describe your map, and any server settings you may recommend for playing. Be sure to use full sentences, and check your spelling!

• Extensions, extensions: you should always give your map the '.bzw' file extension, text edited or otherwise. It dosn't matter what you made it in - it's all the same format. It's just good practice.

• '''Give your map an imaginative name''' - not just "xyz's CTF", and not something obvious like "Bridges" or "Castles", as there are probably about five other maps with this title. Instead think of something decriptive and short. Think as though you were titling a movie or a song, something that's going to be attractive to people browsing the forum or listserver.

• Take nice screenshots using the roaming feature in observer mode. Most people will use only the screenshots to get an idea of how well your map will actually play. Try to capture the essence of your map with as little screenshots as possible, no more than three or four, and (if you can) convert your images to JPEGs for faster downloading.

• Furthermore, '''releasing your map means that anyone can download your map.''' If they decide to host your map they don't have to make you an admin on their server. If you have any issues with the way they are using your map take it up with them personally. It's not up for public discussion. See [http://my.bzflag.org/bb/viewtopic.php?t=10575 this announcement] for more information on releasing and licencing in this forum.

• Be open and ready for criticism - if you're new to mapping, the chances are that your map isn't going to be a smash hit, so don't be too offended if somebody doesn't like it. Instead take that criticism on board and use it to improve your map, or to make further maps better.

==Getting Help==
'''If you're looking for some further help with BZW, you can post a question on the BZBB forum, or you can always try the ##bzw IRC channel on irc.freenode.net. Make sure you've searched this Wiki thoroughly first - probably 80% of issues can be resolved with information from this site.'''

'''Lastly, have fun making maps. Many players enjoy mapping even more than actually playing the game, and find it an ammusing and challenging passtime. Just remember to persevere, and with some work, you could be the next Dutchrai or Louman!'''

==See also==
===Map Editors===
{| class="wikitable" style="margin-right: auto; margin-left: 0px;"
| [[BZEdit]]
| [[BZEditWin32]]
| [[BZFed]]
| [[BZWTools]]
| [[DI-Machine]]
|-
| [[IBZEdit]]
| [[Modeltool]]
| [[PyBZEdit]]
| [[Wings3D]]
|
|}

===Map Objects===
{{Template:Map objects}}

===Helpful links===
* [[Comparison of map editors]]
* [[Comparison of map objects]]
* [[Map FAQ]]
* [[Map making by Hand]]
* [[Texturing how to]]
* [[World units]]

[[Category:Map Making]]

BZFlag README

2025-12-15T03:58:32Z

Zehra: update bzflag readme to bzflag 2.4.30

<pre>
BZFlag 2.4.30
https://BZFlag.org/
Copyright (c) 1993-2025 Tim Riker

BZFlag is an Open Source OpenGL multiplayer multiplatform Battle Zone
capture the Flag game. At its heart, the game is a 3D first person
tank simulation where opposing teams battle for dominance. The game
was originally written for SGI computers running Irix, but now runs
and is actively maintained on Windows, Linux, Mac OS X, and other
platforms.

BZFlag may be redistributed under either the LGPL or MPL licenses.

This is the BZFlag README file. This file includes introductory build
instructions, user community interaction references, information for
getting involved in BZFlag development, a manifest of the source code
layout, basic usage expectations, contact information, and more.

Table of Contents
=================
Introduction
Table of Contents
Obtaining BZFlag
Compiling and Installation
Short Version
Long Version
Communication
Internet Relay Chat
Forums
Bug Reports and Support
Providing Contributions
Source Tree Organization
Public Internet Servers and the "list server"
Notes on "CHEAT" servers and network abuse
Project History and Contributions
Contact

Obtaining BZFlag
================

Main BZFlag Website: http://BZFlag.org
BZFlag Github Site: https://github.com/BZFlag-Dev/bzflag

The main BZFlag website provides access to most all of the resources
available for the game. The binary and source distributions of BZFlag
are, however, provided on the GitHub project site. Compiled versions
are distributed as installable packages, disk images, and more, with
details varying depending on the platform. Source code distributions
are provided and archived in various formats as well. See the project
site for the download links.

BZFlag is also available directly from GitHub. To obtain BZFlag from
git, a bit more familiarity with software development is expected.
If you're familiar enough, anonymous GIT access is provided from the
repository:

https://github.com/BZFlag-Dev/bzflag.git

Compiling and Installation
==========================

To compile a playable BZFlag, the following steps should get you up
and running quickly if everything external to BZFlag is properly
installed:

./autogen.sh
./configure
make
./src/bzflag/bzflag

If configure detected everything it needed to build the BZFlag client,
after make the client will be sitting in src/bzflag as 'bzflag'. The
game can be run from there, though you will probably want to "sudo
make install" or otherwise become a privileged user and install the
game properly for your system.

If you're building on a platform that has a README.* file, you should
consult that file as they usually contain additional instructions or
details specific for building on that platform. There are often hints
for common problems specific to those platforms as well.

The Longer Version:

To build sources directly from a git clone you need to create a
configure script. You can skip this step if you grab a distribution of
BZFlag that already has a ./configure script in it, such as from a
source distribution tarball. To generate the configure script, you
need to run the provided autogen.sh script:

./autogen.sh

The script will report whether sufficient versions of the GNU Build
System tools (i.e. autoconf, automake, and libtool) that were detected
and if successful, a configure script will be generated. If the
script fails, submit a report to the developers containing the output
of "sh autogen.sh -v". This will run autogen.sh in verbose mode. One
of the most common failures is having insufficient versions or
mismatched combinations of the GNU Build System tools, so make sure
your tools are recent.

If the previous step was successful you now have a script for
configuring BZFlag. This command:

./configure --help

will list the variety of configuration options. The script adapts
well to various system configurations, so it may be enough to simply
run it as:

./configure

You may want to create a 'work' directory and configure from there to
have all the build products and binary executables get placed in a
directory separate from the sources. To do this, simply create a
directory then run configure and make from there instead.

After configure completes, it will report whether all the requisite
packages were found that it needs in order to build the client and the
server. The client is reliant upon the following external
dependencies that should be installed before running configure:

OpenGL 1.0+
libSDL 1.2+

If you're on an operating system that uses a packaging system
(e.g. apt, portage, ports, etc), be sure to install the development
kit versions of each of those (e.g. xlibmesa-gl-dev package) so that
headers are made available. You may also want to manually install
other dependencies that BZFlag automatically provides if you do not
have them pre-installed:

c-ares
libCURL
libregex (usually provided as part of libc)
zlib

The README.Linux file includes a detailed list of of the packages
needed to compile and run BZFlag on some popular Linux distributions.

The final summary at the end of running configure will report whether
the client will be built or not. Once configure has been run, you may
compile by simply running 'make'. If you have GNU Make and are on a
multiprocessor system, you can build in parallel with the -j option:

make -j4

If compilation was successful, the client will be in src/bzflag and
the server will be in src/bzfs as 'bzflag' and 'bzfs' respectively.
You can run the client or the server directly from those locations
with or without installing:

src/bzflag/bzflag

BZFlag looks for data files in a path defined during compile, in
./data/ , or in the previously specified data path only. As part of
the tarball/git clone, the base data library is located in
<installed-locale>/bzflag/data. This means that to test in a working
directory you need to tell bzflag where to find these files if there
is not a 'data' directory in your current directory. This can be done
with a symbolic link:

ln -s ./path/to/bzflag/data

After testing you can install BZFlag by running 'make install' with
sufficient system installation privileges. Use 'sudo', 'su', or
similar methods to elevate your privileges when installing BZFlag
system-wide:

sudo make install

You should now have BZFlag in the system directory ready to run.

If you do not have admin privileges on your platform, you can install
files in a directory that you own; for this to work, you have to
append to the configure command the prefix option:

./configure --prefix=YourHomeDirectoryHere

You will then be able to perform a "make install" without needing to
elevate your privileges, and all bzflag executable files will be
installed in the subdir bin of the specified path.

For additional information on installing, see INSTALL file.

Again, some platforms may be different. See the README file
appropriate to your system for more information.

You can also build an installable package using:

make package

The package will be placed in ./dist; the exact form of the package
depends on the platform.

There are three cleanup targets: clean, distclean, and
maintainer-clean.

`make clean' removes intermediate files but leaves bzflag and other
programs and any man pages.

`make distclean' removes everything clean does and also programs and
man pages. This should get things back to a tarball state.

`make maintainer-clean' removes everything distclean does and also
packages, directories created during the build, and the platform
configuration; this should get the source tree back to its state in
the Git repository.

To build BZFlag for an unsupported platform, see PORTING.

The ./configure script has a number of build options that you may find
interesting.

Communication
=============

The BZFlag project has several resources set up for communicating both
with other developers and with the community. There is an IRC
channel and forums.

Internet Relay Chat
-------------------
Most of the BZFlag development activity and discussions occur over
IRC. Join the #bzflag IRC channel on the Libera.Chat network
(irc.libera.chat, TLS port 6697) to get involved.

See https://web.libera.chat/ for a web based interface for
first-time users. Individuals that intend to stay in the channel are
expected to get a non-web-based IRC client. See http://irchelp.org or
search the web for IRC clients for your operating system.

Forums
---------------
There are extensive and active forums used by players, server
operators, administrators, and others available here:

https://forums.bzflag.org

Registering an account on the forums presently also registers your callsign
for use inside of BZFlag. Some servers require registration in order to
play. See the Getting Started page on our site for more about registration.

Bug Reports and Support
=======================

For reporting bugs and unexpected behavior, please go to BZFlag bug
tracking system at:

https://github.com/BZFlag-Dev/bzflag/issues

If you require assistance with some issue, please visit the BZFlag
IRC channel at #bzflag at irc.libera.chat

Alternatively, discussion forums are also available for resolving issues.

Providing Contributions
=======================

Pull Requests should be entered submitted via the GitHub pull system:

https://github.com/BZFlag-Dev/bzflag/pulls

Contributions are gladly accepted for modifications that do not
affect the core gameplay. Interacting with the other developers in
the IRC channel is recommended for any changes which will affect
gameplay.

Source Tree Organization
========================

After unpacking a source distribution, you should have at least the
following files in the new 'bzflag' directory:

README - this file
README.* - platform specific details
AUTHORS - project contributors
COPYING - the license for BZFlag
ChangeLog - source code changes since previous release
DEVINFO - information for developers
NEWS - history of visible changes for each release
PORTING - a guide for porting BZFlag
autogen.sh - build system preparation script
configure.ac - build system configuration script template
data/ - data files (sounds, images, etc.)
include/ - include headers for libraries
man/ - man pages
misc/ - miscellaneous goo
MSVC/ - stuff for building on the Windows platform
package/ - stuff to build installable packages
plugins/ - bzfs plugins
src/ - bzflag, bzfs, etc. source code
3D/ - 3D code including texture manager
bzadmin/ - bzadmin app source code (text admin/chat client)
bzflag/ - bzflag app source code (game client)
bzfs/ - bzfs app source code (game server)
common/ - general purpose classes
date/ - unified version and build date stamping for apps
game/ - game library used by both the server and client(s)
geometry/ - geometry rendering classes
mediafile/ - classes for reading resources
net/ - networking classes and functions
obstacle/ - collision detection stuff
ogl/ - OpenGL utility classes
platform/ - platform dependent code
scene/ - high level rendering algorithms
tools/ - various helper utilities
Xcode - Mac OS X Xcode project and associated files

Note that include/ does not have all the include files. If a header
is used entirely within a library (i.e. it doesn't directly provide
functionality outside the library) then the header is found in the
library's directory under src/. An include file goes in include/ only
if it's required by another library or libraries or executables.
While this complicates locating a header file (it can be in one of two
places instead of just one place), you can instantly tell if a header
file is (can be) used by clients of the library.

Public Internet Servers and the "list server"
=============================================

The bzflag project offers a public server listing service that allows
players to find servers to play on. This service is run for the
benefit of the project. As of Version 2.4, BZFlag servers that wish to
be listed on the public list server must provide an authentication key
that ties the server to a specific global user. This is done to
provide contact information for players and project
staff. Authentication keys are automatically generated at
https://my.bzflag.org/listkeys/

Notes on "CHEAT" servers and network abuse
==========================================

While the license for BZFlag certainly allows users to run any server
modification that they wish or to modify the code in any way, we ask
that people do not publish or host "cheat" clients or servers to the
general public for use. We also expect that users will abide by basic
usage guidelines of reasonable and tolerable behavior that are not
detrimental to the game's heritage of a fun gaming environment for
all.

We understand the desire to expand, modify, and improve the game and
its sources including the ability to test out new features publicly.
These modified clients and servers generally provide some advantage
over unmodified clients and are generally discouraged for widespread
use. As such, we ask that anyone wishing to host or otherwise
participate in a game that involves a modified client or server to
register under a different network protocol than the current public
release by modifying BZ_PROTO_VERSION in the src/date/buildDate.cxx
file. This will let modified games be played and prevent modified
clients from being used on public unmodified servers.

Any individuals that are found to be contributing to abuse of the
public services being provided may be subject to bans or other access
restrictions. Abuse generally consists of any disruption to one of
BZFlag's network services including denial of service attacks,
spamming of BZFlag web sites or servers, disruptive gameplay on
multiple public servers, intrusion attempts, password sniffing, or any
other behavior that is deemed inappropriate.

The BZFlag project administrators reserve the right to remove public
listings of any game servers for any reason whatsoever, including
removal of servers or banning of individuals that do not follow this
request. Similarly, the BZFlag project administrators also reserve
the right to limit access or otherwise block any players from public
service access at any time. These actions may include the suspension
or removal of global accounts and limiting access to the web site
services including web site services, list server access, forum access,
and any league resources.

In general, the entire network is provided by the community for the
community as an entirely volunteer and contributed effort. We ask
that all players recognize and respect the time, effort, and resources
involved and that we're all generally here to have a good time.

Project History and Contributions
=================================

BZFlag was primarily originally authored by Chris Schoeneman
<crs23@bigfoot.com> in the early 1990's. After several years of
development, Chris turned over copyright and maintainership of the
game to Tim Riker.

BZFlag continues today to be maintained and developed by the Open
Source community by a project administration team with contributions coming
in from all over the world. See the AUTHORS file for more details on
contributions to the project.

Contact
=======

Any of the core developers listed in the AUTHORS file are generally
receptive to being contacted for most matters relating to the game.
Internet Relay Chat (IRC) or e-mail is generally the expected method
of interaction with IRC being generally preferred. The project
maintainer Tim Riker <Tim@Rikers.org> is available for most legal matters,
but day to day development is handled by the Project Administrators:

Scott Wichser (blast007) <blast007@users.sourceforge.net>
Jeff Makey (BulletCatcher) <bullet_catcher@users.sourceforge.net>

Happy Shooting!
The BZFlag Development Team
</pre>

BZWGen revisited

2025-12-15T03:53:00Z

Zehra: Zehra moved page BZWGen revisited to GSoC: BZWGen revisited: making GSoC projects and proposals more consistent with '''GSoC''' prefix

#REDIRECT [[GSoC: BZWGen revisited]]

GSoC: BZWGen revisited

2025-12-15T03:53:00Z

Zehra: Zehra moved page BZWGen revisited to GSoC: BZWGen revisited: making GSoC projects and proposals more consistent with '''GSoC''' prefix

{{IdeaDesign}}

This is a two part project that aims to address two main issues of BZWGen, accessibility and universality.

Accessibility has been probably the main reason that BZWGen didn't get much attention -- using the program required downloading a separate program and compiling it's sources, then running it and setting it up to work with bzfs. On the other side, getting the program to produce different results requires the knowledge of a language that however documented is not straightforward for the user.

Universality addresses the fact that BZWGen would more accurately be called now a City Generator, despite the fact that the underlying engine could do much more. Furthermore, some of the ideas I initially had for 2007 were never even touched. The second (bigger) part of this years project would be to present an accessible way for the program to generate a broad choice of outputs.

== Deliverables ==

The aim of the project is to provide a revised version of BZWGen that will work both as a standalone app and a plugin to bzfs. As a side effect, a common protocol will be presented for handling world-generating plugins.

The generator itself will be severely enhanced to provide a much wider array of output, and to allow a first time user to do much customization without the need of reading much documentation. Additionally textures and data files for the extended generator capabilities will be provided as well.

=== Streamlining ===

To pluginize BZWGen a common interface for generators will be established, which will take care of supplying the generator with necessary data. In case of bzfs data will be read from a config file. The existing map generator will then also be pluginized, an in the future, replaced by a config file for BZWGen that ideally mimics it's behavior.

=== Documentation update ===

As the system currently is somewhat mysterious to people, I'd like to provide better documentation on the L-system generator, including an illustrated tutorial on writing your own rules.

=== Config file layer ===

L-systems are hardly transparent for someone not used to them. However I didn't intend them as the main modification tool. Above the low-level L-system layer there should be a lot more readable "template" file layer, that decides what will be generated on a given map zone. What now is treated as command line parameters for BZWG will then be placed in the template file, along with the ability to use different texture sets, and load custom L-system sets.

=== Generation zones ===

The L-system based approach that BZWG uses now is just one of the features I intended for it. To smoothly blend multiple generation tools a system of splitting the map into zones is needed. Each zone will have generation parameters supplied via config files. Zones will be not limited to rectangles as is the case now, but any arbitrary polygon.

=== Road placement algorithm rewrite ===

The current subdivision method will be left intact as an option, but thanks to the custom shaped generation zones, the original intent of the L-system based road placement generator will be implemented. Apart for generating roads it will be able to do a custom territory split of a given map.

=== Extensions ===

Some of the planned extensions to the generator itself are listed below:

* scatter algorithms -- expands on the existing bzfs map generator to allow a finer control on scattering, like the control of scattered objects, control over where objects may be scattered, and control over their size and orientation. Higher level example -- scattering of L-system generated buildings.

* template based building -- a way to control the placement of other generation algorithms -- constructs the map out of a predefined template, where the template parts will be filled with the given generation result, or a preprepared map-tile.

* block-connected building -- the map is build out of pre-prepared chunks of geometry that follow the defined rules for connection. This is the way that map generation works in contemporary 3d RPG games -- dungeons are constructed from preprepared components randomly connected. The approach is suitable for overland structures as well.

* procedural objects -- as time will allow BZWG will be equipped with procedural generators for various real-world objects, for example trees and foliage. Priority is set on items that can be used in the scatter algorithm.

== Project schedule ==

The existing blog ( http://bzflag.chaosforge.org/ ) will be used to report progress. Posts will be made at least twice weekly during the main program timeframe. Having the experience of last year, I hope to organize my time a lot better this year, and get a lot more accomplished.

=== Phase 1 -- May 26 - July 1 ===

==== May 26 - June 15 ====
* bzwgen compiles and works as a plugin for bzfs
* bzwgen's existing codebase is cleaned up
* a detailed schedule and plan for the rest of GSoC is prepared and accepted
* design for the template layer and other promised features
* reevaluation of bzflags collision code
* alternative ruleset/textureset to show the current capabilities

==== June 16 - June 28 ====
* implementation of double-linked graph based network for usage for both the road network algorithm and the new zoning algorithm
* implementation of an alternative ad-hoc non-orthogonal road layout generator and making it work with the existing grammar (especially rewriting zones to be non-quad)

==== June 30 - July 6 ====
* scatter generator
* primitives and custom mesh consolidation
* procedural meshes (extension of grammar if needed)
* reconstructing the existing generator as a compile option

=== Phase 2 -- July 6 - August 11 ===

==== July 6 - July 14 ====
* setting up a test server, promotion on the forum, and outside
* refining the road layout algorithm to be less chaotic, and more realistic
* config file layer

==== July 14 - July 20 ====
* extentending the config file layer with full templating capabilities
* documentation and tutorial for the existing config/template system
* sample interesting template/config files, more media

==== July 21 - July 27 ====
* extension of the grammar system to allow more Mueller-quality buildings (I think I found a solution for that)

==== July 28 - August 3 ====
* block-connected building system based on the mesh import feature
* sample data for both "internal" and "external" effects
* additional template files, and documentation for this and previous weeks features

==== July 4 - August 11 ====
* bringing it all together, and merging with BZFlag core as much as the devs allow

=== Phase 3 -- August 11+ ===

Cleanup time for the GSoC finalization. Once that is done, I hope that there will be some RFE's from the community that I will be happy to implement.

Talk:Webadmin SOC2008

2025-12-15T03:48:16Z

Zehra: Zehra moved page Talk:Webadmin SOC2008 to Talk:GSoC: Webadmin 2008: giving GSoC projects/proposals a GSoC prefix

#REDIRECT [[Talk:GSoC: Webadmin 2008]]

Talk:GSoC: Webadmin 2008

2025-12-15T03:48:16Z

Zehra: Zehra moved page Talk:Webadmin SOC2008 to Talk:GSoC: Webadmin 2008: giving GSoC projects/proposals a GSoC prefix

Flesh out the propsoed features, try to make them as generic as possible. i.e If you allow the editing of a bad words file, you basicly allow the editing of ANY external file, so put it that way. Describe the code section in more detail breaking down the various sections that you will have. Describe the various actions that you plan for controlling the live game. Do you want to do reports, chat, or kicks and bans?
--[[User:JeffM2501|JeffM2501]] 01:07, 22 April 2008 (EDT)

Webadmin SOC2008

2025-12-15T03:48:16Z

Zehra: Zehra moved page Webadmin SOC2008 to GSoC: Webadmin 2008: giving GSoC projects/proposals a GSoC prefix

#REDIRECT [[GSoC: Webadmin 2008]]

GSoC: Webadmin 2008

2025-12-15T03:48:16Z

Zehra: Zehra moved page Webadmin SOC2008 to GSoC: Webadmin 2008: giving GSoC projects/proposals a GSoC prefix

This is [[User:BugQ|bugQ]]'s proposal for [[GSoC]] 2008, which may change with the minds of those involved.

See bugQ's development blog to check and discuss the project's progress: http://planet-soc.com/blog/89

==Overview==
'''webadmin''' will be a web-based control interface for [[BZFS]]. As opposed to the existing Javascript/HTML tool for generating config files, this interface will let the server owner control the server directly via a standard web browser.

==Design==
The use of a browser with a live server will allow additional administration and configuration tasks that are not available with a simple config.
These tasks include:
* Editing all config-related files
* Saving configuration on server-side
* Reading and clearing logs
* Controlling and checking the status of the server process.

=== Initial Limitations===
Optimally the tool could be developed to a point where it was able to control nearly every aspect of the server. The primary focus of this initial design interface will be ease of use and security. Portability is also a major secondary concern.

==Proposed Features==

=== File editing===
An example feature lacking in <tt>bzfs_conf.html</tt> is the ability to edit and save the several other config-related files, like badwords and helpmsg, from within the browser.
This is reasonable, since Javascript can't usually write to disk, but for this project, it's a necessity. It could be as simple as a text field, but a more sophisticated interface might be useful, such as a table of banned IP addresses with a custom input form and buttons to remove addresses from the list. Depending on the of complexity and layout of these, a separate page for the editing interface for each file might also be warranted. On the other hand, the daemon will overwrite a few files on exit for the things that can be changed by server commands, like the banlist, so a better option for those might be to let the user issue commands to the server from the web interface, which would give control over other parts of the server, as well.

=== Plugins ===
The user should be able to choose from plugins and maps in pre-defined folders, and upload custom maps. Depending on the relative difficulty, maps might be validated on upload or BZFS will check them on startup. (Although it would be interesting to do the same for plugin files, there probably wouldn't be any nice way of keeping it secure.)

==Code==
Javascript will be used sparingly, in places where it makes the interface easier to use. Since not all users allow Javascript, of course, any client-side input validation will be mirrored on the server side. If time allows, and if it would add to the usability of the tool in certain areas, some use of asynchronus Javascript messages through XMLHttpRequest might be explored. However, the entire interface must lose no functionality where user scripting is unavailable.

There should also be very few external tools used in this project, so that it can be deployed as widely as possible. It could be written in PHP or another common scripting language, but that would require whatever language chosen to be present on the host machine. Since BZFlag itself is written in C++, using that language would eliminate the dependency. It would also allow the admin interface to be implemented as a plug-in, using the in-port HTTP feature of the BZFS API, which would likely make it more convenient to deploy. However, in order to ease development, a scripting language may be used to create a working prototype which would then be a blueprint to rewrite the tool in C++.

==Development==
[[User:BugQ|BugQ]] will be carrying out tests on the config files generated by the tool as well as hosting a test server for others to try and give comments on. Suggestions on unnecessary or possible new features should be added to the talk page.

[[Category: Summer Of Code 2008]]

LibBZW

2025-12-15T03:46:49Z

Zehra: Zehra moved page LibBZW to GSoC: LibBZW: projects can be prefixed with '''GSoC:''', to better keep track of them

#REDIRECT [[GSoC: LibBZW]]

GSoC: LibBZW

2025-12-15T03:46:49Z

Zehra: Zehra moved page LibBZW to GSoC: LibBZW: projects can be prefixed with '''GSoC:''', to better keep track of them

''libBZW is a proposed library that will encompass current and future [[BZW]] functionality, replacing independant implementations in various applications, including bzfs.''
==Implementation==
libBZW will be implemented as a static library within [[BZFlag]]. Applications/builds depending on libBZW should be within the BZFlag tree as well for sanity's sake (i.e. [[BZFS]] will depend on libBZW, and is within /bzflag/src).

==Features==
*BZW file parsing

==Functionality==
libBZW will initially contain methods and functionality from the following sources:
Just so I can keep track of what files I will need initially, obtained via grep, primitive list.
Need to add summaries of functionality desired to be copied/reproduced/replicated from each file. --Lukstr
*bzflag/
**src/
***bzfs/
****'''bzfs.cxx''' -- ''Read worlds (via stream/blob or filename), retrieve WorldInfo''
****'''BZWReader.h'''
****'''BZWReader.cxx'''
****'''BZWError.cxx'''
****'''BZWError.h'''
****'''CmdLineOptions.cxx'''
***bzflag/
****'''World.cxx'''
**tools/
***modeltool/
****'''modeltool.cxx''' -- ''Creating/writing bzw files''
*bzwworkbench/
**src/
***model/
****'''BZWParser.cpp''' -- ''Cleaner parser than bzfs?''
****'''Model.cpp'''
**include/
***model/
****'''BZWParser.h'''
****'''Model.h'''

==API==

[[Category: Summer Of Code 2008]]

Bz getPublicPort

2025-12-07T02:01:30Z

Zehra: redirect, since functions are in official docs

#REDIRECT [[Category:BZFS API Docs]]

Bz getPublicDescription

2025-12-07T02:01:15Z

Zehra: redirect, since functions are in official docs

#REDIRECT [[Category:BZFS API Docs]]

BZRobots

2025-12-07T01:57:02Z

Zehra: /* API Methods */ completed conversion to templates

=About BZRobots=

'''(Note that the following information applies to the BZRobots in the upcoming BZFlag 3.0 release)'''

BZRobots is a programmable computer player client that is compatible with the [[BZFS]] server. It is designed to be an artificial intelligence training and development tool that operates under the BZFlag platform.

BZRobots requires that you have already configured and are running an instance of [[BZFS]], that allows one or more bots (using the -botsPerIP setting). Also, BZRobots is a "headless" client (i.e. there are no graphics, it is only text-based), so if you want to watch your bots in action, you will also need to join as an observer or player using the BZFlag client.

=Quick Start: Building=
===Linux/OS X===
The BZRobots client (and support for C++ bots) will by default as a standard part of the bzflag trunk build. However, if you want to build Python bots, you will need to run ./configure with the option --enable-bzrobots-python (and of course have the necessary dependencies)

===Windows===
Open the bzrobots solution, then build the bzrobots and testbot projects.

=Quick Start: Running=
(Note: This quick start assumes that you will be testing bzrobots from within the build directory, have already run 'autogen.sh', 'configure', and 'make' and have not run 'make install')
===Linux/OS X: Shared Library [.so]===
(Due to the use of libtool, the binary TestRobot.so is in the .libs directory)
# cd bzflag/src/bzrobots
# ./bzrobots -team red sobot@localhost .libs/TestRobot.so

===Linux/OS X: Python [.py]===
# cd bzflag/src/bzrobots
# ln -s .libs/bzrobot_pyext.so ./bzrobot_pyext.so
# ./bzrobots -team red pybot@localhost ../../bots/python/TestRobot.py

===Linux/OS X: LUA [.lua]===
# cd bzflag/src/bzrobots
# ./bzrobots -team red luabot@localhost ../../bots/lua/bzbot.lua

===Windows: Shared Library [.dll]===
# cd bzflag
# bzrobots.exe -team red dllbot@localhost TestRobot.dll

===Windows: LUA [.lua]===
# cd bzflag
# bzrobots.exe -team red luabot@localhost bots\lua\bzbot.lua

=Developing Robots=
* [[BZRobots/API]] - A description the BZRobots API
* [[BZRobots/API_BZRobots_vs_Robocode]] - For those coming from RoboCode, a list of differences between the RoboCode and BZRobots

=See Also=
=BZRobots/Ideas=
This page is to collaborate on ideas for the [[BZRobots]] Programmable Computer Player Client

= Suggested ideas =
==API functions==
* Provide an API for visual targets based on the same rules a player would see.
** This would only apply to maps using flags
* Provide global, team, admin, and report chat APIs so bots can communicate just like players, perhaps with some parsing helper functions.

== Input ==
* Allows input of coordinates/properties from stdin, so info from other apps, gps, etc. can be pumped into the bot
** What to do when multiple bots are running in the same client?

= Accepted ideas =
==Scripting==
* Be able to load multiple modules.
** A small amount of work in bzrobots client should make this happen

= Rejected ideas =
==API functions==
* Have methods to compute travel paths to desired locations, with updates for moving targets.
** (Rejected as it defeats the purpose of BZRobots as an AI learning tool)
* Add a getTank(callsign) function
** (Rejected due because BZRobots now supports the onScannedPlayer event)

=History=
The BZRobots Programmable Computer Player Client was originally developed by Brigham Young University as a project called [http://bzrc.cs.byu.edu/ BZRC]

In 2007 it was further developed by Jørgen Pedersen Tjernø (AKA daxxar) as part of the [[Google_Summer_of_Code#Programmable_Computer_Player_Client|Google Summer of Code]]. Information about his work can be found on his GSoC blog at http://gsoc.daxxar.com

This work was continued in 2009 by Mathew Eis (AKA Bulldozer and KingRobot), again as part of [[Google_Summer_of_Code#Programmable_Computer_Player_Client|Google Summer of Code]].

The current BZRobots code can be found in the [[BZFlag_SVN| BZFlag subversion system]] at http://bzflag.svn.sourceforge.net/svnroot/bzflag/trunk/bzflag/src/bzrobots

=BZRobots API=

The API for the BZRobots Programmable Computer Player Client.

The [[BZRobots]] API is based heavily on the [http://robocode.sourceforge.net/ robocode] project. It is class-based, meaning that a robot is built by extending from one of the following two classes:
* Robot (An easy-to-use robot with a simplified API, e.g. degree units, etc.)
* AdvancedRobot (A robot with more advanced features in the API, e.g. radian units, etc.)

The main control loop is created by overriding the class method ''run'', and then using the methods shown below to control the robot. These control methods fit into two categories 'blocking', and 'non-blocking'. A blocking function, once called, will not return until either the requested action has completed, or the amount of time allotted for a "turn" or "tick" has passed - whichever comes later.

Non-blocking functions will return immediately, allowing for additional processing, but their actions do not take effect immediately; rather, they will take place when the ''execute'' method is called. After a blocking function has been called, various "events" that have been generated during that turn may be processed by the various event methods, if they have been overridden.

If you are new to BZRobots, but have Robocode experience, you may want to take a look at [[BZRobots/API_BZRobots_vs_Robocode]]

Unless otherwise specified, all units are in map units (distance), degrees (angles), and seconds (time)

=API Methods=
'''Note:''' ''As BZRobots currently supports bot scripts written in three different languages, the following is language independent description of the methods available for bot development. Actual usage will vary depending on the language used''

{| cellpadding=4 {{Prettytable}}
|-
! colspan=7 {{Hl3}} | ==Robot/AdvancedRobot Methods==
|-
| {{Hl3}} |'''Method'''
| {{Hl3}} |'''Description'''
| {{Hl3}} |'''Blocking'''
| {{Hl3}} |'''Robot'''
| {{Hl3}} |'''Advanced Robot'''
| {{Hl3}} |'''Robocode Compatible'''
| {{Hl3}} |'''Functional Status'''
|-
| void ahead(double distance)
| Moves the robot ahead by ''distance''
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| void back(double distance)
| Moves the robot back by ''distance''
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| void clearAllEvents()
| Clears the event queue; any events will be disgarded
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| void doNothing()
| Clears the event queue; any events will be disgarded
! {{Red}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| void execute()
| Causes any action queued by setAhead, setTurnRight, etc. to take place, ending the "turn"
! {{Green}} | Y
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| void fire(double power)
| Fires a single shot
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Yellow}} | Y
! {{Green}} | 100%
|-
| Bullet *fireBullet(double power)
| Fires a single shot, returning a reference to the fired shot
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Yellow}} | Y
! {{Yellow}} | 50%
|-
| list<Event> getAllEvents()
| Returns a list of all events currently in the queue
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Red}} | 5%
|-
| double getBattleFieldLength()
| Returns the length of the battle field
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Grey}} | N/A
! {{Green}} | 100%
|-
| double getBattleFieldWidth()
| Returns the width of the battle field
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| list<Event> getBulletHitBulletEvents()
| Returns a list of BulletHitBulletEvent currently in the queue
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Red}} | 5%
|-
| list<Event> getBulletHitEvents()
| Returns a list of BulletHitEvent currently in the queue
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Red}} | 5%
|-
| list<Event> getBulletMissedEvents()
| Returns a list of all BulletMissedEvent currently in the queue
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Red}} | 5%
|-
| double getDistanceRemaining()
| Returns the distance remaining from a setAhead/setBack
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| double getEnergy()
| For robocode compatibly - robot's current "energy" (Always 16)
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Grey}} | N/A
|-
| double getGunCoolingRate()
| Returns the time it takes to reload a single shot
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Yellow}} | Y
! {{Green}} | 100%
|-
| double getGunHeading()
| For robocode compatibly - robot's gun heading (Always matches robot heading)
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| double getGunHeadingRadians()
| For robocode compatibly - robot's gun heading (Always matches robot heading)
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| double getGunHeat()
| Returns the time until the gun will be ready to fire
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Yellow}} | Y
! {{Green}} | 100%
|-
| double getGunTurnRemaining()
| For robocode compatibly - (Always returns 0)
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Grey}} | N/A
|-
| double getGunTurnRemainingRadians()
| For robocode compatibly - (Always returns 0)
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Grey}} | N/A
|-
| double getHeading()
| Returns the current heading of the robot
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| double getHeadingRadians()
| Returns the current heading of the robot in radians
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| double getHeight()
| Returns the height (Z-size) of the robot
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Red}} | N
! {{Green}} | 100%
|-
| double getLength()
| Returns the length (Y-size) of the robot
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Grey}} | N/A
! {{Green}} | 100%
|-
| string getName()
| Returns the name (Callsign) of the robot
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| int getNumRounds()
| For robocode compatibly - number of battle rounds (Always '''1''')
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| int getOthers()
| Returns the number of other robots/tanks currently in the battle
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| double getRadarHeading()
| For robocode compatibly - robot's radar heading (Always matches robot heading)
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| double getRadarHeadingRadians()
| For robocode compatibly - robot's radar heading (Always matches robot heading)
! {{Red}} | N
! {{Green}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| double getRadarTurnRemaining()
| For robocode compatibly - (Always returns 0)
! {{Red}} | N
! {{Green}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Grey}} | N/A
|-
| double getRadarTurnRemainingRadians()
| For robocode compatibly - (Always returns 0)
! {{Red}} | N
! {{Green}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Grey}} | N/A
|-
| list<Event> getRobotDeathEvents()
| Returns a list of all RobotDeathEvent currently in the queue
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Red}} | 5%
|-
| int getRoundNum()
| For robocode compatibly - current battle round (Always '''1''')
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| list<Event> getScannedRobotEvents()
| Returns a list of all ScannedRobotEvent currently in the queue
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Red}} | 5%
|-
| list<Event> getStatusEvents()
| Returns a list of all StatusEvent currently in the queue
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Red}} | 5%
|-
| double getTime()
| Returns the current game time
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Yellow}} | Y
! {{Green}} | 100%
|-
| double getTurnRemaining()
| Returns the distance remaining from a setTurnLeft/setTurnRight
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| double getTurnRemainingRadians()
| Returns the distance remaining from a setTurnLeft/setTurnRight in radians
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| double getVelocity()
| Returns the speed of the robot (excluding the Z-speed)
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| double getWidth()
| Returns the width (X-size) of the robot
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| double getX()
| Returns the current X coordinate of the robot
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| double getY()
| Returns the current Y coordinate of the robot
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| double getZ()
| Returns the current Z coordinate of the robot
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| bool isAdjustGunForRobotTurn
| For robocode compatibility - always true
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Grey}} | N/A
|-
| bool isAdjustRadarForGunTurn
| For robocode compatibility - always true
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Grey}} | N/A
|-
| bool isAdjustRadarForRobotTurn
| For robocode compatibility - always true
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Grey}} | N/A
|-
| void resume()
| Resumes any movements saved by a previous call to ''stop''
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| void scan()
| Prompts a radar scan, resulting in onScannedRobot events
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| void setAdjustGunForRobotTurn(bool independent)
| For robocode compatibly - but has no effect when false
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Yellow}} | Y
! {{Grey}} | N/A
|-
| void setAdjustRadarForGunTurn(bool independent)
| For robocode compatibly - but has no effect when false
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Yellow}} | Y
! {{Grey}} | N/A
|-
| void setAdjustRadarForRobotTurn(bool independent)
| For robocode compatibly - but has no effect when false
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Yellow}} | Y
! {{Grey}} | N/A
|-
| void setAhead(double distance)
| Specifies that the robot should move forward by ''distance'' at the next execute()
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| void setBack(double distance)
| Specifies that the robot should move backwad by ''distance'' at the next execute()
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| void setFire(double power)
| Specifies that the robot should fire a bullet of ''power'' at the next execute()
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Yellow}} | Y
! {{Green}} | 100%
|-
| Bullet *setFireBullet(double power)
| Specifies that the robot should fire a bullet of ''power'' at the next execute()
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Yellow}} | Y
! {{Yellow}} | 50%
|-
| void setMaxTurnRate(double maxTurnRate)
| Sets a limit on the maximum turn rate of the robot at the next execute()
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| void setMaxVelocity(double maxVelocity)
| Sets a limit on the maximum speed of the robot at the next execute()
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| void setResume()
| Immediately resumes any motion halted by setStop
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| void setStop(bool overwrite = false)
| Immediately stops any motion until resumed by setResume
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| void void setTurnGunLeft(double degrees)
| For robocode compatablity - has no effect
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Yellow}} | Y
! {{Grey}} | N/A
|-
| void void setTurnGunLeftRadians(double radians)
| For robocode compatablity - has no effect
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Yellow}} | Y
! {{Grey}} | N/A
|-
| void void setTurnGunRight(double degrees)
| For robocode compatablity - has no effect
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Yellow}} | Y
! {{Grey}} | N/A
|-
| void void setTurnGunRightRadians(double radians)
| For robocode compatablity - has no effect
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Yellow}} | Y
! {{Grey}} | N/A
|-
| void void setTurnLeft(double degrees)
| Sets the robot to turn left by ''degrees'' at the next execute()
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| void void setTurnLeftRadians(double radians)
| Sets the robot to turn left by ''radians'' at the next execute()
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| void void setTurnRadarLeft(double degrees)
| For robocode compatibility - has no effect
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Yellow}} | Y
! {{Grey}} | N/A
|-
| void void setTurnRadarLeftRadians(double radians)
| For robocode compatibility - has no effect
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Yellow}} | Y
! {{Grey}} | N/A
|-
| void void setTurnRadarRight(double degrees)
| For robocode compatibility - has no effect
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Yellow}} | Y
! {{Grey}} | N/A
|-
| void void setTurnRadarRightRadians(double radians)
| For robocode compatibility - has no effect
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Yellow}} | Y
! {{Grey}} | N/A
|-
| void void setTurnRight(double degrees)
| Sets the robot to turn right by ''degrees'' at the next execute()
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| void void setTurnRightRadians(double radians)
| Sets the robot to turn right by ''radians'' at the next execute()
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| void stop(bool overwrite = false)
| Stops the robot, saving any current movements
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| void turnGunRight(double degrees)
| For robocode compatibly - but has no effect
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Yellow}} | Y
! {{Grey}} | N/A
|-
| void turnGunLeft(double degrees)
| For robocode compatibly - but has no effect
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Yellow}} | Y
! {{Grey}} | N/A
|-
| void turnLeft(double degrees)
| Turns the robot left ''degrees'' degrees
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| void turnLeftRadians(double radians)
| Turns the robot left ''radians'' radians
! {{Green}} | Y
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| void turnRadarRight(double degrees)
| For robocode compatibly - but has no effect
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Yellow}} | Y
! {{Grey}} | N/A
|-
| void turnRadarLeft(double degrees)
| For robocode compatibly - but has no effect
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Yellow}} | Y
! {{Grey}} | N/A
|-
| void turnRadarLeftRadians(double radians)
| For robocode compatibly - but has no effect
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Yellow}} | Y
! {{Grey}} | N/A
|-
| void turnRadarRight(double degrees)
| For robocode compatibly - but has no effect
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Yellow}} | Y
! {{Grey}} | N/A
|-
| void turnRadarRightRadians(double radians)
| For robocode compatibly - but has no effect
! {{Red}} | N
! {{Red}} | N
! {{Green}} | Y
! {{Yellow}} | Y
! {{Grey}} | N/A
|-
| void turnRight(double degrees)
| Turns the robot right ''degrees'' degrees
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| void turnRightRadians(double radians)
| Turns the robot right ''radians'' radians
! {{Green}} | Y
! {{Red}} | N
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
! colspan=7 {{Hl3}} | ==Robot/AdvancedRobot Event Handlers==
|-
| {{Hl3}} |'''Method'''
| {{Hl3}} |'''Description'''
| {{Hl3}} |'''Blocking'''
| {{Hl3}} |'''Robot'''
| {{Hl3}} |'''Advanced Robot'''
| {{Hl3}} |'''Robocode Compatible'''
| {{Hl3}} |'''Functional Status'''
|-
| void onBattleEnded(BattleEndedEvent e)
| Called at the end of a league match, or the server shutting down
! {{Grey}} | N/A
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Red}} | 10%
|-
| void onBulletFired(BulletFiredEvent e)
| Called when another robot/tank fires a bullet
! {{Grey}} | N/A
! {{Green}} | Y
! {{Green}} | Y
! {{Grey}} | N/A
! {{Red}} | 10%
|-
| void onBulletHit(BulletHitEvent e)
| Called when a bullet fired by the robot hits another robot
! {{Grey}} | N/A
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Yellow}} | 80%
|-
| void onBulletHitBullet(BulletHitBulletEvente)
| For robocode compatibility - will never take place
! {{Grey}} | N/A
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Grey}} | N/A
|-
| void onBulletMissed(BulletMissedEvent e)
| Called when a bullet fired by the robot expires or hits a wall
! {{Grey}} | N/A
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Red}} | 10%
|-
| void onDeath(DeathEvent e)
| Called when the robot dies
! {{Grey}} | N/A
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| void onHitByBullet(HitByBulletEvent e)
| Called when the robot is hit by a bullet
! {{Grey}} | N/A
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Red}} | 25%
|-
| void onHitRobot(HitRobotEvente)
| For robocode compatibility - will never be called
! {{Grey}} | N/A
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Grey}} | N/A
|-
| void onHitWall(HitWallEvent e)
| Called when the robot runs into a wall or object
! {{Grey}} | N/A
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! bgcolor="#22BB00" | 90%
|-
| void onRobotDeath(RobotDeathEvent e)
| Called when the robot is killed
! {{Grey}} | N/A
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| void onScannedRobot(ScannedRobotEvent e)
| Called each turn as the robot's radar "sees" another robot
! {{Grey}} | N/A
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 100%
|-
| void onSpawn(SpawnEvent e)
| Called when the robot spawns
! {{Grey}} | N/A
! {{Green}} | Y
! {{Green}} | Y
! {{Grey}} | N/A
! {{Green}} | 100%
|-
| void onStatus(StatusEvent e)
| Called at the beginning of each "turn", before the main loop is run
! {{Grey}} | N/A
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | Y
! {{Green}} | 95%
|-
| void onWin(WinEvent e)
| Called when the robot (or it's team) wins a league match
! {{Grey}} | N/A
! {{Green}} | Y
! {{Green}} | Y
! {{Yellow}} | Y
! {{Red}} | 10%
|-
|}

=See Also=

* [[BZRobots/API_BZRobots_vs_Robocode]] - Differences between Robocode and BZRobots

Template:Grey

2025-12-07T01:54:23Z

Zehra: created grey template

bgcolor="#555555"

Template:Yellow

2025-12-07T01:51:58Z

Zehra: created yellow template

bgcolor="#BBBB00"

Comparison of map objects

2025-12-07T01:30:45Z

Zehra: content merged to BZW Index

#REDIRECT [[BZW Index]]

BZW Index

2025-12-07T01:29:49Z

Zehra: merged content from Comparison of map objects

Index of BZW maps, tools, utilities and more.

=Map Editors=
Map editors are programs that are specifically written to create and edit [[BZW]] map files.

There's several different versions of map editors which currently exist.
Some are standalone programs while others are based on plug-ins and/or scripts and mostly are designed to convert files into the BZW format.

Below is a basic general comparison of several map editors.

{| class="wikitable sortable"
|-
! Map editor
! Operating system
! Supports 2.0 world objects
! Type of program
|-
! [[BZEdit]]
| Linux
| No
| Standalone
|-
! [[BZEditWin32]]
| Windows
| No
| Standalone
|-
! [[BZFed]]
| Linux
| No
| Standalone
|-
! [[BZWTools]]
| Cross-platform
| Yes
| Plug-in
|-
! [[DI-Machine]]
| Cross-platform
| Yes
| Script to convert .obj file into a drawInfo-specific .bzw file
|-
! [[IBZEdit]]
| Mac OS
| Some objects are supported
| Standalone
|-
! [[Modeltool]]
| Cross-platform
| Yes
| Tool to convert wavefront.obj files to .bzw mesh
|-
! [[PyBZEdit]]
| Cross-platform
| Yes
| Standalone
|-
! [[Wings3D]]
| Cross-plaform
| Yes
| Standalone
|}

=Tools and Utilities:=

{|{{Prettytable}}
|-
| {{Hl3}} |'''Tool/Utility name'''
| {{Hl3}} |'''Description'''
|-
| [https://forums.bzflag.org/viewtopic.php?t=20415 bzflag-rendering.php] || '''Generating map thumbnails in PHP'''
|-
| [https://forums.bzflag.org/viewtopic.php?t=468 Bmp2Bzw] || '''Converts .bmp files into maps.'''
|-
| [https://forums.bzflag.org/viewtopic.php?t=1651 bzmapper v2.0] || '''1.x Multi-tool map generator'''
|-
| [https://forums.bzflag.org/viewtopic.php?t=7928 BZReader] || '''Texture grabber and organizer for images.bzflag.org'''
|-
| [https://forums.bzflag.org/viewtopic.php?t=6520 BZFlag MapU - Box to Mesh] || '''Builds a mesh based on specifications for a box. (Some errors may be present.)'''
|-
| [https://forums.bzflag.org/viewtopic.php?t=20587 Pyramid to Mesh] || '''Builds a mesh according to specifications for a pyramid.'''
|-
| [https://forums.bzflag.org/viewtopic.php?t=11514 DI-machine] || '''Converts .obj files into pure drawInfo. (Requires PHP.)'''
|-
| [https://forums.bzflag.org/viewtopic.php?t=20707 Py-Machine] || '''Python port of DI-Machine'''
|-
| [https://forums.bzflag.org/viewtopic.php?t=12636 applescript Material Generator] || '''AppleScript program for bzw materials generation.'''
|-
| [https://forums.bzflag.org/viewtopic.php?t=12703 pyconvert] || '''Converts old style (1.0) maps into textured mesh maps.'''
|-
| [https://forums.bzflag.org/viewtopic.php?t=16040 Anim8or to BZW Converter] || '''Tool to convert cubes in animator to .bzw boxes, pyramids or teleporters. '''
|-
| [https://forums.bzflag.org/viewtopic.php?t=20709 Anim8orToBZW] || '''Port of the original tool to Python'''
|-
| [https://forums.bzflag.org/viewtopic.php?t=16071 random generator] || '''Tool for helping generate random symmetric maps with the "group" object.'''
|-
| [https://forums.bzflag.org/viewtopic.php?t=13058 bzwmoviemaker] || '''Script for making billboard animations in BZFlag'''
|-
| [https://forums.bzflag.org/viewtopic.php?t=12886 FixOldTeles] || '''Fixes broken teleport links from BZEdit'''
|-
| [https://forums.bzflag.org/viewtopic.php?p=136642#p136642 GrassTuftGenerator] || '''Creates 3D grass tufts for a map'''
|-
| [[BZWTools]] || '''Plug-in for viewing and editing bzw maps in Blender. (Does not work with current version of Blender.)'''
|-
| [https://forums.bzflag.org/viewtopic.php?t=19267 UnityBZFlagBoxExport] || '''Supports the creation and positioning of boxes in 3D view. (Nearly a map editor.)'''
|-
| [[Modeltool]] || '''Current go to tool for converting .obj files to bzw mesh maps.'''
|-
| [https://forums.bzflag.org/viewtopic.php?t=1899 remove map file comments] || '''C++ app'''
|-
| [https://forums.bzflag.org/viewtopic.php?t=1867 "Maze" generator] || '''In C and in Python'''
|-
| [https://forums.bzflag.org/viewtopic.php?t=1614 Map generator script] || '''In Python'''
|-
| [https://forums.bzflag.org/viewtopic.php?t=11693 BZEdit Replacement Textures] || '''Better textures for BZEdit'''
|-
| [https://forums.bzflag.org/viewtopic.php?t=18429 Autogeneration of bzw world] || '''In GNU Emacs'''
|-
| [https://forums.bzflag.org/viewtopic.php?t=5404 MAP converter] || '''In Qbasic'''
|-
| [https://forums.bzflag.org/viewtopic.php?t=6995 Write text with bullets] || '''In Qbasic'''
|-
| [https://forums.bzflag.org/viewtopic.php?t=8343 A text to map converter] || '''In Qbasic'''
|-
| [https://forums.bzflag.org/viewtopic.php?t=7008 A text to map converter /!\ OLD version] || '''In Qbasic'''
|-
| [https://forums.bzflag.org/viewtopic.php?t=7133 Random Map Generator] || '''Lots of versions of random map generators'''
|-
|}

==Map Objects==
{|{{Prettytable}}
|-
| {{Hl3}} |'''Map Object'''
| {{Hl3}} |'''Description'''
|-
| [[ Arc]] || Arc is an object that defines an arc or cylinder in a map.
|-
| [[ Base]] || Base is an object which is similar to a box, but defines properties of it being a base for capture the flag style game play modes.
|-
| [[Box]] || Box is an object which defines a cube structure in a world file.
|-
| [[Color(BZW)]] || Color is used in a BZFlag world (BZW) as a sub parameter for many parameters, such as materials and dynamic colors.
|-
| [[Cone]] || Cone object is a BZW object that defines a cone in a BZW world file.
|-
| [[Define]] || Group Definition, or define, will group a set of objects that can be recalled and duplicated multiple times with the group object.
|-
| [[DrawInfo]] || DrawInfo allows clients to render the mesh object more efficiently through LODs (Levels of Detail). Drawinfo also allows the ability to create moving objects in a map.
|-
| [[DynamicColor]] || DynamicColor describes how a color channel will be dynamically updated.
|-
| [[GroundMaterial]] || GroundMaterial is an option for a Material that allows one to set the ground texture. .
|-
| [[Group]] || Group allows one to bring together a number of elements and refer to them as a single object.
|-
| [[Include]] || Include is an option which allows one to specify a second bzw file that will be included in the first bzw.
|-
| [[Link]] || Link is an object which creates a link (route) between two teleporters.
|-
| [[Linkmaterial]] || LinkMaterial allows one to set the texture of the teleporter window to anything one would like it to be..
|-
| [[Material]] || A material is used in a BZFlag world to define a new look for otherwise regular objects, such as meshboxes.
|-
| [[Mesh]] || Mesh is an object which defines an arbitrary three dimensional shape.
|-
| [[Meshbox]] || Meshbox is an update to the original [[Box]] object and supports features such as physics drivers and textures.
|-
| [[Meshpyr]] || Meshpyr is an object that constructs a specialized mesh that has the geometric appearance of a Pyramid.
|-
| [[Options (object)]] || Options object is a BZW map structure that defines various options for a server to use when running a map.
|-
| [[Physics]] || Physics, or Physics Driver, is an object when applied to another object, will affect a tank touching it in some way.
|-
| [[Pyramid]] || Pyramid is a BZW map structure that defines a polyhedron having a polygonal base and triangular sides with a common vertex in the world.
|-
| [[Sphere]] || The sphere is an Object that defines a sphere in a map file.
|-
| [[Teleporter]] || Teleporter is an object which transports the user to another teleporter in a different part of the world.
|-
| [[Tetra]] || Tetra is an map object which creates a polygon with four vertices.
|-
| [[TextureMatrix]] || TextureMatrix, or texmat, when applied to a material object, allows you to define how a texture will appear in a material.
|-
| [[WaterLevel]] || WaterLevel is an object that defines a plane of water that spans the entire map. WaterLevel is deadly to all tanks that cross it.
|-
| [[Weapon (object)]] || Weapon object is a BZW map structure that defines a fixed weapon effect.
|-
| [[World (object)]] || World object is a BZW map structure that defines various options for the map.
|-
| [[Zone]] || Zone is a rectangular BZW map structure for spawn or flag zones.
|}

[[Category:Map Making]]

Google Summer of Code/2009/OrgApplication

2025-12-07T01:13:18Z

Zehra: Zehra moved page Google Summer of Code/2009/OrgApplication to Google Summer of Code: 2009:OrgApplication: let's standardize the pages a bit with '''Google Summer of Code:''' as prefix

#REDIRECT [[Google Summer of Code: 2009:OrgApplication]]

Google Summer of Code: 2009:OrgApplication

2025-12-07T01:13:18Z

Zehra: Zehra moved page Google Summer of Code/2009/OrgApplication to Google Summer of Code: 2009:OrgApplication: let's standardize the pages a bit with '''Google Summer of Code:''' as prefix

= 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 more than 19000 registered players 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 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 existing 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). Indiana University researchers worked with our staff in 2007 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. Past participation in GSoC has stimulated our project development activities and forced us to become more organized, collaborative, and deliberate in our focus. Our community members have great ideas for improving the game 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, the administrator will relay this status to Google after repeated attempts to contact the student fail.

Students are expected to commit changes very frequently. Our philosophy is that if they're not committing, then they are not working (at least not 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 needed, we will have discussions with them, see what's going on, and do so proactively. We learned from one student who was in serious danger of failing that a simple change in accountability can have a massive impact on 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 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 prompt responses to questions and comments.

Other than that, the formula for dealing with disappearing students really just boils down to communication. It is 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.

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

For student applicants we have a specific checklist of tasks to help them prepare to engage in routine development. 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 quickly get new developers familiar and interested in development directions. Thanks to our previous involvement with GSoC, we 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 in 2007 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 sense of belonging and a sense of appreciation for the hard work they put 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 but 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 Acceptance

2025-12-07T01:10:55Z

Zehra: Zehra moved page Google Summer of Code Acceptance to Google Summer of Code: Acceptance: let's standardize the pages a bit with '''Google Summer of Code:''' as prefix

#REDIRECT [[Google Summer of Code: Acceptance]]

Google Summer of Code: Acceptance

2025-12-07T01:10:55Z

Zehra: Zehra moved page Google Summer of Code Acceptance to Google Summer of Code: Acceptance: let's standardize the pages a bit with '''Google Summer of Code:''' as prefix

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.

You are welcome to submit more than one patch if you like. We will review any you submit, but we only require and expect one; remember that quality is far more important than quantity in our reviews.

Be sure to include either a link to the Sourceforge patch tracker item or your Sourceforge username 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/Application Guidelines

2025-12-07T01:09:10Z

Zehra: Zehra moved page Google Summer of Code/Application Guidelines to Google Summer of Code: Application Guidelines: let's standardize the pages a bit with '''Google Summer of Code:''' as prefix

#REDIRECT [[Google Summer of Code: Application Guidelines]]

Google Summer of Code: Application Guidelines

2025-12-07T01:09:10Z

Zehra: Zehra moved page Google Summer of Code/Application Guidelines to Google Summer of Code: Application Guidelines: let's standardize the pages a bit with '''Google Summer of Code:''' as prefix

There is intentionally no specific format that students need to use to apply to BZFlag. There are, however, several things that you should and should not do when applying.

= Do's =

'''Be Detailed and Articulate.''' Go into detail about what you intend to do and how you intend to do it. Don't have typos and be clear in your writing. Cite academic references if they're relevant to your work. Create diagrams, show prototypes, create mock-up visuals, and provide more information via external links. You don't have to solve everything, but we need to see that you've thought things through. Impress us.

'''Get Involved Early.''' You need to join our IRC channel, play the game, and get involved in our community. Talk to the other developers, find a mentor that likes your proposal idea. Don't forget to mention your IRC nick in your application. We interact with a lot of people so give us a personality that we can recognize when it comes to reviewing the applications. Communicate early, communicate often.

'''Be Bold.''' We love new innovative ideas. You should make sure your idea fits into the scope of our project and is something we're interested in mentoring, but new projects are welcome. If your proposal is for one of our ideas, be innovative and ambitious in your solution.

'''Be Realistic.''' Make sure the scope of your work is feasible and that you will have the necessary skills to implement your project on time. Don't be so bold that you are unrealistic, keep your abilities and time constraints in mind. If you've got another part-time or full-time job, you probably won't be able to put in the effort or time necessary.

'''Be Passionate.''' Show enthusiasm for your idea. Be excited to work with us. Excitement and passion are never a substitute for competence, but they vastly help your chances all other factors being equal. Express your passion and any background information about yourself that reinforces your interests.

= Don'ts =

'''Don't copy/paste our ideas.''' If all you have to say about the idea is what we've said, it will be rejected. They are just meant to be starting points.

'''Don't be brief.''' Anticipate questions, include details. If your application isn't any more than a few hundred words or less, then you're probably not including useful/necessary detail about the project, your plans, or yourself. Brief proposals very quickly get cut, especially when compared to proposals in similar areas that do include detail.

'''Don't forget to tell us about yourself.''' Most of what we know about you and your abilities is going to come from your application. Include details about your background, experience, and anything else relevant to your work. If you have obligations that will impact your proposal, be upfront. You should be interacting with our community on IRC long before you submit your proposal so we have an idea how you interact.

'''Don't be intimidated.''' Your ideas will be questioned and critiqued. We don't all agree, even amongst ourselves often. You will need to be able to openly and publicly talk about your ideas without being defensive. Be open to the ideas and suggestions of others and be willing to amicably engage in discussions.

'''Don't be discouraged.''' During the application process, we receive a lot of applications. Be patient. If we don't respond to your application for more information, it usually means that it's either really bad or really good. Understand that we have a lot to sort through and discuss. It's a very competitive process given we can only accept a limited number of students. If you have specific questions, engage the mentors over IRC.

Google Summer of Code/2009

2025-12-07T01:07:52Z

Zehra: Zehra moved page Google Summer of Code/2009 to Google Summer of Code: 2009: let's standardize the pages a bit with '''Google Summer of Code:''' as prefix

#REDIRECT [[Google Summer of Code: 2009]]

Google Summer of Code: 2009

2025-12-07T01:07:52Z

Zehra: Zehra moved page Google Summer of Code/2009 to Google Summer of Code: 2009: let's standardize the pages a bit with '''Google Summer of Code:''' as prefix

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]]

Talk:Google Summer of Code/2008

2025-12-07T01:07:12Z

Zehra: Zehra moved page Talk:Google Summer of Code/2008 to Talk:Google Summer of Code: 2008: let's standardize the pages a bit with '''Google Summer of Code:''' as prefix

#REDIRECT [[Talk:Google Summer of Code: 2008]]

Talk:Google Summer of Code: 2008

2025-12-07T01:07:12Z

Zehra: Zehra moved page Talk:Google Summer of Code/2008 to Talk:Google Summer of Code: 2008: let's standardize the pages a bit with '''Google Summer of Code:''' as prefix

This is informational only. There are no wrong answers. This is more just to get a visual on what we're all thinking. Rank what you feel the top five projects ideas from most important to least with a 1, 2, 3, 4, and 5 respectively. Your ranking criteria for determining importance are:

1) projects that are ''needed'' for BZFlag's long-term development
2) projects that are ''wanted'' due to features or capabilities they provide
3) projects that will make the most ''impact'' on our users
4) those that are likely to be ''successfully'' worked on over three months by a student remembering that the scope can be defined/reduced as needed
5) ideas that are of specific interest to you as a dev that warrant involving others in your evil aspirations

'''Only mark your top five'''.

Also, anyone not listed that would like to share their importance ordering is QUITE WELCOME to add their name and numbers to the table.

{|- border="1"
! PROJECT
! dtremenak
! jeffm
! jbdigriz
! spldart
! blast
! sean
! Mr_Burns
! [...]
|-
! Enhanced Statistics system
|
|
|
|
|
|
| 5
|
|-
! Dead Reckoning & Networking
|
| 2
| 2
|
|
|
|
|
|-
! Modularization of Game Logic
|
| 5
| 4
| 3
| 4
| 3
|
|
|-
! Global Authentication Daemon
| 2
| 2
| 3
|
| 1
| 1
| 3
|
|-
! BZWorkBench World Editor
| 3
| 4
|
|
| 3
| 4
| 2
|
|-
! Enhanced Server Listing
|
| 3
|
| 2
|
|
|
|
|-
! Multiple Display Support
| 4
|
|
| 5
|
|
|
|
|-
! In-game Profile Management
|
|
|
|
|
|
|
|
|-
! BZFS Web Interface
| 5
|
|
| 4
|
|
| 4
|
|-
! Network Testing Framework
|
|
| 5
|
|
| 5
|
|
|-
! Cross Server Communications System
|
|
|
|
| 5
|
|
|
|-
! Cheat Preventions
| 1
| 1
| 1
| 1
| 2
| 2
| 1
|
|}

Google Summer of Code/2008

2025-12-07T01:07:12Z

Zehra: Zehra moved page Google Summer of Code/2008 to Google Summer of Code: 2008: let's standardize the pages a bit with '''Google Summer of Code:''' as prefix

#REDIRECT [[Google Summer of Code: 2008]]

Google Summer of Code: 2008

2025-12-07T01:07:12Z

Zehra: Zehra moved page Google Summer of Code/2008 to Google Summer of Code: 2008: let's standardize the pages a bit with '''Google Summer of Code:''' as prefix

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]]
[[Category: Summer Of Code 2008]]

GSoC: Evaluation

2025-12-07T01:06:00Z

Zehra: Zehra moved page GSoC: Evaluation to Google Summer of Code: Evaluation: shorthand GSoC doesn't look too good for page titles

#REDIRECT [[Google Summer of Code: Evaluation]]

Google Summer of Code: Evaluation

2025-12-07T01:06:00Z

Zehra: Zehra moved page GSoC: Evaluation to Google Summer of Code: Evaluation: shorthand GSoC doesn't look too good for page titles

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.

GSoC: 2007

2025-12-07T01:05:19Z

Zehra: Zehra moved page GSoC: 2007 to Google Summer of Code: 2007: shorthand GSoC doesn't look good.

#REDIRECT [[Google Summer of Code: 2007]]

Google Summer of Code: 2007

2025-12-07T01:05:19Z

Zehra: Zehra moved page GSoC: 2007 to Google Summer of Code: 2007: shorthand GSoC doesn't look good.

BZFlag participated in the 2007 [[Google Summer of Code]]. In 2007, Google funded approximately 800 students across approximately 135 participating mentoring organizations, including BZFlag. A detailed after-the-fact discussion and analysis of BZFlag's first-year participation in the 2007 Google Summer of Code 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]''''' by Sean Morrison. 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).
{|align="right"
|[[Image:Gsoc_postmortem_preview.png|thumb|left|512px|http://my.bzflag.org/gsoc/bzflag_gsoc2007_post_mortem.pdf]]
|}

= Preparing an Application =

There was no specific format to applications, but they were told that they should be detailed in their approach and background information about themselves. They were supposed to state specifically what they intend to deliver and any implementation details they felt relevant such as what language they intend to use. C/C++ proposals were preferred though others were considered. Students that just submitted the summaries contained below did not do very well. If you talked with us on IRC about your SoC proposal, you were supposed to include your IRC nickname somewhere in your proposal.

Early proposal submission was encouraged as it gave us more time to review your proposal in detail, comment on them, and potentially ask for additional input. Submitting closer to the deadline wasn't a negative consideration as all submissions were be predominantly judged on their merit, but submitting and discussing early was an advantage for submissions that were similar to other submissions.

Students were 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 =

We received a total of 45 proposals for the 2007 program that were then reviewed, evaluated, and critiqued. Of those applications, only '''four''' could be selected to work on BZFlag. There were about 20 really good proposals overall, making the selection process very competitive and difficult. ''This cannot be stressed enough..'' It was really hard to narrow down the submissions but in the end we did have only so many slots to work with and the line eventually had to be drawn. Every application was read multiple times and reviewed in detail. We thank '''everyone''' that submitted a proposal and hope to still see some of you become involved in our software development.

In the end, submissions were 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 was made of students that were 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 were 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 projects that were accepted are as follows:

== Graphical BZFlag Map Editor ==
=== Jude Nelson (jude-) ===

BZFlag does not yet have a sufficient graphical world map editor. That is to say that while there have been many over the years, they all fall into obsolescence or are less than ideal due to other constraints upon their use). While some existing editors come very close, it is usually the case that they do not fully support advanced map features, require the users to have a programmer's understanding of the file format, are not well documented, are very platform-specific, or are outright obsolete. This is problematic to the BZFlag community in that it hinders less technically-inclined users from developing worlds. To support this need, the proposed work aims to implement such an editor that should allow users to quickly create worlds in a visual manner, provide a GUI to easily manipulate all features of BZW, provide intuitive and interactive visualizations of all map data, and allow for easy extendibility to ensure future BZW compatibility. Additionally, to encompass a larger user base, it will be developed using cross-platform toolkits, allowing it to be easily ported between operating systems and ideally support the same target operating systems as BZFlag itself.

== Random Procedural World Generator ==
=== Kornel Kisielewicz (Epyon) ===

Although BZFlag implements a poor man's random map generator as default, most players prefer to play on user made maps. The reason is simple -- the primitive scattering algorithm implemented in BZF's random map generation is, well, simple and limited. Creating a nice looking and fun-to-play map by hand, however, is a non-trivial task too. In order to really enjoy playing BZFlag, you need to search for good levels in the community, and even those can get boring after a while because you learn their layout or their popularity diminishes. Moreover, players who know the map well have an unfair advantage when playing against people who see the map for the first time. Moreover still, if you want to set up your own server, the task of creating your own map by hand can be rather complicated and involved.

== Community Messaging System ==
=== Chris Wible (L4m3r) ===

BZFlag has efficient in-game chat among players on a server. However, it's currently difficult to reach a player from outside the game, or to communicate without actually joining a server. By implementing a more sophisticated community messaging system, players will be able to contact one another across servers and outside of gameplay, all from within the game client. This will allow players to get together in a common place to schedule matches as well as provide a general ''global chat'' mechanism for the game.

== Programmable Computer Player Client ==
=== Jørgen Pedersen Tjernø (daxxar) ===

BZFlag has a hard-coded computer player that players can join with or enable in the game client, but the behavior and capabilities of that bot player are rather limited, unchanging, and easily predicted. This efforts creates an interface for making better BZFlag computer players by building upon the existing '''exceptional''' efforts of the [http://bzrc.cs.byu.edu/ BZRC] project (developed and contributed by Andrew McNabb and others at BYU). This effort aims to provide a fully programmable/scriptable standard interface for controlling a tank through a framework that can be readily distributed and shared. This interface supports basic artificial intelligence (AI) research and AI education as well.

= Proposal Ideas =

While there are lots of [[Ideas]] floating around of varying utility to the game, the ideas listed below were the specific areas that we were predominantly interested in seeing worked on as part of the GSoC. Please note that students were also welcome to apply with their own original ideas. They should have run those ideas 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.

Ideas marked with an "*" indicate entries where we received at least two or more submissions for that idea.

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

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

== Two-player tanks * ==
Make modifications to the game such that it is optionally possible (e.g. via a server configuration) to allow multiplayer tanks where one player can only drive and the other can control the turret. The implementation would have to be some simple/intuitive interface to join and depart tanks as well as implemented in a fashion that preserves the "spirit" of BZFlag's operational simplicity.

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

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

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

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

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

The below flyer was used to help spread the word about our involvement with the Google Summer of Code. Flyers were translated to other languages that we had mentors for and the students that were selected did end up spanning the globe. While many developers can converse fluently in other languages, English is still expected for developer discussions but the flyers did help get the word out and inform our own (international) player community as to what was happening.

* 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])

Thanks to Sean Morrison (aka learner) for designing our 2007 GSoC flyer.

= 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
* David Wollner
* Andrew McNabb
* Tim Riker
* Donna Crawford

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

[[Category: Development]]

Google Summer of Code/2007

2025-12-07T01:03:13Z

Zehra: Zehra moved page Google Summer of Code/2007 to GSoC: 2007: let's make Google Summer of Code the main page, with subcategories and pages prefixed with '''GSoC:''

#REDIRECT [[GSoC: 2007]]

Google Summer of Code: 2007

2025-12-07T01:03:13Z

Zehra: Zehra moved page Google Summer of Code/2007 to GSoC: 2007: let's make Google Summer of Code the main page, with subcategories and pages prefixed with '''GSoC:''

Google Summer of Code Evaluation

2025-12-07T01:01:55Z

Zehra: Zehra moved page Google Summer of Code Evaluation to GSoC: Evaluation: let's make Google Summer of Code the main page, with subcategories and pages prefixed with '''GSoC:'''

#REDIRECT [[GSoC: Evaluation]]

Google Summer of Code: Evaluation

2025-12-07T01:01:55Z

Zehra: Zehra moved page Google Summer of Code Evaluation to GSoC: Evaluation: let's make Google Summer of Code the main page, with subcategories and pages prefixed with '''GSoC:'''

Google Summer of Code

2025-12-07T00:52:13Z

Zehra: let's do a quick note that info is kept for archive purposes

__NOTOC__

{{SimpleBox|Note|This information is kept for archive purposes. Links, channels and more may be broken.}}

=Overview=

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

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.

=2010=
BZFlag will not be applying to SOC 2010 in order to concentrate on the release of V3.
==Past years==
See
[[Google_Summer_of_Code/2009|2009 GSoC page]]

[[Google_Summer_of_Code/2008|2008 GSoC page]]

[[Google_Summer_of_Code/2007|2007 GSoC page]]

for past projects.

= 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 been accepted.'''''

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

== [[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 whom were integrated into our development community.

== [[Google Summer of Code/2007|2007 (more details here)]] ==
{|align="right"
|[[Image:BZGSoC2007_small.gif|thumb|left|128px]]
|}
BZFlag first participated during GSoC's third year in 2007. A detailed after-the-fact discussion and analysis of BZFlag's first-year participation is included in the article ''[http://my.bzflag.org/gsoc/bzflag_gsoc2007_post_mortem.pdf “Postmortem” Perspectives of a First-year Participant in the 2007 Google Summer of Code for BZFlag]''. This article was given to Google in August 2007 as a final report, per se, of our involvement (you're only a first-year participant once).

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

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

[[Category: Development]]

Project History

2025-12-07T00:38:31Z

Zehra: redirect to BZFlag Project for now, as we can merge most content there

#REDIRECT [[BZFlag Project]]

Chris Schoeneman

2025-12-07T00:36:05Z

Zehra: let's bring back project history during Chris's era

Chris Schoeneman is the original author of BZFlag. He is also known as crs or crs32

==History of BZFlag (as told by Chris Schoeneman)==

BZFlag began back in 1992 while I was a Masters student at the Cornell Program of Computer Graphics. I was an intern at SGI for the summers of '90 and '91, working on a prototype Indigo during the second summer which was a blast. So by 1992, IRIS GL was an old friend.

At the Cornell PCG, essentially the only computers available were HP 700 series workstations. While CRX-24Z graphics wasn't too bad (around XS24-Z performance), HP's graphics library, Starbase, wasn't quite as easy to use as IRIS GL. In the words of fellow student Rick Pasetto, "Starbase sucks rocks." As a result, very few students wrote interactive graphics tools to assist their research. If you wanted to make an image you usually had to at least ray trace it.

So Rick and I wrote an IRIS GL-like layer on top of Starbase which we called WM (it was originally for window management). To encourage the other students to use it I wrote a number of small demo programs, small being the key word here. The fact that you could open a window and render to it with only a dozen lines of code ensured WM's success. I think it was finally retired by 1999, replaced by OpenGL.

I began to write BZFlag as a simple demo but soon abandoned it after producing a program that was supposed to let you drive around a virtual world but instead had a bizarre warping effect because I goofed up the order of my transformations. I had by then also realized how much more work was involved and had other stuff to do.

So there it sat, unused, for a few months until another student browsing the WM demo directory found it and said it looked cool and that I should finish it. So in a week long marathon of programming BZFlag took shape. The earliest complete version had two notable bugs. The first was that each player had his very own random world; it was soon discovered that hiding behind a pyramid didn't work because the pyramid wasn't even there in the other player's world. Once that was fixed, the second bug became clear: it was impossible to play. I had tried to base the BZFlag world on the real world, so the playing field was 10km on a side and shots moved at around Mach 1. It took forever to get from one end of the board to the other and you couldn't even see a shot before it hit you. So we scrapped some realism in favor of playability. After a few more tweaks, we had a pretty fun game.

At this point the game resembled bz by Chris Fouts. This is no surprise because both games are based on the old Atari arcade game ?BattleZone. In fact, BZFlag was called bz back then because no one in the PCG knew of the existence of Chris Fouts' bz. Yes, that's right, BZFlag was written with no knowledge of bz. The two games share no code and were designed and written independently. They owe their similarities to their ?BattleZone heritage.

It didn't take too long to get bored with the basic shoot-'em-up game. We quickly came up with the capture-the-flag mode and designed the new world it's played in. This kept our interest for quite a while (it's still my favorite mode). Strategy now played a role. You still needed good tactics to keep yourself alive, but you had to have a team strategy to excel.

After one of the students hacked the code to make his tank super-powerful (blatantly so; he wasn't trying to fool us) we invented superflags. The first four super flags were: high speed, quick turn, rapid fire, and oscillation overthruster. Originally, there was one of each flag and each had an identifying mark so you knew what it was before you grabbed it. When more superflag ideas came up (including the concept of bad flags) we dropped the marks and made the flags appear randomly. This was around May 1993 and the game has remained substantially the same ever since. I rewrote the game in C++ (from C) for SGI's third ?IndiZone contest. BZFlag won in the Reality Engine category, earning me a nice little home computer (a Indigo2 200MHz R4400, with a 20" monitor, 64MB, a CD-ROM, DAT, 2GB disk, and High Impact graphics with 4 TRAMs).

==Old links==
* http://web.archive.org/web/*/http://reality.sgi.com/crs/bzflag.html
* http://web.archive.org/web/*/http://bzflag.linuxgames.com/
* http://web.archive.org/web/*/http://bzflag.sourceforge.net/
* http://web.archive.org/web/*/http://BZFlag.org/

[[Category:Developer]]