[PHost Logo]© 

The Ship Build Queue
The Portable Host



VGA Planets has a maximum limit of 500 ships in play at one time. Once this limit is reached, new build orders at starbases cannot be fulfilled until an existing ship is destroyed, recycled, or otherwise removed from the game, thus freeing up a ship slot. When a free ship slot does become available, there are usually many starbases with build orders pending. A decision must be made as to which starbase will be allowed to build its ship and fill the free ship slot. This is one of the most vexing problems in the game and has been the cause of much debate.

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.

PHOST 3.3c offers three strategies for managing the build queue:

==> Note that most of this page is still talking about the PAL system. This page needs a re-write.

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, pre-configured strategy is invited to use one of the sample configurations described below.

Back to the index 

Build Queue Basics

Once the 500-ship limit is reached, every new ship build order (either through a regular starbase build or by cloning) is assigned a priority. This priority determines which build order will be the first to be fulfilled once a free ship slot becomes available. The rule is simple: the highest priority build order is the one that is fulfilled.

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.

Back to the index 

Player Activity Level

One of the main arguments behind some build queue management strategies is that the active player should be rewarded for his risks and thus be allowed to build ships at a faster rate than the passive player who simply stockpiles ships. To this end, PHOST attempts to measure the level of involvement of each player, under control of various configuration options.

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.

Back to the index 

How PAL Affects Priorities

On a given turn, each player accumulates a quantity known as the Turn Activity Level, or TAL. At the end of each turn, the player's TAL is added to his old PAL value to obtain the new PAL value. Both of these values can affect the priorities of build queue orders. The operation of these quantities is as follows. In summary, the actions of the TAL and PAL can roughly be described as follows: For example, the Birdman player engages one ship in combat and destroys it. The mass of the enemy ship was 320 KT. With the setting of PALAggressorPointsPer10KT set to 50, the Birdman player will receive 1600 points towards his TAL. The player's PALPlayerRate setting is 50, meaning he only uses 50% of his points, or 800 points, for boosting priorities. Assuming a value of 0 for SBQBoostExpX100 (which is the default, and the only possibility in PHost 3.2 and earlier), every build order that the Birdman player has in the build queue has its priority boosted by 800 points.

To encourage players to build only ships they really need, the SBQBoostExpX100 option allows to scale down the priority gain depending on the number of build orders a player has.

Back to the index 

Other Priority Issues

For every turn in which a build order remains in the queue and is not fulfilled, it is automatically given a boost in priority. This boost will be the same for all ships and is nominally 500 points (or the value of the SBQPointsForAging configuration option). What this boost does is ensure that any build order submitted on turn N will have a higher priority than a build order submitted on turn N+1, all other things being equal. For example, a build order submitted on turn #56 is given a priority of 499. Next turn, on turn #57, if this build order is still unfulfilled, its priority will be boosted to 999, while a new build order is given a priority of 499. Thus the first build order will have a higher priority, due to having been submitted first.

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.

Back to the index 

Order Overrides

Normally, the order in which your ships are built is the order in which you submit their build orders. The only effect of the priority build system is to determine the relative build order between different players. You can, however, change the order in which your own ships are built using the order override friendly codes. These planetary friendly codes are of the form PBn (where n is a number from 1 to 9, inclusive). A base with one of these codes "jumps the queue" and has its build order fulfilled prior to any base without a build order override, and prior to any base with a build order override using a higher number.

As an example, consider a build queue that looks like this (considering only your own build orders):

Over several turns, the priority values will increase but it will still be the case that the ship at  base #100 will be built first, followed by the ship at base #200, and finally the ship at base #300. Now, if the friendly code at planet #300 is set to PB1, the build queue will appear as follows (assuming priorities haven't increased): Note how base #300 has jumped to the top of the queue and all other bases have been "pushed down" in order. Priorities haven't changed, however. In a real game, the priority numbers will increase as usual, but what is important to note is that build order overrides do not affect your priorities, nor do priorities have any effect on build order overrides. In other words, you cannot change the order of ship builds relative to other players, you can only change the order relative to your own bases.

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.

These friendly codes can be disabled using the AllowPriorityBuild configuration option.

Back to the index 

Measurement of Activity

This section briefly lists the configuration options that link a player's activities in the game to his TAL, and hence, his PAL. For a more detailed description of each option, please consult the "Configuration Options" page.
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. If a planet was damaged then only the combat mass from the defense posts will affect the TAL (100kt base mass are ignored). 
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. If a planet was destroyed then only the combat mass from the defense posts will affect the TAL (100kt base mass are ignored). 
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. If a planet was destroyed then only the combat mass from the defense posts will affect the TAL (100kt base mass are ignored). 
PALShipMinekillPer10KT  Points for every 10 KT of mass when a ship is destroyed by a minefield hit.  
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. 
PALGloryDevicePer10KT  Points for every glory device that is detonated, related to the mass of the ship that exploded. Using this option, you can give more points for blowing up a heavy ship than for a small one. 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. Partial damage results in partial score awarded: damaging a ship by 20% gives you 20% the nominal points. Same-race and allied ships are not credited. 
PALGloryKillPer10KT  Points for every 10 KT of enemy ship mass killed as a result of a glory device explosion. If you damage a ship far enough that it explodes, you receive these points in addition to the normal PALGloryDamagePer10KT points. 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. 
PALIncludesESB If enabled, the PALAggressorPointsPer10KT, PALOpponentPointsPer10KT, PALOpponentKillPointsPer10KT, and PALAggressorKillPointsPer10KT options use the combat mass, including possible bonuses (Engine Shield Bonus, Fed Crew Bonus), for the computation. If disabled, these computations use the plain ship mass without bonuses.
Back to the index 


This section lists some example configuration settings to achieve certain queue management philosophies. Hosts are invited to use these values as starting points for their own explorations into "the optimal build queue management algorithm".

Simple FIFO Queue

The point behind this strategy is that whoever submits a build order first should have their ship built first. This is a simple and appropriate strategy for ship lists in which all players have ships that are comparable in combat (such as the PLIST[Remote] ship list). Appropriate settings for this philosophy are: All 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.

Alternatively, just set BuildQueue to FIFO, see below.

Default Settings

The default settings used by PHOST (if no configuration settings are given) are listed here. These settings attempt to reward active players by linking their activity points with priority boosts for both existing and new ship build orders. The settings are by no means "optimal" settings and you should not interpret these numbers as being anything more than a very rough estimate of how players should be rewarded for their activity.
  SBQBuildPALBoost              = 10
  SBQNewBuildPALBoost           = 10
  SBQPointsForAging             = 500
  SBQBuildChangePenalty         = 2147483647 # =2^31-1, can also be written simply as -1
  SBQBoostExpX100               = 0

  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                    = 5
Back to the index 

FIFO system

The FIFO system is simple: Build orders are performed in the order of their submission. Each turn, PHOST starts at a random starbase collecting build orders and pushing them on the queue.

When you want to use the FIFO system, all you need to do is to set BuildQueue = FIFO in pconfig.src. The other options are ignored in this mode (but must still be present right now).

For ship lists (such as PLIST[Remote]) in which each player's top ships are comparable in combat, a FIFO strategy is a very good choice (and a lot less complex).

Back to the index 

PBP system

The PBP system is similar to the build queue system in HOST. The basic idea behind it is that players can collect PALs resp. Priority Build Points, and later trade those points for ships.

When this system is used, players must decide which ships are important to them, and mark these as priority builds. This is done by giving the associated starbase a PBx friendly code. Each player can designate up to 9 priority builds this way (because there are nine PBx fcodes, that is. If you use one code twice, only one of them is accepted, so don't do that). As usual, PB1 is most important, PB2 second-most, etc.

When there is a free ship slot to fill, the player with the most PBPs can perform his most important build order. If he has no priority build (or all his priority builds were already performed), or his PBPs do not suffice to do the build (see below), tough luck: then, the player with second-most PBPs is allowed to fill that slot. And so on. When no priority build can be performed, the normal FIFO system is used.

Building ships costs PBPs, the heavier the ship, the more PBPs it costs. The PBPCostPer100KT option defines how many PBPs you need to build a 100 KT ship. There is a minimum cost, however: PBPMinimumCost. If the build order was a clone order, it costs even more PBPs; the PBPCloneCostRate can be used to scale this up.

An example probably helps to understand this. This example configuration can also be found in pconfig5.src:

  BuildQueue                    = PBP
  AllowPriorityBuild            = Yes

This enables the PBP system, and the PBx friendly codes. You should usually enable PBx here, but it makes sense to turn them off for the first so-and-so turns. Like HOST which does not perform priority builds until there are at least 450 ships in the game. Just remember to turn it on when the time is right.

  PBPCostPer100KT               = 200
  PBPMinimumCost                = 400
  PBPCloneCostRate              = 200

Assume you want to build a 150 KT ship. This would cost you 150*200% = 300 PBPs. Since the minimum cost is 400, that build will cost you 400 PBPs. If it were a clone, it would cost twice as much (400*200% = 800 PBPs).

Okay, and where do these PBPs come from? PBPs are good ol' PALs. And the PAL settings define how you get them. The suggested settings are

  PALDecayPerTurn               = 0
  PALPlayerRate                 = 100
  PALCombatAggressor            = 0
  PALAggressorPointsPer10KT     = 2
  PALOpponentPointsPer10KT      = 2
  PALAggressorKillPointsPer10KT = 8
  PALOpponentKillPointsPer10KT  = 8
  PALShipMinekillPer10KT        = 0
  PALCombatPlanetScaling        = 100
  PALCombatBaseScaling          = 150   # destroying a base gets more points
  PALShipCapturePer10Crew       = 0
  PALRecyclingPer10KT           = 10
  PALBoardingPartyPer10Crew     = 0
  PALGroundAttackPer100Clans    = 0
  PALGloryDevice                = 125   # Saber: 153, D19b: 96
  PALGloryDamagePer10KT         = 10
  PALImperialAssault            = 0
  PALRGA                        = 0
  PALPillage                    = 0

The basic idea is that destroying 1 KT mass gets you one point, building 1 KT costs you two points. Some actions do not contribute to ship destruction aka freeing ship slots; these should not be awarded points. But that's up to you; you could, for example, also have a PBP decay if you wish.

For a more elaborate description of the PBP system, see the PBP page at The Vagabund[Remote], which is the basis of this new build queue system.

Back to the index 
This document is maintained by The Portable Host Project[Remote] (support@phost.de).

Last updated 7 December, 2001