Skip to content

0048 — Pirate Ecosystem Dynamics: Self-Regulating Population

Status

Folded into SYSTEMS/pirate-ecosystem.md

Context

Pirate Holdings (ADR-0047) seed an initial pirate population per region but define no dynamics for what happens after a player clears them — leaving either static depletion (a cleared region stays empty) or static accumulation (an ignored region never worsens). Pirates instead behave as a self-regulating ecosystem: a weighted population score with a suppression-modulated target, virus-like daughter spawning from existing holdings, and tier-evolution of untouched holdings, all driven by a weekly tick against a 30-day rolling kill log.

The durable rule — current_population_score = sum of holding weights, with self-regulating spawn/decay — and all tables, worked examples, and algorithms live in SYSTEMS/pirate-ecosystem.md.

Consequences

Positive:

  • The pirate population is responsive to player action. A region that was dangerous stays dangerous if you ignore it; a region you've been clearing becomes safer (within the 20% floor); a region you neglect grows back.
  • The virus-spawn metaphor is mechanically simple but produces emergent behavior — pirate sites spread out from existing nests, lineage chains are auditable via parent_holding_id, and the universe has a sense of pirate territory that expands and contracts.
  • Tier evolution gives players a real reason to stay engaged with low-tier sites. A Camp left untouched for a month becomes an Outpost; ignored long enough and a Bubble-anchored Outpost becomes a Stronghold. "I should clean these up before they grow" is a real strategic choice.
  • The Cleansed-region state rewards systematic clearing with a 30-day "breathing space" before regrowth catches up. Players who fully clean a region get tangible recognition.
  • The 20% floor means the Frontier never feels empty. Even after sustained suppression, some pirate presence remains for narrative continuity.
  • All knobs (kill weight per tier, suppression decay rate, growth cap, evolution thresholds) are operator-tunable; balance tuning post-launch doesn't require schema changes.

Neutral:

  • One new scheduled service (weekly growth tick) and one new region-level state (pirate_ecosystem_state JSONB on the Region row).
  • New parent_holding_id self-FK on PirateHolding for lineage tracking.
  • New growth_eligible_at and last_damage_at_threshold_met_at columns on PirateHolding for evolution tracking.
  • Weekly tick is a single bulk-update transaction per region; even at 1,000 regions, the workload is small.

Negative:

  • A player who deliberately farms low-tier Camps for rep gain can be exploited by the system — kills inflate the suppression modifier, but the modifier decays over 30 days. A dedicated grinder could keep the modifier near the floor indefinitely. The 20% floor is the safety net; even at full suppression, ~7 weighted points of pirate presence remain (a few Camps), so the grind is bounded but possible. Acceptable: rep grinding is a game-economy concern, not an ecosystem concern.
  • The virus-spawn model can produce unintuitive geography — a Stronghold spawning a daughter Camp 5 hops away can put a pirate site near a player's home base. This is the design intent (pirates spread; they don't respect player territory) but requires player communication so it doesn't feel arbitrary. ARIA narration handles this: "I've detected new pirate activity 4 sectors from your last engagement — they're spreading out from the Carrion Court."
  • Tier evolution is slow (30+ days for Camp→Outpost) and may feel imperceptible to casual players. The promotion is the consequence of long-term neglect, not a frequent event. Operators can tune EVOLUTION_THRESHOLD if the cadence feels off.

Alternatives considered

Static respawn (rejected). When a holding is cleared, replace it with an identical-tier holding at a fixed delay. Rejected because it removes the player's sense of progress (you cleared something but it's just back) and produces no spread or escalation dynamics.

Per-player ecosystem (rejected). Track pirate population per-player-per-region rather than per-region. Rejected because (a) it conflicts with the shared-universe model — two players in the same region would see different pirate states, breaking realtime consistency — and (b) it dilutes the "you cleaned up the region" social signal.

Pure exponential growth without cap (rejected). Let pirates grow unbounded if neglected. Rejected because a runaway population would overwhelm new players entering the region and produce content density that doesn't fit the rest of the design (region capacity, NPC scheduler load, sector-defense surface clutter). The 1.5× cap preserves "more dangerous" without hitting "unplayable."

No tier evolution (rejected). Camps stay Camps forever; only spread, no upgrade. Rejected because it removes the long-term consequence of neglect — the universe doesn't get more dangerous, just spreadier. Tier evolution is what makes "leave them alone" a real risk.

Population modeled at galaxy level, not region level (rejected). A single galaxy-wide pirate population scoring. Rejected because cross-region effects would be confusing (clearing pirates in your home region shouldn't affect Frontier presence in someone else's region) and the local-region scope matches existing region-isolation patterns.

Daily tick instead of weekly (rejected). Run growth every UTC midnight. Rejected because daily growth would feel relentless and the math (tracking deltas, decay rates) gets fiddly at higher cadence. Weekly is enough for the dynamics to be visible without being intrusive.