Skip to content

Weapon Damage + Upgrade Boost — Design

Chris (2026-07-17): “boost all weapon upgrades and dmg.” Scoped via AskUserQuestion to the “Aggressive” option: the per-weapon power upgrade mod goes from ×1.25 to ×1.5 per stack, and every weapon’s base_damage goes up 30%.

What already exists (verified against source)

Section titled “What already exists (verified against source)”
  • WEAPON_MODS (sim/upgrade_system.gd:32-49) is a per-weapon table of [kind, magnitude] pairs. 14 of 15 weapons carry a ["power", 1.25] entry (the shared “+damage” upgrade); one outlier, scar_tissue, carries ["power", 1.20]. chronowell has NO power entry at all — its mods are duration/rate/heal only.
  • AIM_MODS (sim/upgrade_system.gd:53-54) is the always-available manual/aim weapon’s own mod list, also carrying ["power", 1.25].
  • data/bible.json has 15 weapons; 12 carry a nonzero base_damage (blade 3.0, pulse 3, nova 4, orbit 10.0, beam 0.8, turret 1.0, scatter 1.4, blaster 4, chalice 4.0, thunder_wake 20.0, railgun 6.0, wildfire 12.0, momentum_core 4). 3 carry base_damage: 0 by design, not omission:
    • scythe: deals damage as a percentage of the target’s CURRENT max HP (sim/weapon_scythe.gd:5, “all beings are equal… a % hit isn’t softened”) — a true-damage execute mechanic entirely independent of base_damage.
    • scar_tissue: a reactive weapon whose damage comes from a stack-based burst formula (sim/weapon_scar_tissue.gd:5-11), triggered by the pilot taking damage, not from base_damage.
    • chronowell: “Deals ZERO direct damage — it never touches sim.elemental_system.damage_enemy” (sim/weapon_chronowell.gd:8) — an intentional pure-utility/CC weapon, explicitly documented as dealing no damage by design.
  • Crit (+0.15 chance/stack, fixed 2.0× multiplier) and the 3 transformative mods (catalyst, overcharge, lingering) are separate systems, not touched by this request.

In scope:

  1. Every ["power", X] entry in WEAPON_MODS becomes ["power", 1.5] — this includes bringing scar_tissue’s outlier 1.20 up to the same 1.5 as everything else, for consistency with “boost ALL weapon upgrades” (flagged here in case Chris intended to preserve scar_tissue’s lower value specifically — his own review of the diff is the check for that).
  2. AIM_MODS’ ["power", 1.25] entry becomes ["power", 1.5] — the manual weapon’s own upgrade is a weapon upgrade too.
  3. Every nonzero base_damage in data/bible.json (the 12 weapons listed above) × 1.30.

Out of scope (a blind ×1.3 correctly no-ops on these, but doesn’t touch their real output):

  • chronowell stays at 0 — it’s an intentional zero-damage utility weapon; touching that is a design change (“give Chronowell damage”), not a boost to an existing number.
  • scythe’s %-max-HP execute value and scar_tissue’s reactive-burst formula constants are untouched — boosting those would mean editing their own bespoke per-weapon constants (different code, different risk), not this table/field. If Chris wants those boosted too, that’s a follow-up ask naming the specific constants (e.g. scythe’s HP-percentage), not implied by “boost all weapon upgrades and dmg.”

Changing base_damage/mod magnitudes does not touch RNG draw order (no new/removed/reordered SeededRng calls), so it can’t break same-seed reproducibility. It WILL almost certainly change the PINNED baseline hash/checksum in tests/test_determinism_survival.gd, because enemies die faster and pilots take different damage over a fixed-seed run, shifting downstream spawn/kill timing. This is a normal, expected re-pin (per this project’s own established convention — “each re-pin just confirms the sim still runs byte-identically for a given seed, not a break in determinism”), not a sign anything is wrong.

  • tests/test_upgrade_system.gd (or wherever WEAPON_MODS/AIM_MODS magnitudes are currently asserted, if at all — verify at plan-writing time): update any test that hardcodes the old 1.25/1.20 magnitude.
  • A weapon unit test (e.g. tests/test_weapon_blaster.gd) asserting base_damage reads the new bible.json value, if such an assertion exists.
  • Full suite + determinism re-pin (expected) + a soak sanity check that nothing anomalous happens with the new numbers (no invariant failures, no NaN/negative HP from a much bigger hit).