Missions and Expeditions¶

Mission Philosophy¶

Missions are the main container for async action. They should bundle travel, encounter risk, supply consumption, timing, and rewards into one understandable commitment.

Dynamic events should feed directly into mission generation so the board reflects current world conditions instead of static categories alone.

Many of these should become event-flavored variants when local conditions change, such as blight relief gathering, storm salvage escort, refugee supply runs, or den-clearing hunts.

See expedition-types.md for the detailed breakdown of what each expedition category is meant to test, reward, and risk. See ../combat/loadouts-and-safety-rules.md for the simplified launch setup model, ../../tech/expedition-generation-model.md for board-generation rules, ../../tech/unified-board-item-and-player-contract-model.md for shared board-item structure, and ../../tech/expedition-acceptance-and-settlement-model.md for acceptance and settlement rules.

Mission Board Generation¶

Mission boards should be generated from live simulation state, not from static quest pools.

Each refresh should consume three direct inputs:

town_urgency_score from town shortages, route pressure, event pressure, and project priority
event_severity_score from active event instances in the board's scope
control_window_score from active or previewed town-control windows

Those inputs should directly affect which expedition types appear, how urgent they are, how long they stay on the board, and what kinds of rewards they emphasize.

Board Source Behavior¶

town board: prioritizes shortage relief, route recovery, civic projects, and local safety work
event board: prioritizes response vectors for the active event, with more cards as severity rises
guild board: prioritizes control-window scoring work, civic stabilization, and strategic preparation
regional caravan board: prioritizes deliveries, escorts, and route surveys when deficits or disruption rise

Direct Input Consequences¶

high town urgency should suppress low-impact routine work in favor of gather, escort, caravan, survey, and rescue offers that address the real deficit
high event severity should spawn multiple event-flavored mission variants instead of one generic emergency card
active control windows should create board work that directly contributes to influence, convoy safety, public works, and contested-route control

Offer Reasons¶

Every mission should carry a machine-readable reason for appearing, such as food shortage, mine collapse, washed road, or active control window. The board UI can expose one primary reason tag so players immediately understand why the mission exists.

Refresh Triggers¶

Boards should regenerate when:

town reserve bands change
route pressure changes materially
an event spawns, escalates, or resolves
a control window enters preview, active, or closing state
a public work begins, stalls, or completes

Solo and Group Play¶

Each player controls a single character. Solo missions are common and accessible. Group missions allow multiple players to bring their own characters on a shared expedition, rewarding complementary skill coverage, better logistics, and coordinated preparation. Group missions do not require synchronous online presence for every step.

Expedition Inputs¶

Before launch, the player should choose:

destination
loadout
supplies
retreat threshold
consumable use rules
cargo priority

Expedition Outputs¶

When complete, the mission can produce:

loot
gathered materials
codex knowledge
injuries
deaths or retreats where permitted
map updates
reputation changes
contract completion

Travel and Time¶

Travel time should be a meaningful part of the economy and session model. A nearby hunt might resolve in minutes; a desert survey or inter-town caravan run might take much longer.

Dynamic events should be one of the main reasons travel conditions change over time. Floods, raids, plagues, and festivals should alter route value and risk.

The same route and state changes should feed mission generation. If a road collapses or a control window turns a caravan lane strategic, the board should change immediately rather than waiting for hand-authored content.

Group Mission Coordination¶

Group expeditions need at least:

a group leader who selects the expedition from the board
a ready check so all members confirm their loadout, supplies, and safety rules before departure
an expedition escrow for shared supply contributions
a visible outcome log for all participants after completion
shared map knowledge for tiles traversed during the run

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

Failure States¶

Failure should not always equal total loss. Typical failure outcomes should include:

retreat with injuries
partial success
lost cargo
broken gear
missed deadline
reduced map quality