This page describes the development goals for the project. It is a set of desired features, problem areas, wishlist items that define the general direction that the developers feel the project should be taken in.
Please see Development RoadMap for a more detailed list of the development plan.
- 1 Tools
- 2 Services
- 3 Codebase
- 4 Game server
- 5 Game Client
- 6 See Also
BZFlag has a number of sub-tool projects, each with their own needs.
BZWB is a world/map editor that was completed for the 2007 Google Summer of Code program that BZFlag participated in. It is mostly functional but lacks a number of features, including.
- A UI that is usable.
- Mesh support
Model tool needs to tessellate strips and fans into faces when the mesh is used with regular geometry.
The public services offered by the project are also open for development.
The list server that is in use now is considered by many to "suck". A new list server/authentication system that can work using some sort of distributed network system to allow for redundancy would be greatly desired.
Proposals have included:
- Re-writing the existing php list server to be more efficient.
- Using MYSQL syncing features to split up the server.
- Using LDAP for authentication
- Moving away from PHP/Apache to a real compiled daemon.
- Moving away from HTTP to a more efficient TCP protocol.
The current system of using phpbb to manage user groups is proving to be logistically difficult given the large number of servers and the groups that their server owners desire. A more user centric group management system would be a large help.
A full spec for the system can be found at Group Management System
A more push oriented stats system is desired. The concept of having pages poll the list of running servers to get stats data is not desirable.
Proposals have been;
- Include a standardized plug-in that pushes data to various stats sites.
- Include more detailed stats with the game servers' list server update pushes.
- Provide a common "data dump" page on the list server so that external stats sites don't have to poll data.
As much game code as possible needs to be generalized into a lib game and be shared by the client and server.
The current codebase has a number of files/functions that need to be broken up for better reuse and maintainability, these include:
Authoritative Server State
The game server needs to keep full track of where every player and every shot is. This state needs to be pushed out as the authoritative state to all clients. The server needs to also verify all input according to the current game's rules. This state needs to include at least the following;
- Player position
- shot positions and paths
- death and shot ends.
- Player/world collision verification
Part of this is described in the Server Updated Shots design document.
Server Side players
Need to be finished.
Server side logic for as many actions as possible
The game server should provide the logic for as many events/actions as possible, such as flag capturing, death on hit, and others.
Graphics system split
The graphics subsystem of the game client needs to be split out and made into its own module that can be optionally built in. This will help standalone bots.
Graphics Engine Evaluations
Existing third party graphics engines/libraries need to be evaluated to see if they would provide the game with significant features. Engines such as OGRE, Crystal Space, and Open Scene Graph look promising.