Weapon-Target Matchup by the Data

"How powerful is this weapon?" is the wrong question. The right question is "How powerful is this weapon against this target?" An ATGM can kill a tank in one shot, but firing it at a single infantryman is pure waste. How do you model this matchup? The key is to put it in data, not code.

▶ Real simulation — a 155mm engagement striking a target. The top shows 'PHASE 5: ENGAGE' with fire events, target damage status, and rules-of-engagement (ROE) compliance, while thermal and other sensor views appear along the bottom.

Probability of Kill (Pk) by Target Type

For each weapon, the catalog records a probability of kill (Pk) against each target category.

Rendering diagram…

ATGM example: 0.90 vs armor / 0.20 vs infantry. The target's armor class is compared against the weapon's penetration rating, and effectiveness is derived automatically. This naturally bakes "firing an anti-tank weapon at infantry is inefficient" into the model — engagement outcomes align with doctrine.

In code, this matchup is just a Pk lookup and a salvo probability — two functions.

# single-shot hit prob Ph, n-round salvo -> at least one hit
def salvo_hit(Ph, n):
    return 1 - (1 - Ph)**n

# per-target kill: look up Pk from the weapon catalog
def kill_prob(weapon, target):
    return weapon["pk_vs"].get(target.armor_class, 0.0)   # ATGM vs tank=0.90, infantry=0.20

Extending the Domain with One Line

The real power of data-driven design is scalability. Because matchups live in the catalog, adding a new weapon or a new domain requires one catalog row, zero code changes.

Rendering diagram…

An engine built for ground engagements ran air-defense (SAM, AAM, CIWS) and anti-ship (ASM, naval guns) scenarios with zero new code, just additional catalog rows. "One engine, domains in data" is the engagement-model counterpart of the self-containment philosophy.

💡 Adding a weapon means registering in two tables — There is one trap. A new weapon must be registered in both the damage table (Pk vs each target type) and the ballistics table (how the round flies). Register in only one table and the weapon is classified as "unknown type," its fire is silently skipped, and damage is zero. This is the engagement-model version of a silent fail.

⚠️ An unvalidated matchup table is dangerous — Plugging in Pk values without empirical backing distorts engagement outcomes entirely. Use the abstract model to quickly screen candidates, then calibrate with measured penetration and kill rates from the physics simulation (see the Lanchester article) before trusting the numbers.

In a nutshell

📌 Weapon effectiveness is target-dependent — ATGM: 0.90 vs armor, 0.20 vs infantry. Storing that matchup as catalog data (pk_vs · armor_class) lets the same engine cover ground, air defense, and anti-ship engagements with zero code changes. One caveat: every weapon must be registered in both the damage table and the ballistics table to avoid silent failures.