[VM] Play System: Complicated Mechanics

Librarian: HexCode
Post Reply
User avatar
HexCode
First Lieutenant
First Lieutenant
Posts: 926
Joined: 2019-09-30 18:54, Monday

[VM] Play System: Complicated Mechanics

Post by HexCode » 2021-04-04 01:40, Sunday

CONTENT LINKS
==============

Introduction
viewtopic.php?f=100&t=544#p8984

Atmospheric Conditions
viewtopic.php?f=100&t=544#p8985

Ground Conditions
viewtopic.php?f=100&t=544#p8986

Unit Reinforcements: Prestige Expenditure Computations
viewtopic.php?f=100&t=544#p9676

Unit Entrenchment
viewtopic.php?f=100&t=544#p8987

Unit Initiative In Combat
viewtopic.php?f=100&t=544#p8988

Rugged Defense Likelihood Determination
viewtopic.php?f=100&t=544#p11425

Submarine Class Unit Detection Mechanism
viewtopic.php?f=100&t=544#p11017


===================================================================

The topic's contents may be modified or progressively added upon as time goes by.

===================================================================

INTRODUCTION
=============

This topic should be of interest to Veteran Modders (VMs). It is assumed that the reader is already intimately familiar with the information featured here:

[NP] Introductory Documentation
viewtopic.php?f=100&t=531
Last edited by HexCode on 2021-10-18 18:32, Monday, edited 5 times in total.

User avatar
HexCode
First Lieutenant
First Lieutenant
Posts: 926
Joined: 2019-09-30 18:54, Monday

ATMOSPHERIC CONDITIONS

Post by HexCode » 2021-04-04 01:48, Sunday

ATMOSPHERIC CONDITIONS
========================

Identical atmospheric conditions prevail during an entire scenario turn (i.e., both player half-turns). To this effect, the player directing the Side which moves first is always the beneficiary of exact knowledge as to what atmospheric conditions will prevail during his opponent's half-turn.

Atmospheric conditions are determined by:

a) the Weather Geographical Zone (WGZ); and
b) the Calendar Month

during which scenario events unfold.

Weather Geographical Zones

There is a pseudo-WGZ which is invoked "on-the-fly", as required. There are also THREE (3) full fledged WGZs "traditionally" characterized by progressively increasing, inclement weather conditions. The value assigned to variable "Weather Zone" in file *.PGSCN fully specifies a scenario's WGZ (i.e., 0, 1, 2 or 3).

Fair Weather & Storm Fronts

A typical scenario's duration is subject to strictly alternating periods of

A) Fair Weather; and
B) a Storm Front.

No "gaps" are allowed here. Please note that a scenario may commence with a Storm Front already being present. The Boolean value assigned to variable "Current Weather" in file *.PGSCN controls this feature (i.e., value 1 implies "Fair Weather" while value 0 implies "Storm Front Presence"). Whether a Fair Weather or a Storm Front period, its Average Duration is expressed in full turns.

Throughout its entire duration, a Fair Weather period dictates Clear Skies. The pseudo-WGZ is always blessed with Fair Weather conditions (and, hence, Clear Skies) and no Storm Fronts whatsoever. For full fledged WGZs, a Storm Front period dictates anything but Clear Skies throughout its entire duration !

Precipitation Types

With regard to a typical Storm Front's full turn, there are always TWO (2) individually distinctive and collectively exhaustive possibilities:

1) Overcast Skies; or
2) Precipitation.

The likelihood of Precipitation is the probability complement of the likelihood of Overcast Skies.

When it comes to the very first Precipitation event to manifest itself during a typical Storm Front period, there are always TWO (2) individually distinctive and collectively exhaustive possibilities:

i) Snow; or
ii) Rain.

The likelihood of Snow is the probability complement of the likelihood of Rain. However, that first Precipitation event definitively coins the particular Precipitation type which may be witnessed during the remainder of the current Storm Front period. In other words, one can never experience both Snow and Rain during one and the same Storm Front period. That notwithstanding, one may experience Snow and Rain over the entire course of a scenario !

Data Descriptors

PGF's engine "understands" the following data descriptors:

(I) "Clear Time" = Average Fair Weather Duration (expressed in full turns).

(II) "Storm Time" = Average Storm Front Duration (expressed in full turns).

(III) "Storm Type" = If a first Precipitation event, likelihood that Precipitation (if any) will be Snow and not Rain for the entire duration of the current Storm Front (expressed in percentage terms).

(IV) "Storm Chance" = Likelihood of Precipitation and not Overcast Skies this full turn (expressed in percentage terms).

The values of the preceding variables are embedded within PGF's executable in Tabular Format.

PGF's engine somewhat randomizes duration on the basis of the corresponding Average Duration data.
Last edited by HexCode on 2021-05-18 06:11, Tuesday, edited 2 times in total.

User avatar
HexCode
First Lieutenant
First Lieutenant
Posts: 926
Joined: 2019-09-30 18:54, Monday

GROUND CONDITIONS

Post by HexCode » 2021-04-04 01:53, Sunday

GROUND CONDITIONS
===================

Absolute Prerequisite

Atmospheric Conditions
viewtopic.php?f=100&t=544#p8985

Ground Moisture

Ground moisture is represented by the Wetness Level (WL) the integer value of which may range anywhere from ZERO (0) to FIVE (5) inclusive. No values outside the aforesaid range are allowed.

WLs ZERO (0),ONE (1) orTWO (2) trigger dry ground conditions.

WLs THREE (3), FOUR (4) or FIVE (5) trigger wet ground conditions. If the current (or last) Storm Front is (was) a Rain one, the ground is muddy. If, on the other hand, the current (or last) Storm Front is (was) a Snow one, the ground is frozen.

Fair Weather

At the very start of a turn, a determination of Fair Weather (i.e., Clear Skies) for the turn immediately triggers a DEcrease in the WL by TWO (2) notches.

Rain Storm Front

At the very start of a turn, a determination of Overcast Skies (rain Storm Front is on) for the turn immediately triggers a DEcrease in the WL by ONE notch. On the other hand, a determination of Precipitation (i.e., rain) for the turn immediately triggers an INcrease in the WL by TWO (2) notches.

Snow Storm Front

At the very start of a turn, a determination of Overcast Skies (snow Storm Front is on) for the turn leaves the WL value unaffected. On the other hand, a determination of Precipitation (snow) for the turn immediately triggers an INcrease in the WL by TWO (2) notches.

Initialized WL Value & Implication

At the very start of a scenario, PGF's engine always initializes WL with value ZERO (0). This means that the ground can never be muddy / frozen on the first turn; even if it rains / snows. One full turn must pass before WL's value can ever get above 2.
Last edited by HexCode on 2021-05-18 06:13, Tuesday, edited 2 times in total.

User avatar
HexCode
First Lieutenant
First Lieutenant
Posts: 926
Joined: 2019-09-30 18:54, Monday

UNIT ENTRENCHMENT

Post by HexCode » 2021-04-04 01:58, Sunday

UNIT ENTRENCHMENT
===================

Basics

Units that do not move during their friendly half-turn are assumed to be "digging in", thus further enhancing their defensive stance. Entrenchment is expressed in Levels (ELs). Moreover, each unit class entrenches at a rate specific to that class (UCERs).

When a unit moves out of its hex, it automatically loses all its ELs. However, attacking without moving, mounting / dismounting without moving, resupplying / upgrading without moving and the like preserve the unit's hitherto accumulated ELs.

Each attack on an entrenched unit, whether successful or not in terms of inflicted damage / casualties, reduces its EL by one Level (negative ELs are not allowed).

Higher ELs translate into a defending unit being better able to withstand attacks upon it. Furthermore, they increase the likelihood that a non-ranged ground attacking unit will be subjected to Rugged Defense combat...

Weather conditions do not affect ELs.

Terrain Base & Maximum ELs

Each terrain type is assigned a Terrain Base EL (TBEL). Units starting their friendly half-turn on a hex of a particular terrain type automatically assume that TBEL in all instances where their hitherto attained EL is lower than the aforesaid TBEL. In such instances, the TBEL serves as an EL bonus.

Repeated attacks during a single half-turn upon a defending unit may even reduce the defending unit's EL below the underlying hex's TBEL.

Units can entrench up to a maximum of FIVE (5) ELs over the TBEL dictated by the underlying hex terrain type.

EXCEPTION: Tank class units are only allowed to attain a maximum of TWO (2) ELs irrespective of any other considerations.

TBEL values are hard-coded in PGF's executable. They are:

Code: Select all

Terrain Name                     TBEL Value

Fortification                    4

Non-Naval City                   3
Embarkation City                 3
Port City                        3

Forest                           2
Bocage                           2
Mountain                         2

Rough                            1
Port Facility                    1

All Other Terrain Types          0
EL Tracking

A unit's EL is tracked on the basis of Earned Entrenchment Points (EEPs) during the entrenching unit's half-turn(s). Here's the formula:

(EEPs) = (UCER) * (1 + (TBEL))

UCER values are hard-coded in PGF's executable. They are:

Code: Select all

Unit Class Name                 UCER Value

Infantry                        3

Recon                           2
Anti-Tank                       2
Artillery                       2
Air Defense                     2

Tank                            1
Anti-Aircraft                   1
Structure                       1
Land Transport                  1

All Other Unit Classes          0
A unit which has just been the beneficiary of an EL bonus does not get any additional EEPs for that particular friendly half-turn.

EEPs accumulate from friendly half-turn to friendly half-turn as long as a unit remains stationary on a particular hex and doesn't get attacked. When a unit's EEP total increases to some predetermined value or greater, the unit gains another EL and an equal number of EEPs are immediately subtracted from the unit's EEP running tally.

The "EEP to EL" conversion values correspond to additional ELs successively attained. They follow:

Code: Select all

Additional EL Attained            Conversion Value

First                              4
Second                             4 + 9 = 13
Third                             13 + 9 = 22
Fourth                            22 + 9 = 31
Fifth                             31 + 9 = 40
Last edited by HexCode on 2021-05-18 06:15, Tuesday, edited 2 times in total.

User avatar
HexCode
First Lieutenant
First Lieutenant
Posts: 926
Joined: 2019-09-30 18:54, Monday

UNIT INITIATIVE IN COMBAT

Post by HexCode » 2021-04-04 02:03, Sunday

UNIT INITIATIVE IN COMBAT
========================

Basics

The first step in any non-ranged combat (including ranged combat between Capital Ship class units, by exception) is to determine which unit gets to "shoot" first ! The determination of a unit's effective (i.e., combat-specific) initiative rating takes into account the following factors:

a) The unit's listed initiative rating;
b) Special unit combinations and circumstances (e.g., Rugged Defense);
c) The hex terrain being contested, if any (i.e., the hex the defending unit is on);

At the end of this intermediate stage, the unit's base initiative rating emerges.

d) The unit's current Experience Level;
e) Air attack on an Air Defense class unit; and,
f) A pseudo-random factor.

At the end of this final stage, the unit's effective initiative rating emerges.

It is extremely important to internalize the following fact; the "attacker" is the unit which initiates combat during its own half-turn and not necessarily the unit that eventually gets to "shoot" first. Consequently, the "defender" is the unit that is the target of the initiated attack irrespective of which unit eventually gets to "shoot" first.

Listed Initiative Rating

There is no "mystery" here. A unit's Listed Initiative Rating is prominently displayed on its Unit (Statistical) Information Screen.

Special Unit Combinations and Combat Circumstances

1) If an Anti-Tank class unit "attacks" a "defending" Tank or Recon class unit, the units' Listed Initiative Ratings are modified as follows:

The Anti-Tank class unit now sports a modified Listed Initiative Rating of ZERO (0);

The Tank or Recon class unit now sports a modified Listed Initiative Rating of NINETY NINE (99).

2) If an Ordinary Rugged Defense occurs, the "attacker" ends up sporting a modified Listed Initiative Rating of ZERO (0).

3) If a Sudden Collision (i.e., Special Rugged Defense, Surprise Contact or Out of the Sun) event occurs, the moving unit ends up sporting a modified Listed Initiative Rating of ZERO (0).

4) Barring Surprise Contact events, when two Capital Ship class units are involved in combat:

The "attacker" ends up sporting a modified Listed Initiative Rating of NINETY NINE (99).

The "defender" ends up sporting a modified Listed Initiative Rating of ZERO (0).

5) Barring Surprise Contact events, when a Submarine class unit is involved in combat:

The "attacker" ends up sporting a modified Listed Initiative Rating of NINETY NINE (99).

The "defender" ends up sporting a modified Listed Initiative Rating of ZERO (0).

Terrain Impact

The hex terrain upon which the "defender" is situated may further lower a unit's (possibly already) Modified Listed Initiative Rating. This is usually referred to as the Terrain Initiative Cap (TIC) effect.

Code: Select all

Terrain Type                         Initiative Cap Value

City, Mountain                        1
Swamp                                 2
Forest, Bocage, Fortification         3
Rough, Port Facility                  5
All Other Terrain Types              99
Note: A precise definition for "City" is: Port, Embarkation or Non-Naval City.

If a unit's (possibly already) Modified Listed Initiative Rating is greater than the relevant TIC value, the said unit's initiative rating is now set to equal the relevant TIC value itself.

At this intermediate stage, the unit's base initiative rating emerges.

Current Experience Level Impact

A unit's current Experience Level may further additively modify a unit's hitherto computed Base Initiative Rating. This is usually referred to as the Experience Initiative Bonus (EIB) effect.

Code: Select all

Unit Experience                    Initiative Bonus

No Stars                            0
1 to 2 Stars                       +1
3 to 4 Stars                       +2
All 5 Stars                        +3
Special Case: Air Attack on an Air Defense Class Unit

When an air unit directly "attacks" a "defending" Air defense class unit (not an Anti-Aircraft class unit) both "attacker" and "defender" automatically assume identical, notional, modified Base Initiative ratings to the exclusion of all other considerations.

Pseudo-Random Variation

Finally, the pseudo-random outcome of a 3-sided probabilistic die (d3) is added onto the unit's (possibly already) Modified Base Initiative Rating. Die outcomes 0, 1 and 2 are considered to be equiprobable.

At the end of this final stage, the unit's effective initiative rating emerges. :phew

Grand Comparison

The "attacker's" and "defender's" effective initiative ratings are now compared. The unit with the highest rating gets to "shoot" first. If the units' ratings are identical, the units get to "shoot" at one another simultaneously.
Last edited by HexCode on 2021-05-18 06:17, Tuesday, edited 2 times in total.

User avatar
HexCode
First Lieutenant
First Lieutenant
Posts: 926
Joined: 2019-09-30 18:54, Monday

UNIT REINFORCEMENTS: PRESTIGE EXPENDITURE COMPUTATIONS

Post by HexCode » 2021-05-17 02:47, Monday

UNIT REINFORCEMENTS: PRESTIGE EXPENDITURE COMPUTATIONS
=========================================================

Absolute Prerequisites

Unit Reinforcements: Typology
viewtopic.php?f=100&t=543#p9597

Unit Reinforcements: Prestige Costs
viewtopic.php?f=100&t=543#p9633

Computations

1) New Unit Purchases

Step 1.1: PGF's engine does not really need to compute anything here. It simply picks the intended unit type's value which is listed in data column entitled "Cost" (PGF programmer's choice; not mine) in file EQUIPMENT.PGEQP.

Step 1.2: PGF's engine compares the value obtained under Step 1.1 with the current value of the procurer side's Prestige Point Tally (PPT). Insufficiency of currently available Prestige Points (PPs) to "finance" the cost of the requested unit purchase blocks the purchase altogether. Otherwise, the request is implemented.

2) Unit Upgrades

Step 2.1: PGF's engine picks the intended unit type's value which is listed in data column entitled "Cost" in file EQUIPMENT.PGEQP.

Step 2.2: PGF's engine multiplies the value obtained under Step 2.1 by TEN (10).

Step 2.3: PGF's engine divides the value obtained under Step 2.2 by TWELVE (12).

Step 2.4: Because PGF engine's computations are confined to performing integer arithmetic, the value obtained under Step 2.3 is automatically ROUNDED DOWN, if necessary. EXCEPTION: If that value is GREATER THAN ZERO (0) BUT LESS THAN ONE (1), the engine automatically ROUNDS IT UP TO ONE (1).

Step 2.5: PGF's engine compares the value obtained under Step 2.4 with the current value of the procurer side's PPT. Insufficiency of currently available PPs to "finance" the cost of the requested unit upgrade blocks the upgrade altogether. Otherwise, the request is implemented.

3) Unit Over-Strengthening

Step 3.1: PGF's engine checks whether any SF procurement is possible to begin with. This requires the engine to check whether restrictions due to enemy unit adjacency and transportation mode would outright block the procurement request. If not:

Step 3.2: PGF's engine checks whether the unit is currently Under-Strength (i.e. it sports fewer than 10 SFs). If so, the computational process continues with Step 4B.1 in the sequel. Otherwise:

Step 3.3: PGF's engine checks whether the unit's SFs currently in excess of TEN (10) are GREATER THAN OR EQUAL to the unit's current Experience Level (EL). If so, the procurement request is blocked. Otherwise:

Step 3.4: PGF's engine picks the unit type's value which is listed in data column entitled "Cost" in file EQUIPMENT.PGEQP.

Step 3.5: PGF's engine divides the value obtained under Step 3.4 by TWELVE (12).

Step 3.6: Due to integer arithmetic, the value obtained under Step 3.5 is automatically ROUNDED DOWN, if necessary. EXCEPTION: If that value is GREATER THAN ZERO (0) BUT LESS THAN ONE (1), the engine automatically ROUNDS IT UP TO ONE (1).

Step 3.7: PGF's engine compares the value obtained under Step 3.6 with the current value of the procurer side's PPT. Insufficiency of currently available PPs to "finance" the cost of the requested unit over-strengthening blocks the procurement of that single SF altogether. Otherwise, the request is implemented.

4) Strength Factor Replacements

4A) Campaign Inter-Scenario Replacements

Step 4A.1: PGF's engine does not need to do much here; the situation not being an in-game one to begin with. If, in fact, the procurer has opted to receive "free" such replacements, the engine simply restores all of his Under-Strength Core units back to full TEN (10) SF strength status without in as much as touching the procurer side PPT's current value.

4B) Elite Replacements

Step 4B.1: PGF's engine checks the situationally maximum number of SFs which the currently Under-Strength unit might be able to procure, temporarily assuming that it has sufficient PPs to do so. For the purposes of this presentation, "M" will represent the aforementioned number.

Step 4B.2: PGF's engine picks the unit type's value which is listed in data column entitled "Cost" in file EQUIPMENT.PGEQP.

Step 4B.3: PGF's engine multiplies the value obtained under Step 4B.2 by "M".

Step 4B.4: PGF's engine divides the value obtained under Step 4B.3 by TWELVE (12).

Step 4B.5: Due to integer arithmetic, the value obtained under Step 4B.4 is automatically ROUNDED DOWN, if necessary. EXCEPTION: If that value is GREATER THAN ZERO (0) BUT LESS THAN ONE (1), the engine automatically ROUNDS IT UP TO ONE (1).

Step 4B.6: PGF's engine compares the value obtained under Step 4B.5 with the current value of the procurer side's PPT. Insufficiency of currently available PPs to "finance" the full cost of the requested unit's SF Replacements loops the computational process back to Step 4B.3 above where "M" MINUS ONE (M-1) is used instead of "M", and so on and so forth. Ultimately, current PP availability will determine how many Elite SF Replacements (if any) can be "financed". To this effect, PGF's engine will proceed with the requisite implementation.

4C) Regular Replacements

Step 4C.1: PGF's engine divides the value obtained under preceding Step 4B.5 above by FOUR (4).

Step 4C.2: Due to integer arithmetic, the value obtained under Step 4C.1 is automatically ROUNDED DOWN, if necessary. EXCEPTION: If that value is GREATER THAN ZERO (0) BUT LESS THAN ONE (1), the engine automatically ROUNDS IT UP TO ONE (1).

Step 4C.3: PGF's engine compares the value obtained under Step 4C.2 with the current value of the procurer side's PPT. Insufficiency of currently available PPs to "finance" the full cost of the requested unit's SF Replacements loops the computational process back to Step 4B.3 above where "M" MINUS ONE (M-1) is used instead of "M" and so on and so forth. Ultimately, current PP availability will determine how many Regular SF Replacements (if any) can be "financed". To this effect, PGF's engine will proceed with the requisite implementation.

User avatar
HexCode
First Lieutenant
First Lieutenant
Posts: 926
Joined: 2019-09-30 18:54, Monday

SUBMARINE CLASS UNIT DETECTION MECHANISM

Post by HexCode » 2021-09-10 01:27, Friday

SUBMARINE CLASS UNIT DETECTION MECHANISM
==========================================

Absolute Prerequisite

Submarine Class Unit Detection
viewtopic.php?f=100&t=543#p11016

Likely Mechanism

1) PGF's engine serially checks all instances of friendly Units / Cities / Airfields / Ports (UCAPs) which may detect a given Enemy Submarine Class unit.

2) Each UCAP is subjected to a P=0.50 probabilistic outcome determination.

3) If the determination's outcome is "Detection", the process immediately terminates with the Enemy Submarine Class unit having just been detected.

4) Otherwise, the next (if any) UCAP is subjected to a P=0.50 probabilistic outcome determination; and so on.

5) If all UCAPs have been subjected to a P=0.50 probabilistic outcome determination without having obtained a "Detection" outcome, the process ends with the Enemy Submarine Class unit remaining undetected.

User avatar
HexCode
First Lieutenant
First Lieutenant
Posts: 926
Joined: 2019-09-30 18:54, Monday

RUGGED DEFENSE LIKELIHOOD DETERMINATION

Post by HexCode » 2021-10-18 18:29, Monday

RUGGED DEFENSE LIKELIHOOD DETERMINATION
=========================================

Absolute Prerequisites

Unit Entrenchment
viewtopic.php?f=100&t=544#p8987

Unit Class Entrenchment Rate Table
viewtopic.php?f=100&t=551#p9046

Rugged Defense Event Prediction

Whenever an entrenched enemy target is subjected to a non-ranged attack initiated by a unit which is not the beneficiary of Rugged Defense (RD) avoidance privileges, the determination of the likelihood of RD actually happening is computed on the basis of an algebraic formula.

Prediction Formula Variables

Attacker's Experience Level (AExpL)
Attacker's Entrenchment Rate (AEntR)

Target's Entrenchment Level (TEntL)
Target's Experience Level (TExpL)
Target's Entrenchment Rate (TEntR)

Prediction Formula Ratios

Experience Ratio (ExpR) = (TExpL + 2) / (AExpL + 2)
Entrenchment Rate Ratio (EntRR) = (TEntR + 1) / (AEntR + 1)

Prediction Formula

Rugged Defense Percentage Chance = (N/D) * TEntL * ExpR * EntRR

where "N/D" is a calibration fraction. Derived values HIGHER THAN ONE HUNDRED (100) are automatically interpreted as EQUAL TO ONE HUNDRED (100).

Code Computations

PGF's engine does NOT do... high school algebra; rather, it performs integer arithmetic. To this effect:

Numerator = N * TEntL * (TExpL + 2) * (TEntR + 1)

Denominator = D * (AExpL + 2) * (AEntR + 1)

The engine then divides the Numerator value by the Denominator value. The division quotient is ROUNDED DOWN to the nearest integer.

Post Reply