Skip to content

Combat Resolution

Design Goals

Each player controls a single character. Multiple players can group together and launch a shared expedition. Combat must resolve asynchronously and cheaply. Each player chooses their own loadout, supplies, and expedition rules before departure, then the server turns the combined group into outcomes.

See combat-and-skills-integration.md for the detailed phase model, encounter tags, skill checks, and formula templates. See combat-encounter-templates.md for concrete sample fights built from skills, encounter tags, and supply prep.

The core simplification rule is that combat should be easy to start with and hard to master. New players should succeed with presets, while advanced players gain edge through better skill coverage, better supplies, and better tag reading.

Core Combat Inputs

Each expedition resolution should read from:

  • character combat snapshot
  • expedition rule set
  • area and route modifiers
  • monster encounter package
  • supply state
  • injury and fatigue state
  • monster knowledge bonuses

No Separate Combat Setup

Combat should not ask players to arrange positions or choose a separate combat package before departure.

For group expeditions, the resolver combines each member's combat snapshot to derive overall group coverage. No player needs to manually assign roles or slots.

The resolver infers group behavior from:

  • each member's loadout-derived role coverage
  • shared expedition rules such as retreat threshold, consumable rules, and cargo priority
  • combined supplies and current condition state
  • encounter tags and route context

New players should be able to rely on role presets and simple expedition defaults.

Resolution Flow

  1. Build a route plan from origin to target and back.
  2. Roll route events using area threat, scouting, weather, and route knowledge.
  3. Generate encounter packages from area tables and current world state.
  4. Resolve each combat encounter through three player-facing phases: Approach, Clash, and Recovery.
  5. Apply injuries, morale shifts, item wear, and supply consumption.
  6. Continue to the next route segment or trigger retreat.
  7. Settle rewards, loot, knowledge, and contract results.

Encounter Types

  • simple skirmish
  • ambush
  • wave defense
  • hunt pursuit
  • boss chamber
  • escort defense
  • environmental hazard plus enemy pressure

Each encounter package should stay small. It only needs:

  • a goal
  • a few visible tags
  • one key phase
  • a short best-skill list
  • one dominant failure risk

Async Combat Model

Combat does not need per-second simulation. It should resolve in a small number of readable phase checks:

  • Approach: scouting, counters, opening control
  • Clash: pressure, guarding, status exchange, main outcome
  • Recovery: injuries, retreat quality, cargo and supply preservation

The resolver can still use substeps internally, but the player-facing model should stay compact.

Boss and Elite Rules

Bosses and elites should not only have larger numbers. They need unique mechanics, resistances, or expedition-wide pressure such as fear, poison zones, armor break, or supply drain.

They should still follow the same simple phase model, with complexity added through tags and scripted mechanics rather than through a totally separate combat ruleset.

Technical Model

Authoritative Records

Store:

  • expedition
  • expedition_member
  • expedition_supply_commitment
  • expedition_route_segment
  • encounter_seed
  • expedition_result_log

Deterministic Seed

At mission start, generate and store a seed. Use it to derive encounter order, rare event checks, and loot branches. This makes debugging, replay summaries, and dispute review much easier.

Group Commit Logic

For group expeditions, all members should lock before departure:

  • active build profile and loadout
  • supply contribution to the shared escrow
  • readiness state
  • share settings for rewards and costs

Once the expedition starts, replacements are not allowed unless the mission type explicitly supports reinforcements.

Durable Object Responsibility

Use one expedition coordinator for mutable expedition state while the run is active. That coordinator handles group joins before departure, readiness checks, and final settlement locks.

Resolution Timing

Do not simulate constantly while the player is away. Instead:

  • store projected segment end times
  • wake on completion alarm or player check-in
  • run the resolver in bounded batches
  • write append-only event results

Replay Summary

Players should receive a readable expedition report that lists:

  • route events
  • key combats by phase
  • injuries and recoveries
  • rare drops
  • map discoveries
  • reasons for failure if the mission went poorly

The report should explain the strongest reasons for the result, not dump every hidden modifier.

  • combat and skills integration
  • character progression and derived stats
  • monster family behaviors
  • supply consumption and hunger
  • knowledge and scouting
  • group contracts and shared rewards