Skip to content

Dynamic Events and World State

Design Goals

The world should feel active without relying on hand-authored one-off events. Areas, towns, roads, and sites should automatically generate events when their local conditions cross meaningful thresholds.

Browser-Fit Rule

Because this is a browser game, events should not depend on everyone being online at the same second. Events should appear as timed opportunities, changing area states, temporary missions, and map markers that players can respond to during short check-ins.

Core Principle

Events should be condition-driven, not purely random.

An event should start because something in the world changed:

  • a town ran low on food
  • monster pressure rose in nearby fields
  • storms hit the coast
  • a mine was overworked
  • a guild diverted too many supplies
  • a caravan route became unsafe
  • players overhunted or overharvested an area
  • prosperity unlocked festivals or merchant influx

Area State Model

Each area should maintain a compact state profile that can feed event generation.

Recommended area state inputs:

  • security pressure
  • monster pressure
  • food pressure
  • water pressure
  • medicine pressure
  • route disruption
  • resource depletion
  • corruption or blight
  • weather severity
  • prosperity
  • unrest
  • mystery or anomaly score

These scores can be derived from town state, nearby sites, recent mission outcomes, season, region type, and unresolved prior events.

Condition Scale

All local condition inputs should resolve to 0-100 before event templates read them.

  • 0-24: dormant
  • 25-49: elevated
  • 50-74: active
  • 75-100: crisis

Use the same scale for town shortage, route disruption, monster pressure, unrest, prosperity, and anomaly scores so event templates can share weights and aftermath rules.

Event Categories

Ecological Events

  • overhunting reduces herd presence
  • predator surge near farms
  • fungal bloom opens temporary gather sites
  • locust swarm damages crops

Settlement Events

  • ration shortages
  • plague flare-up
  • refugee arrival
  • labor strike or unrest
  • harvest festival

Route and Trade Events

  • bridge collapse
  • caravan ambush wave
  • washed-out road
  • black-market surge
  • rare merchant convoy

Monster Events

  • den expansion
  • undead stirring in a barrow chain
  • drake nesting window
  • fae hunt passing through forest routes
  • cult ritual escalation

Weather and Climate Events

  • blizzard front
  • heatwave
  • ashfall
  • flood season
  • storm tide

Discovery Events

  • sinkhole reveals ruins
  • fresh ore seam exposed
  • hidden spring found
  • ancient ward failure reveals a sealed site

Prosperity and Civic Events

  • town fair
  • tournament
  • tax dispute
  • public works rush
  • pilgrim influx

Event Lifecycle

  1. Condition Build-Up: area scores drift due to world state, player actions, and natural cycles.
  2. Trigger Evaluation: the local event director checks whether an event candidate should fire.
  3. Event Instance Creation: the game creates an event with area, duration, urgency, and outcome branches.
  4. Player Exposure: players see event cards, map markers, town-board entries, market deltas, and route warnings.
  5. Participation Window: players run missions, deliver goods, fight threats, or ignore the event.
  6. Resolution: on expiry or threshold completion, the event resolves automatically.
  7. Aftermath: area state, town reserves, route status, monster tables, and future trigger weights change.

Trigger Evaluation Model

Every event_template should define:

  • base_weight
  • trigger_threshold
  • base_severity
  • base_duration_hours
  • condition_weights
  • season_tags
  • chain_tags
  • cooldown_hours
  • required_prerequisites

Recommended evaluation formula:

trigger_score = base_weight + Σ(local_condition_score × condition_weight) + season_bonus + chain_bonus + policy_bonus - cooldown_penalty - local_cap_penalty

Spawn rules:

  • discard templates below trigger_threshold
  • keep the top 3 candidates per scope after filtering
  • spawn at most 1 crisis event and 1 non-crisis event per area evaluation pass
  • if multiple candidates land within 10 points of each other, use weighted random among them to preserve variety

Severity and Duration

Severity should come from conditions, not only event type.

severity_score = clamp(base_severity + trigger_score - trigger_threshold, 1, 100) duration_hours = base_duration_hours × scope_multiplier × severity_multiplier

Recommended urgency bands:

Severity Band Typical Use
1-24 local issue one board card, limited market effect
25-49 serious multiple contracts, area marker, visible price pressure
50-74 major route warnings, stronger area modifiers, chain risk
75-100 crisis emergency board priority, town-state impact, likely follow-up chain

Event Chains

Events should be able to chain.

Examples:

  • crop blight -> food shortage -> bandit pressure on grain caravans -> refugee influx
  • storm season -> fishing losses -> ration shortage -> coastal import contracts
  • overmining -> cave-in -> rescue contracts -> iron shortage -> weapon price spike

This is how the world starts to feel alive instead of episodic.

Participation Types

Players should be able to engage events through multiple existing systems:

  • hunt or defense missions
  • gather or survey missions
  • delivery and escort contracts
  • crafting for public works or emergency supply
  • guild-backed town contributions
  • market speculation and logistics

That keeps events integrated with the core game instead of becoming a separate minigame.

Success and Failure Logic

Events should resolve from aggregate participation plus background NPC contribution.

Recommended resolution inputs:

  • number and quality of completed event missions
  • total resources delivered
  • relevant monster pressure reductions
  • escort success rate on affected routes
  • town reserve changes during the event window
  • guild or faction policy modifiers

This allows events to move even when some players ignore them.

Contribution Normalization

All player and NPC responses should convert into comparable resolution points.

Recommended sources:

  • mission completion: expedition difficulty × outcome quality
  • delivery turn-ins: reserve units delivered × urgency multiplier
  • crafting turn-ins: recipe category value × quality tier
  • escort or defense work: protected cargo value × survival percentage
  • survey confirmation: high value for route, hazard, and discovery events
  • passive NPC response: small baseline from town size, security, and prosperity

resolution_target = base_difficulty × severity_multiplier × scope_multiplier × chain_depth_multiplier resolution_ratio = (player_points + npc_points + policy_bonus + timing_bonus) / resolution_target

Outcome bands:

  • < 0.75: failure
  • 0.75-0.99: partial containment
  • 1.00-1.24: success
  • 1.25+: strong success

Aftermath Rules

Aftermath should write state back into the same systems that created the event.

  • failure increases at least one local pressure score, applies a longer negative modifier, and raises the weight of one follow-up chain
  • partial containment ends the immediate emergency but leaves shorter negative modifiers or lower-quality rewards
  • success clears the main modifier, applies cooldown, and reduces related pressure scores
  • strong success can add prosperity, discovery chances, extra market supply, or temporary morale bonuses

At least one aftermath field should be machine-readable for each affected system: town reserves, route state, market index, monster table, site availability, or guild influence.

Chain Propagation

Event chains should not be hand-scripted only as prose. Each event family should define one or more chain_tags and a carry-forward amount.

Recommended rule:

chain_pressure = unresolved_pressure × chain_multiplier

A failed crop blight can therefore feed food shortage pressure, which then feeds caravan raid pressure, without a bespoke script for every region.

Example Events

Wolf Pressure in the Marches

Trigger conditions:

  • low local food reserves
  • high predator presence
  • reduced field security

Effects while active:

  • farm output drops
  • hides and meat become more available from hunts
  • grain and ration prices rise
  • urgent hunt and fence-repair contracts appear

Resolutions:

  • successful hunts and deliveries stabilize farms
  • failure pushes the town into shortage and increases bandit opportunity

Storm Surge on the Coast

Trigger conditions:

  • severe weather score
  • high tide window
  • low route stability

Effects while active:

  • fishing jobs become risky
  • drift salvage sites appear
  • dock repairs and rope demand rise
  • reef monsters become more active

Mine Collapse in a Frontier Area

Trigger conditions:

  • heavy extraction over time
  • low maintenance investment
  • unstable geology score

Effects while active:

  • metal supply drops
  • rescue and timber delivery contracts appear
  • local tool and weapon prices climb
  • hidden lower tunnels may open after stabilization

Harvest Festival

Trigger conditions:

  • prosperous town state
  • adequate food reserve
  • safe roads

Effects while active:

  • morale rises
  • rare merchants visit
  • special cooking and craft orders appear
  • tournament or prestige contracts spawn

Anti-Spam Rules

Events should not flood the map.

Use explicit controls:

  • max 2 active events per area, with no more than 1 crisis event at once
  • max 2 crisis events per region unless a world-scale disaster flag is active
  • cooldowns of 12-72 hours after resolution depending on severity
  • escalating thresholds for repeated failures so the same template does not respawn every pass
  • event-family rotation to preserve variety between ecological, civic, route, and monster pressure
  • prosperity events should use a separate cap so they do not crowd out emergencies

Player-Facing Presentation

In the browser client, events should appear as:

  • world map markers
  • area urgency banners
  • town-board emergency cards
  • market alerts
  • expedition destination modifiers
  • short recap logs after resolution

The player should be able to understand an event in one screen:

  • what happened
  • where it is
  • how long it lasts
  • what actions can help
  • what the consequences are

Technical Model

Core Records

Store:

  • event_template
  • event_trigger_rule
  • event_instance
  • event_phase
  • event_area_state_snapshot
  • event_participation
  • event_contribution_bucket
  • event_resolution
  • event_cooldown
  • area_dynamic_modifier

Each event_instance should also store severity_score, required_resolution_points, deadline_at, seed, and origin_ref.

Each event_participation record should store source_type, source_ref, points_awarded, and validated_at so event scoring never depends on freeform logs.

Coordinator Model

Use a local coordinator rather than a global world brain.

Recommended pattern:

  • one town coordinator evaluates town and nearby settlement events
  • one region or area coordinator evaluates route, monster, and discovery events
  • event instances write summary projections for map and board reads

This fits the Cloudflare model and avoids costly global scans.

Evaluation Loop

Run event evaluation on a schedule such as every 15-60 minutes depending on scope.

Each evaluation pass should:

  1. refresh local condition scores
  2. gather eligible event templates
  3. filter by cooldown, caps, season, and prerequisites
  4. compute weighted trigger scores
  5. spawn zero or a small number of event instances
  6. schedule the next phase or resolution wake time

Resolution Pattern

Event instances should resolve like other long-running jobs:

  • store seed and planned duration
  • accept contributions during the active window
  • compute outcome at wake time
  • write aftermath modifiers to town, area, route, or market state

Recommended resolution order:

  1. freeze the target score and severity at event start
  2. accept only server-validated contributions while the window is open
  3. total points by contribution bucket and apply policy modifiers
  4. compute the outcome band from resolution_ratio
  5. write aftermath modifiers, cooldown, and recap history

Read Models

Expose compact read models for:

  • active map events by region
  • local town emergencies
  • affected routes
  • event-linked market modifiers
  • event recap history

These should be summarized for quick browser sessions.

  • town simulation and supply
  • missions and expeditions
  • exploration and resource discovery
  • gathering and resource ecology
  • markets and logistics
  • guilds and town control