Sea Ecosystem — Work History and What We Did

Library note (2026-07-19): This history is the output of development sessions; when added to the library, the files were renumbered: 11_Deniz_Seyahati14_Deniz_Seyahati_5e.md, 12_Deniz_Savasi15_Deniz_Savasi_5e.md, 12_Ticaret_ve_Meslekler16_Ticaret_ve_Meslekler_5e.md. In the text, "File 10" = Event System (file 13 in the library), "File 11" = Sea Travel (file 14). The world files (10_Dunya_Temelleri, 11_Dogal_Kaynaklar, kaynak_verileri.json, 3 SVGs) were NOT TRANSFERRED to the library — the current English versions in the library's 07_Dunya/ folder (10_World_Foundations, 11_Natural_Resources, resource_data.json; including the island revision) are authoritative.

What this document is for: A "sea ecosystem" was built tied to the D&D 5e (2024) homebrew world — travel, combat, trade, professions, and the subsystems connecting them. This document records the sequential story of that work, the decisions made, what the simulations showed, and why we did it that way. The next session (or future you) can look here to understand where things came from.


Overview

The sea ecosystem consists of three main systems + the subsystems connecting them. Everything was designed to work like a single organism: one system's output becomes another's input.

SystemFileStatus
Sea Travel11_Deniz_Seyahati_5e.mdRev 004 — core complete
Naval Combat12_Deniz_Savasi_5e.mdRev 004 — core complete
Trade and Professions12_Ticaret_ve_Meslekler_5e.mdRev 001 — core complete, deep layer skeleton

Core working method (at every step): Decisions were made through multiple-choice questions → evaluated for consistency → claims were validated with Python simulation → then written. The principle "unvalidated balance is not accepted" was applied throughout.


Chronological Story — What We Did, Why

1. Sea Travel Engine (foundation)

The first system built. Started with the question "What makes the sea feel different from land?"

Core built:

  • Core loop: Weather (±1 TD) → Voyage Die (d100) → Event → Ship Turn. Variable scale (zoom): zooms in to hourly detail on major events.
  • Voyage Die: d100 × TD0-5 threshold table. The sea translation of File 10's "luck die" philosophy. Validation: 20,000 sims, smooth S-curve (TD0 28% event → TD5 72%).
  • Ship status system: PHB stats as the base, with a status layer on top (fire/flooding). Severity/spread via DC-difference threshold (consistent with the critical system: 1-4 difference escalates, 5+ spreads). Cap 4.
  • Crew = action point pool: Base 2 (from OKs, breaks the death spiral) + 1-5 depending on ship type. Validation: 2,000 sims/tier, death spiral broken.

Important fix (Rev 002): Crew points were initially a fixed "3". But PHB crew numbers vary wildly (Rowboat 1 – Galley 80). The fixed value contradicted the "ship stats are the base" principle. Converted to a tier function (1-5) — chosen over log2/square-root candidates because it keeps the Sailing Ship at 3 and preserves the existing calibration.

2. Alarm Escalation (Rev 003)

The sea adaptation of File 10's Alarm principle (repeated threats aren't blocked, they escalate).

  • Alarm type tied to region: Authority (reactive) / Hunter / Curse (proactive). Doesn't convert to another type.
  • 0-5 counter: 1-2 frequency increase, 3-4 CR increase, 5 named pursuer.
  • Reactive vs proactive: Traveling clean in Authority waters keeps Alarm at 0; even lingering in wild/cursed waters accrues Alarm.

Important fix: The first calibration was too generous — even clean play in Authority waters reached a 56% pursuer rate (the opposite of design intent). Once the increase sources were reined in and the tier extended to 0-5, it hit the target: authority+clean 10%, authority+plunderer 85%, proactive+clean 37%, proactive+plunderer 95%. 5,000 sims/cell. This is a clear example of the "simulation catches design mistakes" principle — if we'd written it at the desk, it would have come out broken.

3. Naval Combat — Ship-to-Ship (Rev 001-002)

A separate system: how do ships fight?

  • Range backbone: Far/Medium/Near/Broadside — each range opens different axes ("gear" logic). Not all five axes at once, 2-3 active depending on range.
  • Parallel turn flow: Character action + crew action points; the captain can convert their turn into "command" (a two-layer bridge).
  • Maneuver & position tokens: 3 categories (Wind/Position/Speed) × tier, cap 3.

Validations:

  • Duration balance: The first calibration's battles lasted 9-14 turns (too long). Once the damage/HP ratio was fixed, ~90-94% of battles end in 4-8 turns. 3,000 sims/tactic.
  • Tactical depth (Rev 002): Once character actions were added, tactics became meaningful — guns 85%, sabotage 94%, broadside 76%, balanced 63% (K=0.6). Indecisive play is weakest.
  • Class gap (Rev 002): A sloop can't beat a man o' war even with a strong party (victory ~0%, escape ~15%, defeat ~85%). This is DELIBERATE — "ship tonnage is king".

Important honesty moment: The goal of "sloop gets a 5-10% victory rate" contradicted the constraint "man o' war is overwhelmingly superior". Three rounds were tried, the math didn't allow it. Rather than forcing a victory (which would break another balance point), it was honestly accepted. The "moment of fate/Nat-20" mechanic that didn't work was not added and abandoned — simplicity was preserved. An epic small-ship victory was left to the fiction layer (fleet, environment, sabotage mission).

4. Trade and Professions (Rev 001)

An economy built on top of the world project's resource system (21 resources, 8 regions).

Core decision — sea-first trade: Geography analysis FORCED this (not a preference): four small continents + Continent V in the open sea, even the interior of the main continent is broken up. Sea = primary (inter-continental), land = secondary (local).

  • Price formula: Base = (strategic value^1.6) × 10 × tier multiplier. Local = base × density multiplier.
  • Three constraints: Capacity (ship cargo), Saturation (~×0.80/repeat), Distance-risk (max 55% loss).
  • Validation: Full simulation with JSON data, voyage ROI ~52% (within the 30-60% target band). The critical measure is ROI, not raw margin.

Two simulation findings:

  1. Anomaly outside trade: Raw margin spiked to 214%, breaking the economy + already forbidden in the lore. Moved to the Smuggling profession (fixed both the math and the lore).
  2. The real balance lever is capacity: Cutting margin would kill cheap goods; limiting volume is both realistic and tied to ship stats.

Six professions (common skeleton + risk ladder + reputation + license): Hauling, Fishing, Salvage, Monster Hunting, Smuggling, Bounty Hunting. Each tied to an existing system.

Deep layer: Price fluctuation + processability are defined as a mathematical skeleton; content is [POST-LORE] — will be filled in once power centers are determined. The decision: "math now, content after lore".

5. Sea Monster Combat (Combat Rev 003)

Core gap #1: The Monster Hunting profession and all three systems were waiting on this, but there was no mechanic.

  • Monster class = complexity tier: Small (ship-like range) / Medium (+grapple) / Giant (multi-phase boss).
  • Four monster-specific hazards: Dive (every class), Grapple (medium+), Multi-part + Size Pressure (giant).
  • Bridge to the boss system: Giant monsters are designed with the existing boss system; a 6-step roadmap was added.

Important fix: The size pressure balance settled after three attempts. A giant monster without a telegraph instantly sank the ship 19-35% of the time. A mandatory telegraph, when it protected too much, gave a free turn (win rate jumped to 58%). The right point turned out to be the boss system's "telegraph turn = half damage" rule — instant sinking dropped to 11%. 4,000 sims/matchup. A proven rule (telegraph) worked again.

"Fair prey" economy: Sailing vs giant 36%, warship vs giant 93% — the message is "bring a warship to a kraken". The same philosophy as trade's ROI and naval combat's class gap.

6. Provisions & Water Economy (Travel Rev 004)

Core gap #2: "Voyages take months" but distance was an abstract number.

  • Single abstract counter: Provision Day (no bookkeeping).
  • Graduated warning chain: Rest pressure → crisis events → slow exhaustion (1 level per 3 days, prevents a death spiral).
  • Trade tie-in: Base provisions separate + extra provisions take up cargo space (goods vs. provisions decision).
  • Fishing: 40% chance of a partial rescue (not guaranteed).

Important fix: The first attempt was too soft (provisions 1.3× → no tension at all, even a negligent party arrived without trouble). Once the multiplier was pulled to 1.15 + events to 30%, the sweet spot was found: a negligent party struggles (avg 1.0 exhaustion, 14% severe), a reasonable party arrives safely (0.0) but feels rest-pressure tension in ~30% of the route. 3,000 sims. The goal "don't punish reasonable play, hit negligent play" held.

7. Closing the System Loop (Combat Rev 004)

Core gap #3: The systems pointed to each other, but some links were incomplete. This was consistency stitching work, not simulation.

  • Combat→Alarm: Monster combat leaves no trace; pirate/authority combat depends on region+witness (+1 for every clash in authority waters, +1 for a survivor/fleeing enemy in the open sea).
  • Action→Alarm (legitimacy axis): Alarm is determined by behavior, not profession — legitimate action −1, unlawful +1. Resolved the contradiction "unlicensed bounty hunting = unlawful".
  • Combat→Salvage: Every sunk ship leaves a wreck (value based on tonnage).
  • Monster→Harvest: Monster carcasses are a separate system (Monster Parts, distinct from wreck — organic vs. man-made).

Seven systems, one organism:

  • Travel ↔ Trade: Routes are the transport network; events/Alarm affect price and risk.
  • Provisions ↔ Trade ↔ Fishing: Extra provisions take up cargo (goods vs. provisions); fish is a survival tool in a crisis.
  • Combat ↔ Monster Hunting: Combat is the hunting engine; monster carcasses are harvested.
  • Combat ↔ Salvage: Wreck generation.
  • Combat/Action ↔ Alarm: Loop closed (§6C).
  • Alarm ↔ Smuggling/Bounty Hunting: Legitimacy axis.
  • Monster ↔ Boss System: Design bridge.

Recurring Design Principles (proven in this work)

  1. "Data is Normal, difficulty/depth is a layer": This principle from the boss system was applied to trade (core+deep layer), provisions (soft core+difficulty modifier), and monster combat (small/giant tier).
  2. Telegraph turn = half damage: Came from the boss system, solved instant sinking in monster combat.
  3. Graduated complexity: Simple threat, simple rule; big threat, rich rule (monster classes, provision chain).
  4. Simulation catches design mistakes: Alarm (too generous), provisions (too soft), monster (instant sinking), trade (anomaly breakage) — all were broken at first calibration, sim fixed them.
  5. Sometimes the goal is unreachable: The sloop victory example — when one goal contradicts another constraint, honestly accept it rather than forcing it.
  6. Behavior determines outcome: Alarm's legitimacy axis; an extension of the "the character doesn't act stupid" principle.

Library Integration (2026-07-19)

  • The module was added under 08_Ev_Kurallari/ as a multi-file module: 14_Deniz_Seyahati_5e.md · 15_Deniz_Savasi_5e.md · 16_Ticaret_ve_Meslekler_5e.md (the package's internal 11/12/12 numbers were moved to 14/15/16 in the library; 10-13 were already taken in the library).
  • Cross-references inside the main files were updated: "File 10" → Event System (file 13), "File 11" → file 14, 10_Dunya_Temelleri/11_Dogal_Kaynaklar10_World_Foundations/11_Natural_Resources (07_Dunya). This history and the handoff prompt are preserved as historical documents (the old numbers are kept, with explanation).
  • Shared documents were named with the module's first number: 14_Deniz_Ekosistemi_TARIHCE.md (this file — decision log) + 14_Deniz_Ekosistemi_DEVIR_PROMPTU.md.
  • The package does not contain a version snapshot; the revision history is in the "Revision Notes" sections at the end of the main files. Future snapshots will be added to the _yedek/YYYYAAGG_deniz-ekosistemi-surum-arsivi/ folder.
  • Locked decisions (the handoff prompt's "Locked Decisions" section) are binding — calibrated by simulation, not changed unless the user requests it.