![[PHost logo © John W. Smith]](../image/logo-small.gif){kind=logo}
PHost - Build Queue
PHost 4.1h
| Build Queue |
Index
Introduction
The original 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 becomes available, there are usually many starbases with pending build orders. 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.
(v4.0:) PHost 4 (as well as HOST999) allows up to 999 ships in the game. This delays the ship limit, but does not avoid it.
The list of pending ship builds is called build queue. PHost offers three strategies of managing the build queue. These strategies and their parameter are discussed here.
Build Queue Basics
PHost maintains a list of pending build orders. This list is remembered between turns.
Each turn, PHost scans all starbases for new ship build orders. These are placed into the ship build queue. This scan starts at a random starbase, so that low-Id starbases don't have advantages: every base has the same chance to be chosen first. The new orders are generally appended to the end of the build queue, where they wait until all orders before them are processed.
After collecting build orders, PHost attempts to build new ships by looking at the head of the queue. As long as enough ship slots are free, the whole queue can be processed immediately, so that build orders are performed in the same turn they were submitted in, during the ship building phase. As soon as all ship slots are used up, build orders start to accumulate in the queue.
The build queue mode (BuildQueue) decides in which order to perform the builds. Therefore, each build order is associated with a priority. The highest-priority order is performed first.
Players can affect these priorities using their build points (Player Activity Level, PAL). Build points are awarded for risky game actions: the more active you play, the faster you can build. The build points collected in one turn are called Turn Activity Level (TAL).
Normally, the order in which your ships are built is the order in which you submit your build orders. You can designate some build orders as Priority Builds to have them performed earlier than the others.
To use Priority Builds, the AllowPriorityBuild config option must be enabled. You can then use the PBn friendly codes to affect the order of build.
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.
Changing Build Orders: When you change a build order before the ship is built, the new build order normally starts walking the build queue anew, as if the previous order had never been there. PHost can be configured to allow the new order to inherit some of the old order's priority using the BuildChangeRelativePenalty option. That option specifies how much priority a changed build order loses compared to the previous one, and defaults to 100% (=complete loss). At a value of 25, for example, a build order would lose only one-fourth of its priority, and therefore start in the front quarter of the queue instead of at its end.
Historically, there also is an option SBQBuildChangePenalty which specifies a fixed penalty. That option only works in PAL queue mode, see below. It specifies a penalty given in addition to BuildChangeRelativePenalty.
PAL Queue
This is the original build queue system of PHost 3. The ship build queue is entirely driven by priorities. Build points (Player Activity Level, PAL) directly translate into a priority for your ships. The ship which has the highest priority will be built first.
Build orders newly enqueued will get a priority related to your total player activity level:
PAL * PALPlayerRate% * SBQNewBuildPALBoost |
In addition, build orders gain priority each turn from your turn activity level (TAL, build points received this turn):
TAL * PALPlayerRate% * SBQBuildPALBoost * scale + SBQPointsForAging |
The scale factor is there to encourage players to build only ships they really need. Mathematically, it is
1/N ^ (SBQBoostExpX100 / 100) |
where N is the number of build orders the player has. The SBQBoostExpX100 values have the following meanings:
- At the default value 0, the number of orders does not matter. When you get a TAL of 800, each priority is increased by 800 (assuming a PALPlayerRate and SBQBuildPALBoost of 100%). So it does not make a difference whether a player only builds important warships, or fills build queue slots with "junk" build orders just to get a good position in the queue. This is the behavior of PHost 3.2 and earlier.
- At the value 100, the priority boost is divided by the number of build orders. When you have two pending build orders, the above 800 points would turn into a 400-point boost for each order. If you had 20 build orders instead, each of them would get a mere 40 points only.
- Values in-between 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.
In addition to the PAL points, every build order receives SBQPointsForAging points each turn. This way, build orders which are waiting for a long time tend to have a higher priority than new ones.
When you change a build order, it will be given a penalty of SBQBuildChangePenalty (in addition to BuildChangeRelativePenalty). The default value is 2147483647, that's almost "infinity" in computer terms. Because no build order will ever reach such a priority, changed build orders will start to walk the build queue anew as if they were completely new orders. By lowering this value, you can lower that penalty.
Priority Build with a PAL Queue
The PBn codes simply rearrange your build orders. A starbase with one of these friendly codes jumps the queue and has its build order fulfilled prior to any of your bases without a build order override, and prior to any of your bases with a build order override using a higher number.
Let's assume you have three build orders:
Base #100 Priority 10000 Base #200 Priority 9000 Base #300 Priority 5000 |
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):
Base #300 Priority 10000 (using PB1) Base #100 Priority 9000 Base #200 Priority 5000 |
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 ordering is maintained in the build queue until a different override code possibly changes it again.
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.
FIFO Queue
The FIFO system is the simplest strategy of them all. Build orders are performed in the order of their submission -- First In, First Out. Build points are ignored here.
When a ship slot is free, PHost simply builds the build order which was submitted to the queue first.
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). PHost automatically maintains priorities so that the oldest order always has the highest priority.
For ship lists (such as PLIST![[Remote]](remote.gif){kind=small}
) in which each
player's top ships are comparable in combat, a FIFO strategy is a
very good choice (and a lot less complex than the others).
Priority Build with a FIFO Queue
Like in PAL mode, the PBn friendly codes simply re-arrange your build orders. See there for more information.
PBP Queue
The idea behind the PBP system is that players can gather activity points (called PBPs here, but they are nothing else than good ol' PAL points), and later trade these points for ships. This system is similar, but not identical, to the system implemented in HOST.
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 PBn friendly code. Each player can designate up to 9 priority builds this way (because there are nine PBn fcodes. If you use one code twice, only one of them is accepted, so don't do that). PB1 is most important, PB2 second-most, etc. Unlike in the other build queue modes, you must keep the PBn codes on your bases until your ship was built.
Every turn, the first free ship slots are given to players ready to pay for it using their priority points. The player with most PBPs gets the first slot, until all slots are used up, or until no more priority builds exist. All ships built during this phase will cost priority points. If a player is granted a priority build but has not designated one, or he has not enough points to build his highest-priority ship, he is skipped.
If some ship slots still remain after all possible priority builds are processed, ships are built in FIFO order, oldest build order first.
Priority Build with a PBP Queue
Building a ship using a Priority Build friendly code 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.
For example, let's assume you want to build a 150 kt ship, and the configuration uses the default values:
PBPCostPer100KT = 200 PBPMinimumCost = 400 PBPCloneCostRate = 200 |
According to PBPCostPer100KT, the cost would be 150*200% = 300 points. Since the minimum cost is 400, you'd have to pay 400 points for building that ship. If that build order were a clone order, it would cost even twice as much.
When a ship is cloned, build points are deduced from the starbase owner. This may not be the same player as the owner of the ship being cloned (and thus, the owner of the new ship) if the ship is using a planet-level alliance.
Note that PHost doesn't force you to do a priority build. If you have most PBPs in your game, but do not use a PBn friendly code, you keep accumulating points (for a really huge battleship, maybe). In contrast, HOST forces you to do a priority build in this case.
Note that the PBn friendly codes are always
active in PHost (subject to the AllowPriorityBuild
config option), no matter how many ships there are.
If you use PBn early in the game, you will spend PBPs
for that ship, even if there were enough ship slots to build the
ship normally.
Build Point Details
This section describes how a player's actions translate into build points.
Basics
Each turn, players gather turn activity level. Turn activity levels are summed up to yield a player activity level. In order to keep players active (instead of resting comfortably on their gathered points), PAL is reduced by a certain percentage: points decay when not used.
New PAL = Round((Old PAL - Points Used) * Decay Factor) + TAL Decay Factor = 1 - (PALDecayPerTurn/100) |
Old PAL is the player activity level you ended the previous turn with; at the start of a game, everyone has zero PAL.
Points Used is the number of points used for priority builds, in PBP mode. In other queue modes, points are not "used up", so this is zero.
TAL is the sum of the points earned for various actions, see next section. Points cannot be used in the same turn they are won. If you get hundreds of points by winning a battle, you cannot use these points until next turn. This makes building a little more predictable, as you know beforehand how many points you have to spend, and can re-arrange your build orders if required.
Actions with Rewards
With the PAL system, you generally reward people for risky actions. The default configuration reflects that and gives points for many things. The numbers have otherwise just been pulled out of a hat; nowadays there exist much better configurations than PHost's internal defaults.
With the PBP system, you generally reward only actions that lead to destruction of ships, and thus make ship slots available. It is very common to configure the game such that building an N kiloton ship costs twice as many PBPs as destroying it.
With the FIFO system, build points are not used, so the values of the PALxxx options does not matter. You may still use it as some kind of activity score.
Combat
Note that no points are awarded when the opponents are allied. It doesn't matter which alliance levels are granted, all that matters is whether they're allied or not.
PALCombatAggressor = 0 |
Points awarded for being aggressor in combat. This is a fixed amount of points. See order of battle for what it means to be an aggressor. Basically, an aggressor is a ship or planet that initiates combat.
PALAggressorPointsPer10KT = 2 PALOpponentPointsPer10KT = 2 |
Points awarded for every 10 KT of enemy mass encountered in combat. Aggressor and opponent can receive different amounts of points. These points are pro-rated for damage done to the enemy. When you completely destroy the enemy, you'll get the full points according to this option (plus the points from the next two options). When you damage the enemy by 40%, you'll get 40% of the points you'd get for destroying him.
PALAggressorKillPointsPer10KT = 10 PALOpponentKillPointsPer10KT = 10 |
Points awarded for every 10 KT of mass destroyed in combat, when you were the aggressor/opponent. When a planet was destroyed, then only the combat mass from the defense posts will affect the TAL, the base mass of 100 KT is not counted.
PALShipCapturePer10Crew = 5 |
Points for every 10 crew members killed on a ship captured in combat.
PALCombatBaseScaling = 50 PALCombatPlanetScaling = 80 |
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.
PALIncludesESB = Yes |
If enabled, various bonuses (Engine-Shield bonus, Fed bonus) are included in the computation of combat points. When disabled, this uses the hull mass only.
Boarding
PALBoardingPartyPer10Crew = 3 |
Points for every 10 crew members on a ship that was boarded by the Privateers or Crystals. No points are awarded if the boarded ship's owner is an ally of the boarding player.
Glory Device
PALGloryDevice = 100 PALGloryDevicePer10KT = 0 |
Points for detonating a Glory Device. These points are awarded to the owner of the Glory Device ship. With the first option, you can give a fixed number of points per Glory ship (the traditional way). You can use the second option to give mass-related points. For example, with PALGloryDevice = 50 and PALGloryDevicePer10KT = 3, detonating a 120 kt Glory Device ship would give 50 + 3*12 = 86 points.
PALGloryDamagePer10KT = 2 |
Points for every 10 kt of enemy hull mass damaged by a Glory Device. These points are awarded to the owner of the Glory Device ship, and are scaled by the damage inflicted. Ships owned by that player or one of his allies are not credited.
PALGloryKillPer10KT = 0 |
Points for every 10 kt of enemy hull mass destroyed by a Glory Device. These points are awarded to the owner of the Glory Device ship, and are given in addition to the damage points. Ships owned by that player or one of his allies are not credited.
Ground Attack & co
PALGroundAttackPer100Clans = 100 |
Points for every 100 clans killed using a standard ground attack (i.e. not imperial assault). These points are automatically multiplied by the defender's ground defense factor, and divided by the attacker's ground attack factor (that is, killing Lizard clans gives you more points than killing Bird Men). The defending player receives no points. No points are awarded if the planet is owned by an ally of the ship.
PALImperialAssault = 100 |
Points for performing an Imperial Assault. No points are awarded if attacker and defender are allied.
PALPillage = 10 |
Points for performing a Pillage mission on an enemy planet. Same-race, unowned or allied planets are not credited.
PALRGA = 10 |
Points for performing a Rebel Ground Attack mission on an enemy planet. Same-race, unowned or allied planets are not credited.
Miscellaneous
PALRecyclingPer10KT = 4 |
Points for every 10 kt of ship mass for a ship that is recycled at a starbase or decommissioned at a planet.
PALShipMinekillPer10KT = 0 |
Points for every 10 kt of hull mass destroyed by a mine hit. These points are awarded to the player who owns the mine field.
(v3.4c:) Points are computed with three fractional digits precision, i.e. exact. At the end of the turn, the fractional part is discarded. PHost versions up to 3.4b would truncate after each step of the computation.
Last updated 31 May 2015.