BZFlag version 3.0 is the next planned release of BZFlag.
- 1 Overview
- 2 Development
- 3 Version Number Change
- 4 Features
- 4.1 Fonts
- 4.2 Server Side Logic
- 4.3 Game state and security checks
- 4.4 BZW Format
- 4.5 Graphics
- 4.6 New Server List
- 4.7 HUD Markers
- 4.8 BZFS API
- 4.9 Lua BZFS API
- 4.10 Server Administration
- 4.11 Gameplay Changes
- 4.12 Build System
- 4.13 Bug Fixes
- 4.14 ChangeLog
- 5 Known Issues
- 6 Release Date
- 7 Misconceptions about V3.0
- 8 See also
Version 3.0 is currently in development and marked as version v2.99.x. Upon release it will be marked as version v3.0. The primary goals for this version are 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 are being made to extend the server side customization of the game. v3.0 will be completely incompatible with all previous versions of the game. Users of v3.0 will 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.
Version Number Change
v3.0 is the first version to use the new version numbering system. The 3.0 release initially began as the 2.1 development line, with the intent of being released as version 2.2. Part of the way through development, however, the versioning number scheme changed and the development revision changed from 2.1 to 2.99. With previous releases the minor version number in the version triplet (major.minor.revision) represented protocol and client compatibility. With 3.0 compatibility is instead reflected in the major version number. This new scheme gives more "room" to deal with minor packaging revisions and patch release updates.
v3.0 has a number of features that make for a much improved gameplay experience.
The font system has been replaced and now uses standard TrueType fonts(TTF). This offers a number of advantages over the older bitmap based font system, including support for unicode character sets.
Users can now 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
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 now be included in groups, with relative naming.
- Mesh faces can now be used as teleportation link sources (with numerous options)
- Mesh faces can now be used as team bases (must be flat tops).
- Mesh faces can now be used as zones (must be flat tops).
- Meshes can now contain weapon objects.
- World Text objects have been added (with numerous options)
- Dynamic Colors now use a simpler format.
- Solid objects can now specify the 'ricochet' property individually.
Changes have been made to the graphical quality settings. What was Experimental quality in 2.0.12 is now High quality. Medium quality is between the old High and Medium, and Low has remained mostly unchanged.
The new Experimental mode includes 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.
If HUD markers showing flag position, GM lockon are now shown to players. THe name and team of the closest target is also shown, helping prevent teamkills. Servers can turn off this feature for all players if desired.
The BZFS API has been reviewed and re-factored for 3.0 and includes a number of new events and functions.
Server Side Players
The API has experimental support for server side players (bots).
Custom Flag Names
The API may define new custom flag names using any strings desired. The ammount of logic that can be processed for custom flags is limited.
HTTP based plug-ins
The networking system for BZFS now allows for the support of HTTP (and other ) connections. A number of plugins have been made to take advantage of this new feature, such as;
BZFS API Versioning
The versioning system in the BZFS API has been redone, and now event data classes are versioned for forward computability. Custom plug-ins that were written for v2.0.x must be updated to use the new classnames before they will work with v3.0.x. This should only be a one time change as the new classes are versioned and will remain the same in future releases. All standard plug-ins that ship with the bzflag source code have been updated.
Lua BZFS API
The lua scripting language (http://lua.org), is now built into the bzfs executable, and exposes 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.
Some changes have been made to help you server administrators.
The Webadmin plug-in allows server owners to manage many aspects of the server from a standard web browsers.
Local authentication ( /identify ), has been removed from the game, servers can use global authentication services for all authentication needs.
A number of changes have been made to the game that will subtly affect gameplay.
Tank acceleration is now always on. The "-a" server option has been removed, and the acceleration values are pulled from BZDB variables. These variables are _inertiaLinear and _inertiaAngular.
Clients now use a synced timestmap and attempt to compensate tank positions for lag. This can change 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 has been changed. It is now a box around the tank that can be adjusted by the server using BZDB variables.
No TK Option
A new server option (-noTeamKills) is available that will prevent players from killing their teammates.
Much effort has been put into making the bzflag source tree easier to compile on various OSs. The makefile build system has been updated and attempts to detect as many items as possible from the host System. The windows build system has been updated to be compatible with Visual Studio 2008 Express Edition that is freely available. When possible, copies of third party libraries are included with the source code.
A student is being paid as part of the Google Summer of Code program to evaluate and fix the backlog of reported bugs in the software. This will have the overall effect of increasing the stability of the game.
A lot of stuff needs testing, and probably doesn't work.
As is always the case for major updates to BZFlag, 3.0 will be released when it is done. It is possible that the release will occur in the first quarter of 2011, or the third quarter of 2020.
Misconceptions about V3.0
There have been a few misconceptions in the community regarding what this new version will and will not do. Most of this is simply due to the exceptionally long development time, or comments being taken out of context.
V3 will do everything Server Side, including shots
This is untrue. While more things have been moved to the server, shoots and hits are still handled by the client. Shots and hits will not be moved to the server until the code can be shown to maintain the level of response time that players have come to expect.
V3 will use more bandwith and be laggy
V3 does a better job of handling network traffic to and from players. Many messages have been reduced in size. Server side handling of some events, (like flag grabs) have actually removed some messages from the network stream. Network performance should be similar to V2.x. In some cases, lag compensation may even improve apparent performance.