This wiki is archived and useful information is being migrated to the main bzflag.org website

DevelopmentGoals

From BZFlagWiki
Jump to: navigation, search

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.

Tools[edit]

BZFlag has a number of sub-tool projects, each with their own needs.

BZWorkBench[edit]

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

ModelTool[edit]

Model tool needs to tessellate strips and fans into faces when the mesh is used with regular geometry.

Services[edit]

The public services offered by the project are also open for development.

List Server[edit]

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.

Group Management[edit]

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

Game Statistics[edit]

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.

Codebase[edit]

libGame[edit]

As much game code as possible needs to be generalized into a lib game and be shared by the client and server.

Cleanups[edit]

The current codebase has a number of files/functions that need to be broken up for better reuse and maintainability, these include:

  • bzfs.cxx
  • playing.cxx

Game server[edit]

Authoritative Server State[edit]

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

Need to be finished.

Server side logic for as many actions as possible[edit]

The game server should provide the logic for as many events/actions as possible, such as flag capturing, death on hit, and others.

Game Client[edit]

Graphics system split[edit]

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

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.

See Also[edit]

Server Updated Shots

Group Management System