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 Launch Gates¶

Before the player can confirm departure, the expedition prep screen must surface the following blocks at the top of the launch view — not buried in a stats tab:

Survival state check

The character's current hunger, thirst, and fatigue bands are displayed as a gate, not a tooltip. If any band is Strained or worse, the affected band is highlighted and the specific expedition tiers that are locked are listed explicitly:

Strained (Hunger) — expeditions above D-rank are unavailable until fed.

If all bands are Stable or better, a single green "Ready" indicator replaces the individual band rows. Players who are prepared should not have to hunt for confirmation that they are.

Single-use consumable warning

If the player's loadout includes any item flagged as single-use or single-charge (ritual preparations, charged tonics, sealed vials), the launch screen displays an explicit acknowledgment before departure:

Your loadout contains [item name], which is consumed permanently on use or lost permanently if you are incapacitated. Confirm?

This acknowledgment is required on the first departure with any given item type. Once acknowledged for an item type, it does not block future launches unless a new item type is added to the loadout.

Quick read: what a departing character should see

Survival bands — gate or "Ready" indicator
Single-use consumable list (if any) with confirmation
Mount feed duration check — if a mount is equipped, the screen verifies that mount feed in supplies covers the estimated expedition duration
Estimated expedition duration based on route and pace

Expedition Inputs¶

Before launch, the player should choose:

destination
loadout
supplies
mount (optional — reduces travel time; mount feed must be included in supplies for the full expedition duration; see world-structure.md for speed values and duration examples)
retreat threshold
consumable use rules
cargo priority
wilderness activities (optional)

Wilderness activities are optional things the character can do in addition to the main expedition objective. Examples include gathering herbs and plants, mining ore and stone, fishing, harvesting beast carcasses, and similar field work. Each selected activity adds time to the expedition duration. If an activity finds no valid targets (for example, fishing when no water source was encountered on the route), the added time is not fully consumed.

Example: a Hunt expedition with harvesting selected will automatically attempt to harvest beast materials after each kill. A Survey expedition with gathering selected will pick herbs and plants along the route. Both extend total expedition time but return more raw output.

Expedition Outputs¶

When complete, the mission can produce:

coin (from human-type enemies such as bandits and brigands only)
gathered materials (from wilderness activities such as harvesting, mining, gathering, or fishing — if any were selected)
carried goods or equipment (dropped by human-type enemies)
codex knowledge
injuries
deaths or retreats where permitted
map updates
reputation changes
contract completion

Travel and Time¶

Travel time is computed from the world scale distances and movement speeds defined in world-structure.md. The formula is: (site_distance_km × 2 ÷ travel_speed_kmh) + site_time. A nearby march ring hunt on foot resolves in a few hours; a long outer belt expedition on foot can take most of a day. The same expedition on a riding mount takes roughly half as long.

Mounts are selected before departure and their speed tier is locked into the expedition snapshot.

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.

Daily Outlook Panel¶

On first board view after returning to the game (or after any expedition settles), the town board header displays a compact three-line summary:

What changed — reserve band shifts, new active events, or route disruptions since last login
Closest progression target — the skill nearest its next band flip, shown as "Blades: ~3 hunts from Skilled (est.)" based on recent gain rate
Best current offer — highest-urgency or highest-premium board offer, with urgency label and time remaining

This panel is always visible at the top of the board view, not in a separate tab or settings menu. It collapses once dismissed and returns on next login or after an expedition settles. Its purpose is to answer "what should I do now?" in under five seconds.

Between-Expedition Activities¶

While an expedition is in progress, a player has no active commitment running. The following activities are explicitly available between launches. They are designed as short interactions (one to a few minutes) and are intended to fill the gap between expedition send-off and result check-in rather than to replace expeditions.

Settlement Watch¶

The player reads the current state of a town they are interested in: reserve bands, active events, current route disruption flags, and pending control windows. No resources or skills required. No cooldown.

Why it matters: Town state drives board offers. A player who monitors reserve bands can predict which expedition types will appear before the next board refresh and position their loadout accordingly. A player who catches a Supply Critical flag early can fill a shortage delivery before competitors notice.

Recipe Study¶

The player selects one recipe they know and spends a study session reviewing it. This earns a Focused Craft token for that specific recipe, consumed on the next craft attempt. The token adds 0.05 to the quality weight roll for that one crafting session.

Available only for recipes already in the player's library
One token at a time per character; a new study session does not stack tokens
No coin cost; 4-hour internal cooldown between study sessions

This is not a shortcut to better quality — it is a small edge for a player who invests time between expeditions.

Trade Scouting¶

The player requests a price snapshot for one commodity at the Trevalkaan exchange. The snapshot shows the current best sell price, best buy price, and volume on both sides.

Available at any Trade skill band
Limited to 3 price scouting requests per daily tick per character
Does not require Trade Familiar or higher — it is the one market access feature with no rank floor

Trade Scouting is intentionally less powerful than the full price history and order book access that Trade skill unlocks. It gives low-rank players a reason to engage with the market without removing the incentive to develop Trade skill.

Codex Review¶

The player opens their accumulated codex and reviews creature entries they have earned through past hunts. Each entry shows: creature name, family, encounter grade, damage type, weakness, and current knowledge quality (Observed / Studied / Well-Known / Mastered).

No resources, cooldown, or skill requirement
Entries also show which creatures the character has never encountered in the zone the player is currently focused on, making this a planning tool for future hunts
"Mastered" entries unlock a tooltip showing the optimal loadout matchup against that creature — this tooltip is only visible through the codex, not on the expedition board

Codex Review is the primary tool for understanding why past expeditions resolved the way they did, and for planning which enemies to hunt next.

The codex header for each creature family shows a completion fraction: 3 / 7 variants encountered. The unknown count shows as 3 / ? until the player has seen enough variants to infer the family ceiling. This is intentional — the incomplete count is a hook, not a spoiler. Filling out a full family entry is a long-term collection goal that surfaces without announcement.

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

Engagement Loop¶

The core return cycle should feel like a closed circuit. Every session should end with a clear next target visible before the player closes the tab.

Return → Scan → Plan → Send → Wait → Return

Phase	What player does	What the game provides
Return	Opens tab after wait	Expedition result waiting; notification badge shown
Scan	Reads outcome, claims rewards	Result modal: coin tween, XP bar fill, injury state
Scan	Checks daily outlook panel	3-line summary: what changed, closest skill flip, best offer
Plan	Browses board, sets loadout	Board sorted by urgency; skill proximity label on relevant cards
Send	Confirms departure	Acceptance snapshot written; expedition begins
Wait	Alt-tabs	Notification chime fires on expedition return

Return Notification¶

The expedition return notification is the single most important engagement touchpoint. It must:

fire reliably when the expedition settles (server push or polling fallback at 60-second intervals)
show outcome band and one headline reward inline in the notification text
be non-modal and non-blocking — badge and banner only, not a forced popup

See ../../tech/ui-design-system.md for the sound event spec. The expedition return chime is the only sound that plays automatically without a UI interaction.

The "One More Run" Mechanism¶

Every session should end with a visible goal one run away. The system surfaces this automatically:

Skill within 20% of next band: show "~N runs from [Band] (est.)" label on relevant board cards and in the daily outlook
Board offer matches character's dominant archetype at Urgent or Emergency urgency: show subtle archetype-match indicator on the card
Town supply at Scarce or lower for a material the character can provide: show "Town needs this" tag with the premium modifier visible

Labels are small and inline. The hook works because the player already knows to look at the board. No popups, no modal nudges.