![]() |
The Ship Build Queue |
PHOST's approach to managing the ship build queue once the 500-ship limit has been reached is consistent with its overall philosophy: empower the host to implement what he/she thinks is the best approach. Rather than trying to decide upon one best method of managing the build queue (and convincing others of its optimality) we have decided to implement a highly flexible system that allows for multiple, different approaches to the problem. The choice of which approach to use is up to the host.
The flexibility of PHOST's build queue management comes at a price, of course. There are a number of new configuration options that are used to tailor the operation of the build queue. The host who wants to fully understand all possible options is charged with reading the description of these options (and the rest of this file) and using them intelligently. The host that wants to implement a simple, preconfigured strategy is invited to use one of the sample configurations described below.
Please note that fans of
the PHOST 2 build scheme (the first-in-first-out strategy) can continue
to use this strategy even with the new priority system. One of the sample
configurations below shows how to effect this FIFO strategy. For ship
lists (such as PLIST
)
in which each player's top ships are comparable in combat, a FIFO strategy
is a very good choice (and a lot less complex).
On any one given turn, a new ship build order (that is, one that is not already in the queue) is assigned a priority in the range 0 through 499. The first new build order that PHOST sees is assigned a priority of 499, the next is given a priority of 498, and so on. PHOST looks for new build orders by starting at a random planet number, in the range 1 through 500. PHOST then looks at each planet in sequence, wrapping around from 500 to 1, looking for new build orders.
For example, on a given turn, PHOST starts looking for new build orders at planet #253. It finds a new build order at planet (with base) #296. This build order is added to the queue with priority 499. PHOST then finds another new build order at planet #427. This is given a priority of 498. PHOST finds no more new build orders up to planet #500, but then starts looking at planet #1 and upwards, finds a new build order at planet #156 and gives it a priority of 497. PHOST stops looking for new build orders at planet #252, one planet short of where it started. The next turn, PHOST will go through the same process but will start at a different planet, chosen randomly.
Various configuration options link actions in the game (such as destroying ships in combat) to a quantity known as the Turn Activity Level (or TAL). The TAL in turn contributes to a long-term estimate of the player's activity known as the Player Activity Level (or PAL). The TAL is computed anew every turn, while the PAL has "memory". Previous activity counts towards the current PAL although previous activity points decay over time.
The TAL is used to boost priorities of ships already in the queue. The PAL is used to boost the initial priority of new ship build orders. The host implements a particular build queue management strategy by modifying the importance of each action in the game on the TAL, and indicating the importance that the TAL and PAL have in modifying ship build priorities.
The Player Activity Level (PAL) is a single number that summarizes the player's overall history of activity. The Turn Activity Level (TAL) is a single number that summarizes the player's activity in a single turn. The TAL is computed anew each turn while the PAL has memory (see below for the actual formulas of computation). The TAL can boost the priorities of existing build orders, while the PAL can be used to boost the initial priorities of new ship build orders.
The effect of the TAL upon existing build orders is configurable with the SBQBuildPALBoost configuration option. The effect of the PAL upon initial priorities of new build orders is configurable with the SBQNewBuildPALBoost configuration option. The PAL can be caused to decay over time so that a burst of activity does not mark the player as being highly active forever. This decay is configurable using the PALDecayPerTurn configuration option.
There are two ways in which the PAL/TAL can affect build order priorities; both were mentioned briefly above. First, the player's TAL on a given turn can be used to boost all of his existing build order priorities. This would relate a player's activity with his likelihood of building new ships. Second, a player's current PAL would be used as a one-time boost for new ship build orders. This connection prevents the punishment of players who have a long period of activity and only submit build orders after that activity has ceased. Without boosting new build orders by the PAL, the player is penalized for not having submitted his build orders earlier, when his high level of activity would have boosted them.
This is known as a FIFO (First-In-First-Out) scheme and is a natural way of managing queues of items. The SBQPointsForAging config option can be modified as desired by the host to enable, disable, or otherwise alter this feature.
Another way that a build order's priority can change is if the build order itself changes. Normally, when a build order is changed, it is placed at the back of the queue. That is, it is removed from its present queue position and treated as a new build order. This behavior can be changed, however, using the SBQBuildChangePenalty configuration option. Simply put, this configuration option indicates the number of priority points to subtract from a build order when that order changes. If this value is 0, then it means that players can change build orders without any decrease in priority! Thus, they can upgrade the quality of their ships to be built right up to the time that the build occurs. Setting SBQBuildChangePenalty to -1 is the usual case, the build order will lose all of its priority points. (This configuration option is specified as an integer, and may take negative values, but it is treated as an unsigned integer in actual usage, so that the value -1 actually is interpreted as the largest possible unsigned number). The priority of a build order is never allowed to fall below 0.
As an example, consider a build queue that looks like this (considering only your own build orders):
Once a build order has been reordered using an override it is not necessary to maintain this special friendly code on subsequent turns. The new order is maintained in the build queue until a different override code possibly changes the order.
The override numbers 1 through 9 are used to set a relative order, where PB1 indicates the build order to be fulfilled first. Override codes need not be used sequentially. Two bases can be set to a specific order using PB1 and PB2, or PB1 and PB5, or PB8 and PB9, for example. Bases without override codes maintain their relative order but will always appear later in the build queue than any base with an override code. If two or more bases have the same override code, the base with the higher ID will be reordered and the other base(s) will have their override codes ignored.
Note that the
PBn friendly codes are considered special by PHOST and will, therefore,
never match for the purposes of combat, beam-gather, etc. Note also that
PB0 is not an override code and is not in any way a special friendly
code.
Finally, note that the PBn friendly codes are meant to mirror the same friendly codes in the HOST programs. Since the build queue in HOST is quite different from PHOST's implementation, the PBn friendly codes serve similar functions but have different effects on build orders.
Configuration Option | Activity |
---|---|
PALCombatAggressor | Points for being the aggressor in combat. Please see the "Order of Battle" page for the exact meaning of the word "aggressor". Basically, an aggressor is a ship or planet that initiates combat. This config option measures nothing but the initiation of combat (with a combat-capable ship, i.e., not a freighter). If the other ship/planet is owned by an ally (even if the combat level of alliance isn't granted) then no points are awarded. |
PALAggressorPointsPer10KT | Points for every 10 KT of mass destroyed in combat when the ship/planet was the aggressor. These points are pro-rated for any damage to the enemy ship/planet. If the enemy ship/planet is completely destroyed, the player gets full points depending upon the mass of the enemy ship/planet. If the enemy ship/planet is brought to 40% damage before the aggressor ship is itself destroyed, then the player gets 40% of the points he would have earned had he destroyed the enemy ship/planet. Again, no points are awarded if the two combatants are allies at any level. |
PALOpponentPointsPer10KT | Points for every 10 KT of mass destroyed in combat when the ship/planet was not the aggressor. This is the same as PALAggressorPointsPer10KT but applies when the ship/planet did not initiate the combat. |
PALAggressorKillPointsPer10KT | Points for every 10 KT of mass destroyed in combat when the ship/planet was the aggressor. Points are only awarded when the enemy ship is destroyed and there is no pro-rating based upon partial damage. |
PALOpponentKillPointsPer10KT | Points for every 10 KT of mass destroyed in combat when the ship/planet was not the aggressor. This is the same as PALAggressorKillPointsPer10KT but applies when the ship/planet did not initiate the combat. |
PALCombatPlanetScaling | Determines how the mass of a planet compares to the mass of a ship for the purposes of awarding points. If this option is set to 100, damaging a planet is worth the same as damaging a ship (per KT of damage). Setting it to 50, for example, means that each 10 KT of planetary damage is only worth half as many points as ship damage. |
PALCombatBaseScaling | Same as the PALCombatPlanetScaling option but it applies to planets with starbases in orbit. |
PALShipCapturePer10Crew | Points for every 10 crew members killed on a ship captured in combat. |
PALRecyclingPer10KT | Points for every 10 KT of mass for a ship that is recycled at a base or colonized at a planet. |
PALBoardingPartyPer10Crew | Points for every 10 crew members on a ship that was boarded and captured using the Privateer or Crystal boarding party mission. No points are awarded if the boarded ship's owner is an ally (at any level) of the boarding player. |
PALGroundAttackPer100Clans | Points for every 100 clans killed using a standard ground attack (not including Imperial Assault). These points are automatically multiplied by the defending race's ground defense bonus and divided by the attacking race's ground attack bonus. The attacking player need not completely remove the defender's clans from the planet to acquire points. The defending player receives no points. No points are awarded if the planet is owned by an ally (at any level) of the ship's owner. |
PALGloryDevice | Points for every glory device that is detonated. Only the player who owned the ship with the glory device receives points. |
PALGloryDamagePer10KT | Points for every 10 KT of enemy ship mass damaged as a result of a glory device explosion. Same-race and allied ships are not credited. |
PALImperialAssault | Points for performing an Imperial Assault mission. No points are awarded for planets belonging to allies (of any level). |
PALRGA | Points for performing a Rebel Ground Attack mission on an enemy planet. Same-race, unowned, and allied planets are not credited. |
PALPillage | Points for performing a Pillage mission on an enemy planet. Same-race, unowned, and allied planets are not credited. |
PALPlayerRate = 0 SBQPointsForAging = 500 SBQBuildChangePenalty = -1All other configuration settings (for build queue management) may be ignored. Ship build orders that are modified while in the queue are sent to the back of the queue.
SBQBuildPALBoost = 10 SBQNewBuildPALBoost = 10 SBQPointsForAging = 500 SBQBuildChangePenalty = 2147483647 # =2^31-1, can also be written simply as -1 PALDecayPerTurn = 10 PALPlayerRate = 100 PALCombatAggressor = 1 PALAggressorPointsPer10KT = 10 PALOpponentPointsPer10KT = 8 PALAggressorKillPointsPer10KT = 5 PALOpponentKillPointsPer10KT = 3 PALCombatPlanetScaling = 100 PALCombatBaseScaling = 100 PALShipCapturePer10Crew = 5 PALRecyclingPer10KT = 1 PALBoardingPartyPer10Crew = 3 PALGroundAttackPer100Clans = 4 PALGloryDevice = 5 PALGloryDamagePer10KT = 2 PALImperialAssault = 5 PALRGA = 5 PALPillage = 5Back to the index