StarFleet is an interactive multiplayer network based game for UNIX workstations running the X11 windowing system. StarFleet is a 2 dimensional space game along the same lines as xtrek/netrek. There the similarities end.
Ships in StarFleet are constructed from 16 different types of systems, from transporters to impulse engines to phasers. There is no limit on the number or combination of systems carried on a ship. For instance, a ship can have a number of different shields that extend over one or more of its six sides, and even overlap. Damage is done to ships on a system-by-system basis. So, for instance, one or more of a ship's engines can be damaged, while the rest of the ship may be fine. Or, for example, the systems on the side of a ship facing an enemy may be damaged heavily while the systems on the other sides could be untouched. A ship is destroyed when its hull is completely destroyed.
Power is an important concept is StarFleet. For every "turn", or tick of the server clock, there must be enough power provided by the engines to move the ship, charge the shields and weapons, and power systems. If there is not enough power to cover all these needs, power is allocated in a priority specified by the player.
Repair works in a similar way. There is only a certain amount of repair that can be accomplished in a server tick. This amount is based on resources carried by the ship and number of living crew. Systems must be repaired to a certain level to function. If not repaired fully, their function will be scaled by their damage. So, for instance, a damaged phaser cannot fire as far, and a damaged engine does not generate as much power. Repair priority can be set by the player, so that, for instance, shields are repaired before weapons, or engines before shields, and so on.
The StarFleet universe can be very large. The system is designed so that a large number of ships can be operating within a universe divided up into quadrants and sectors. The locations and names of suns are read in from a universe config file at startup. Around these stars orbit planets whose distance from their star, orbital period, and size are also read in from the config file. The goals and size of a game can change based on the layout and size of the universe.
StarFleet is designed to be configurable in the extreme. There are currently several major types of config files governing such diverse things as the universe layout, ship parts, ships, server behavior, and client window placement and key bindings.
At present there are 3 races: Federation, Klingon, and Romulan; and 111 distinct ship descriptions ranging from starbases to tugs. Naturally, the number and types of races are configurable as are the ships.
The systems currently implemented are as follows:Move crew/marines/resources/minerals to and from planets and other ships.
Reduces a ship's visibility.
Used to control drones and send identification to other players.
Generate power to be used for charging weapons, shields and powering systems.
Generate power and move ships around below warp speed.
Generate power and move ships around at warp speed.
Detect the existence and race/ship type of other ships.
Detect the status and damage of systems on other ships.
Convert power into charge used to protect ships from damage.
Locking beam weapons that do damage to other ships.
Locking beam weapons that exert force on other ships.
Move in a straight line until near enough to explode, or run out of time.
Lie in wait for something to come near.
Tracking weapons that can be fired at a single target.
Tracking weapons whose target can be changed during flight by the ship.
Missile weapons whose direction and speed are controlled by the ship that fired them.
A StarFleet ship can contain any number of these systems covering any side or combination of sides.
The StarFleet functionality is divided among 3 executables:Displays information received from the server in a number of windows and sends information to the server based on player input.
Controls the physics of the universe as well as getting information to and from the client and robot.
Controls the actions of ships not controlled by players, ship creation, and planet economy initialization.
This window displays the relative positions of the player's ship and other ships nearby as well as any phaser, tractors, or missiles that the client can see. The view can be zoomed to different levels to show detail or the overall picture.
This window graphically displays the current status of each system that can be seen on a ship. Status for a system consists of such things as current damage, permanent damage, charge, whether the system is ON or ACTIVE, and what arcs (sides) that system exists in.
This window graphically displays the shield status of each of 6 sides of a ship as well as weapon readiness.
Displays information on a ship such as type, name, player, class, a bitmap of the ship, what race the ship belongs to, and what race IFF the ship is broadcasting.
Displays transporter settings and allows the player to control such things as what is being transported and to where.
Displays status information on the currently selected drone launched from the ship.
Lets the player select the order in which systems on the ship are repaired.
Lets the player select the order in which systems receive power.
Displays messages from other players.
Each window has a number of resources that control its behavior and appearance. Windows can also have "functions" that are bound to keys or mouse buttons. The binding of keys and buttons as well as resource settings is controlled by the client configuration file. Functions (or actions) are bound to keys on a window by window basis. So, for instance, the binding "8 goto-impulse-speed 80" would bind the action of going to impulse speed 80 to the key "8". The client config file also supports macro definitions that combine multiple actions that can be bound to a single key, or used in other macro definitions. For instance we have a macro to turn on and activate all systems on a ship, and macros to fire torpedos in complex salvos.
The StarFleet client provides a straightforward interface to windows, so programming new windows for StarFleet and including them in clients will not be a problem. New window contributions will be encouraged.
The StarFleet robot can be thought of as a collection of many different robots, each controlling a part of the whole. Each robot is constructed of routines to handle its creation and deletion, and an update routine to be called periodically. In addition, each robot can register itself to receive "events" such as ship creation, ship destruction, a player joining, messages from players, or messages from other robots. At present there are only four robot types implemented:
There is one empire robot per race in the game. This robot handles ship creation, creation of other robots, setting up planet economies, etc...
This robot controls a ship (preferably one with weapons) and attacks any enemy ship that comes close enough to the star system it guards.
This robot moves from planet to planet along a route set by the empire robot that created it.
There are a great many possible robots that can be implemented to perform different tasks. The robot executable is designed to allow many different robots written by different people to interact and operate in the same universe. Robot contributions will also be encouraged.
The StarFleet server controls ship and missile movement, planet economy updating, ship system updating, intership visibility, ship to ship messages, and getting information out to players and the robot.
The server has its own config file to control basic behaviors of the universe such as ship speeds (i.e. what does warp 1 mean in terms of movement), whether or not a player is allowed to change ships without logging out, and how many ticks per second the server will generate. Any basic server behavior changes are intended to go into the server config and be selectable as an option. New server behavior will be encouraged as long as it can be made selectable in the server config.