©	The Ship Build Queue The Portable Host Version 3.2.3.5g  Jump to Table of Contents

• Introduction
• Build Queue Basics
• Player Activity Level (PAL)
• How PAL Affects Priorities
• Other Priority Issues
• Order Overrides
• Measurement of Activity
• Examples
• FIFO system
• PBP system

Introduction

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:

• The old FIFO system of PHOST 2;
• The well-known PAL system of PHOST 3;
• The all-new PBP system.

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

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

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

• The TAL for each player is reset to 0 on every turn.

• Each time a player performs one of the activities listed below, the number of points related to that activity (configured using the associated config option) is added to the player's TAL.

• Every new build order submitted by the player on that turn is given a priority boost determined by multiplying that player's current PAL with the SBQNewBuildPALBoost config option (and scaled by the PALPlayerRate config option).

• At the end of the turn, the player's PAL is decreased according to the setting of the PALDecayPerTurn config option. Then, the TAL is added to give the value of the new PAL for that player.

• The player's TAL is then multiplied by his scaling value, set with the PALPlayerRate config option. This allows activity levels to be related to build priorities in a player-specific way.

• The resulting scaled TAL value is multiplied by the SBQBuildPALBoost config option and divided by N^(SBQBoostExpX100/100) (where N is the number of build orders the player currently has pending). The resulting value is added as a priority boost to every build order of that player.

PAL * PALPlayerRate * SBQNewBuildPALBoost --> priority boost for new ship build orders
(PAL * (100-PALDecayPerTurn)/100) + TAL --> New PAL
TAL * PALPlayerRate * SBQBuildPALBoost / N^SBQBoostExp --> priority boost for existing ship build orders

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.

• At the default value 0, the number of orders does not matter. So it does not make a difference if a player builds only warships, or fills build queue slots with "junk" build orders just to get a good position in the queue. This is the behaviour of PHost 3.2 and earlier.
• At the value 100, the priority boost is divided by the number of build orders. That is, if the above Birdman player had only 2 build orders, each of them would get a 400-point boost. If he had also enqueued 18 additional ships (maybe some "junk"), each of them would only get 40 points -- so he would have to think twice before submitting a new build order.
• Values inbetween can be used to reduce the penalty each additional build order gives: at a value of 50, the boost is divided by SQRT(N), so having four times as many build orders reduces the boost to one half.
• You can also use values outside this range for, ummm, interesting effects.

Back to the index 

Other Priority Issues

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

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

Base #100  Priority 10000
Base #200  Priority 9000
Base #300  Priority 5000

Base #300  Priority 10000  (using PB1)
Base #100  Priority 9000
Base #200  Priority 5000

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

Examples

Simple FIFO Queue

PLIST

PALPlayerRate = 0
SBQPointsForAging = 500
SBQBuildChangePenalty = -1

Alternatively, just set BuildQueue to FIFO, see below.

Default Settings

  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

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) in which each player's top ships are comparable in combat, a FIFO strategy is a very good choice (and a lot less complex).

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, which is the basis of this new build queue system.

This document is maintained by The Portable Host Project (support@phost.de).