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

Difference between revisions of "DevelopmentGoals"

From BZFlagWiki
Jump to: navigation, search
(Authoritative Server State)
Line 51: Line 51:
 
* death and shot ends.
 
* death and shot ends.
 
* Player/world collision verification
 
* Player/world collision verification
 +
 +
Part of this is described in the [[Server Updated Shots]] design document.
  
 
===Server Side players===
 
===Server Side players===

Revision as of 23:46, 14 November 2007

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.

Tools

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

BZWorldBuilder

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

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

Services

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

List Server

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

Group Management

The current system of using phpbb to manage user groups is proving to be logisticaly dificult 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

Main Website

A more data driven site would be beneficial, as well as integrated user management.

Game Statistics

A more push oriented stats system is desired.

Codebase

libGame

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

Game server

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

Game Client

Graphics system split

The graphics subsystem of the game client needs to be split out and made into it's 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.