BZFlag version was the release name for an abandoned codebase, this page is kept for historical reference. Please see the Development RoadMap for the current development plan.
- 1 Overview
- 2 Development
- 3 Features
- 4 See also
Version 3.0 was in development several years ago and was marked as version v2.99.x. Upon release it was to be marked as version v3.0. The primary goals for this version were improved server side stability and security in an effort to minimize the impact of clients that have been modified to provide their users benefit ( aka, cheating ). Additional efforts were being made to extend the server side customization of the game. v3.0 was to be completely incompatible with all previous versions of the game. Users of v3.0 were only be able to play on 3.0 servers. This is similar to how v2.0 was incompatible with 1.10.
Development began on 3.0 on October 25th 2005. After an initial rush of changes, development stalled, as a number of bugs were found in the current release build of the time (v2.0.4). These bugs ,a number of graphical changes from trepan, as well as other problems necessitated the release of compatible v2.0.6, v2.0.8, v2.0.10, v2.0.12 and v2.0.14 versions.
The codebase was abandoned as the primary development target in May of 2011. It was moved to an exerimental branch in SVN in order to be a source of backports for 2.4.x
v3.0 was to have a number of features that make for a much improved gameplay experience.
The font system had been replaced and used standard TrueType fonts(TTF). This offered a number of advantages over the older bitmap based font system, including support for unicode character sets.
Users could set the default fonts that they wish to use on a per-locale basis so they can use the best fonts for their character set. (More info on how?)
Server Side Logic
A number of gameplay features have been moved from the client to the server, to ensure more consistent gameplay and prevent cheating over the internet, including;
- Flag operations (pickup, capture, identify, etc)
- Shot type
Initially much more was planned for the server side state but development problems prevent them from being implemented.
Game state and security checks
Many changes and enhancements have been made to the network protocol to prevent errors in the network message stream or shared game state.
- Links can be included in groups, with relative naming.
- Mesh faces can be used as teleportation link sources (with numerous options)
- Mesh faces can be used as team bases (must be flat tops).
- Mesh faces can be used as zones (must be flat tops).
- Meshes can contain weapon objects.
- World Text objects were been added (with numerous options)
- Dynamic Colors use a simpler format.
- Solid objects can specify the 'ricochet' property individually.
Changes had been made to the graphical quality settings. What was Experimental quality in 2.0.12 became High quality. Medium quality is between the old High and Medium, and Low remained mostly unchanged.
A new Experimental mode included new shot and flag graphics.
New Server List
The list of servers has been enhanced to allow tabbed browsing as well as improved searching and sorting.
HUD markers showing flag position, GM lock=on are now shown to players. The name and team of the closest target was also shown, along with a "friend or foe" system to help prevent teamkills. Servers were able disable these feature for all players if desired.
The BZFS API had been refactored but was not very complete, 2.4.0 introduced a new class based API that is forward comparable.
Lua BZFS API
The lua scripting language (http://lua.org), was built into the bzfs executable, and exposed almost all of the features from the C++ BZFS API (and a few that the C++ API does not have). It has the advantages of being easier to learn and write than comparable C++ code, and it can be embedded in world files. The main disadvantage is that it is not as fast as native c++ code.
A number of changes had been made to the game that will subtly affect gameplay.
Tank acceleration was always on. The "-a" server option had been removed, and the acceleration values were pulled from BZDB variables. These variables were_inertiaLinear and _inertiaAngular.
Clients used a synced timestmap and attempt to compensate tank positions for lag. This had the possibility of changing the way the game feels for players that are used to "leading" the target based on its lag.
The volume that defines a "hit" on a tank had been changed to be more consistent with the collision volume. It is now a box around the tank that can be adjusted by the server using BZDB variables.
A student had been paid as part of the Google Summer of Code program to evaluate and fix the backlog of reported bugs in the software. The intent was to have the overall effect of increasing the stability of the game.