RFC - Subfleets
Ralf "Prolator" Laue
Last modified: Mon Jun 18 00:35:32 CEST 2001
General framework for Subfleets (class TSubFleet)
This first section is about the general framework for subfleets. It explaines all mechanisms which are defined and implemented in the pure virtual ancestor class TSubFleet. It also mentions the methods which are only defined in TSubFleets. The actual implementation and further description of them is given in the following sections together with the descriptions of the rules used in the derived classes.
(green means at least started)
- the fleet belongs to: The parent of a subfleet (a TFleet object) is saved as TLink<TFleet>. The subfleet has to be added to its fleet with the TFleet::Add method. The fleet the subfleet belongs to can be changed with the method TFleet::TransferSubFleet. Furthermore you can get a pointer to the "parent" fleet with the method GetFleet. Upon destruction of the subfleet the "parent" fleet is automatically informed about the destruction of the subfleet.
- the ship type is of: The ship design the subfleet is of has to be set at creation; the constructor expects a pointer to it as parameter. It is saved as TLink<TShipDesign>). The ship design is automatically informed about the new existing subfleet (which makes the ship design unchangeable). Upon destruction of the subfleet the ship design is also informed about the destruction of the subfleet (which can make it changeable again). It is possible to exchange the old ship design with a new one , but only through the auto upgrade mechanism (for more information see there).
- number of ships: The number of ships cane be set and read out simply with the methods SetNumberOfShips and GetNumberOfShips. If SetNumberOfShips is given the value 0, it creates a fatal error, because that doesn't make sense
- autoupgrade: You can set a new ship design (method SetAutoUpgrade) as upgrade design. This automatically tells the subfleet to upgrade at the next opportunity. The upgrade will be done, when the method CommitAutoUpgrade. This method also infroms you (afterwards) whether an upgrade was planned. If it was planned, it is commit and it returns true. If not it returns false. With the method CancelAutoUpgrade you can cancel an outstanding auto upgrade. With the method GetUpgradeDesign you can get the design the subfleet is to be upgraded, if there is an upgrade planned. With the method GetUpgradeCosts (has to be implemented in the derived rule classes) you can get the costs for upgrading and it returns a bool value, whether there us an upgrade planned.. So the mechansim which checks i.e. at planets whether there is an auto upgrade outstanding, has to check with GetUpgradeCosts and get the costs. Then it has to check, whether the player has enough resources and if yes, let him pay and commit the upgrade.
- autoretire: A subfleet has a flag which determines, whether it should be retired automatically at the next opportunity. This flag can be set with the method SetAutoRetire and can be deleted/unset with the method CancelAutoRetire. The mechanism which is responsible for checking whether the subfleet wanst to be retired, can check the flag with the method ancelRetire. If the subfleet is to be retired, this mechanism has to destruct it as usual with the destructor (the destructor informs the fleet and the ship design about the destruction of the subfleet).
- repair subfleet: With the method GetRepairCost you can get the cost for a repair of all damages on hull, armor and other equipment. The cost for new fighters, SP weapons and ammuntion will not be included. The actual repair of the subfleet can be committed with the method RepairSubfleet. Again ammunition, fighters and SP weapons will not be filled up.
- experience: This is just implemented with the methods SetExperience and GetExperience, which set and read out the experience of the subfleet. Which consequences experience has, is up to the battle engine, but I suggest, that the performance of a subfleet increases with experience and that the average is taken, if subfleets are merged
- max hit points of the hull: The method GetMaxHullHP just reads out the hit points of the hull of the ship design and mulitplies it with the number of ships.
- max hit points of the armor: The method GetMaxArmorHP just sums up all hit points of all armor items of the ship design regardless of their type and multiplies this number with the number of ships in the subfleet.
- max hit points of the shields: The method GetMaxShieldHP just sums up all hit points of all shield items of the ship design regardless of their type and multiplies this number with the number of ships in the subfleet.
- actual hit points for hull: The method GetActualHullHP returns the complete amount of hit points the hulls of the subfleet still have. This method has to be implemented in the derived classes.
- actual hit points for armor; the actual process of damaging will be going on inside TSubFleet. It gets informed, with what weapon and how strong it got hit and calculates then the damage (and breaches). The BIG question is, how we handle ship design with two (or more) different kind of armor with different values.
- value for amount of fuel
- value for amount of ammunition
- value for amount of fighters
- value for amount of SP weapons
- cargo space: With the method GetCargoSpace you can get the amount of cargo space (which is also equal to the amount of cargo bay items; each cargo bay item has one unit cargo space, the rest is adjusted with the mass and volume of the item). The return value is just an integer value; the implementation of the cargo space with TSubstanceHold is done on Fleet level.
- battle orders (attack nearest, flee, protect(x))
- range of the long range (FTL) scanners: How the range is calculated and in which units is up to the implementation. It is only defined that you have to give the scanner type as parameter and that the range is returned as double.
- fuel scoop capacity
- has colonization module: With the method IsColonizer you can get the information whether the ship design of the subfleet contains at least on colonization module. What you do with this information is up to the code, which handles the actual colonization. For example, it could get this information and if positive it decreases the number of ships by one and colonizes the planet.
- range of the long range (FTL) jammer
- get mine laying capacity
- mineral mining capacity: With the method GetMiningRate you can get the mineral mining rate of the subfleet. It is simply the value of the ship design multiplied with the number of ships in the subfleet.
- maximum FTL speed
- fuel consumption at a certain speed
- FTL engine breakdown probability
- distance the subfleet can move in one turn with a given speed
Basic rules used in TSubFleetBasic
In this section the actual implementation of the basic subfleet implementation (TSubFleeBasic) is explained. First the basic assumption for the rules:
- STL engine power is measured in 10kW: that (approximatly) the power to accelerate 1 metric ton with 1G (10m/s²)
- FTL engine power is measured in light years/turn
- Distances and ranges on the star map (for FTL travel) are measured in lightyears (LY)
- One shot in a battle goes like this: The battle engine asks the shooting subfleet for a weapon, its damage, its type, its hit probability and modificators (targeting computer, experience). Then the battle engine calculates how many shots hit. The it informs the hitted subfleet about the hits, their number and weapon type. The subfleet has 4 groups of ships (each 25%). The hits are distributed like this: group 1 gets 0% of the hits, group 2 gets 16.6% of the hits, group 3 gets 33.3% of the hits and group 4 get 50% of the hits. When the subfleet is destroyed to a small size (say 6 ships), the hits get equally distributed. In one group the damage gets distributed equally until it is destroyed. Then tehy are (somehow) distributed into new 4 groups. The hits can hit all armor items equally and the damage is then modified through the armor. If the damage of one shot is > 25% of the armor hit points theer is a chance of a breach. This chance is equal to the efficiency of the armor (small efficiency = armor effective against this weapon). The breach is put to the hit possibilities: Example: design with 2 armors type A and 3 armors type B (one armor of type B has a breach). The shot has 2/5 chance to hit armor type A, 5/10 chance to hit armor type B and 1/10 chance to hit the breach. A hit in a breach means direct hull damage. Else the hull is not damage befor the armor at this part is destroyed. How shields work, no idea yet
- FTL engines use fuel like proposed in Jeremy's text. The fuel consumption increases quadratically with speed increase
- In contrary to Jeremy's propsal the reaction engines burn 1mg of fuel/anti matter. Or they don't use anti matter as fuel.
Still open
- many things I don't remember or which didn't come yet to my mind ;-)
Now finally the explainations to the methods/values (again green means already implemented):
- costs for the upgrade: The cost for upgrade are 150% of the costs difference between the designs. If the new design is cheaper the cost is 0, but you don't get a refund. Until now, if the new design is in at least one substance cheaper than the old design, it is handled as whether there are no costs.
- range of the long range (FTL) scanners: You give the type of scanner as tScannerType and the range is calculated with this formular:
range = sqrt( sqr(range1)+sqr(range2)+...+sqr(rangeN) )
- repair and repair costs: no idea yet
- actual hit points for hull: not done yet
- actual hit points for armor: not done yet
- value for amount of fuel
- value for amount of ammunition
- value for amount of fighters
- value for amount of SP weapons
- range of the long range (FTL) jammer
- get mine laying capacity
- maximum FTL speed
- fuel consumption at a certain speed
- FTL engine breakdown probability
- distance the subfleet can move in one turn with a given speed
Battle Tokens (class TToken)
A battle token is derived from TSubFleet, is initialized from a TSubFleet object at the begin of a battle and has these additional values (it can still happen, that values/methods are moved between TToken andTSubFleet):
- armor breaches (they are closed after battle)
- temporary shield points
- shot buffer
- position on the battle board
- last target (enemy subfleet)
- max STL acceleration (for battle)
- short range scannning
- get weapons (somehow) (including targeting computer)
- HitSubFleet( weapon type, DP ):
- get battle/short range jammer
- get fighter launcher
- get SP launcher
Stuff, that didn't fit yet
- damage in a subfleet could be distributed in 4 (or 10...) different ranges: each 25% of the subfleet have 0%, 25%, 50% and 75% damage respectively. The damage the subfleet is getting is distrubuted in 4 categories: 25% of the ships get 0 hits, 25% get 1 hit, 25% get 2 hits, 25% get 3 hits (or similar)
- Cargo on fleet level (implemented as TSubstanceHold with n cargos (volume -1 m³) substances inside