Events¶

Deep dive on the event system — how events fire, surface to the player in the inbox, present choices, and resolve. Events are the primary unit of player decision-making in the game; they are the moments when the simulation surfaces something that wants the player's attention, and a chief reason the player stops advancing time.

→ Parent: GDD.md

Concept¶

Time advances a day at a time: the player ends the current day, or sets the sim running forward to a stop point. Events are the discrete moments when something happens that the player should know about or decide on, and they are a primary reason the sim stops. They surface through:

The inbox — the persistent queue of pending and recent events the player works through.
Stops — events the player has flagged as stop-worthy halt the running sim the moment the player becomes aware of them, demanding attention before the clock moves on.

Which events stop the sim and which simply accumulate quietly in the inbox is a player setting, configured per category (see Stop Settings). The game's job is to fire events; the player's job is to decide how loudly each kind announces itself.

Event Lifecycle¶

Every event passes through up to four phases:

Fire — the event is generated by the simulation when its trigger conditions are met. Triggers are scenario-scripted, condition-based, or driven by gameplay state.
Become known — the event reaches the player's awareness, subject to the information lag system. Local events become known immediately; distant events become known after the era's communication delay.
Resolve via choice — the player picks an option, and consequences apply.
Resolve via default — if the deadline passes after the player has become aware of the event without an explicit choice, the default option is automatically applied.

stateDiagram-v2
    [*] --> Fired: trigger conditions met
    Fired --> Known: player awareness (lag-gated)
    Known --> ResolvedByChoice: player picks an option
    Known --> ResolvedByDefault: deadline passes (default applied)
    ResolvedByChoice --> [*]
    ResolvedByDefault --> [*]

Critical principle: events never resolve via default before the player has become aware of them. If lag means a distant event takes weeks to reach the player, the event waits — but option availability changes with elapsed time (see Time Pressure below).

Event Structure¶

Each event carries:

Trigger conditions — what must be true in the simulation for the event to fire.
Severity — an authored level (trivial / routine / significant / major / critical) that the player's settings can use to determine blocking behavior.
Stakeholder(s) — which stakeholders are involved (drives where it appears, who it affects, and how prominent it is in the inbox per their Clout).
Description — the prose presented to the player.
Options — typically 2 to 4, each with:
A label and short description.
A lead-time requirement — defaults to one month; events override per-option in scenario data when needed (immediate-action options at zero, longer campaigns at three months, six months, etc.).
Consequences shown directly on the choice — explicit labels like "−10% revenue for the next 2 years" or "+15 with Industrialists, sticky." The player sees what each option does before picking; no surprises.
Default option — the option that auto-applies if the player lets the deadline pass without an explicit choice. Authored as the least-negative outcome among the available choices.
Deadline — how long after firing the event remains open. Authored per event — no fallback-by-category; each event names its own deadline.

Default Choice (Victoria 3 Style)¶

Every event has a default option — the choice that auto-executes if the player lets the deadline pass without input. The authoring rubric is least-negative outcome: the option that does the least damage among the available choices. Some events may have only negative outcomes (a forced regulatory crackdown, a strike that demands a response, a debt obligation coming due); the default in those is the least-bad path — the Victoria 3 "safe, neutral fallback" idiom translated into a clear authoring rule.

The player who lets events expire without input is not punished by random catastrophic outcomes; they get the floor. The player who does engage may pick a more aggressive or rewarding option, accepting risk for upside.

Decisions are final. Once an event resolves — whether by explicit choice or by deadline expiry triggering the default — the simulation provides no rewind or undo mechanism. The player commits to their choices and lives with the consequences. (Save and reload is an OS-level concern outside the simulation's domain.)

Time Pressure and Option Decay¶

Events have a deadline in in-game time from the moment they fire. The deadline determines when the default would auto-apply (after the player has seen the event).

Each option also carries a lead-time requirement — how much in-game time it needs to be executed. Some options are immediate (paying a fine, conceding a point, ignoring a demand); others require lead time (running a counter-campaign, building public support, organizing a strike-breaking force).

When the player becomes aware of an event, available options are filtered to those whose lead time fits the remaining time before deadline:

Available options at the moment of awareness = options where lead_time ≤ deadline − awareness_time

Information lag has teeth: distant events that reach the player late offer a smaller decision space. The player must act immediately and may have to choose from a poorer set of options than someone closer to the source had.

Example: Union Demand Event¶

A union in a distant region issues a demand. The event has a 60-day deadline.

Options: - Ignore the demand. Lead time 0. Consequence: union goodwill drops; possible strike. - Concede to the demand. Lead time 0. Consequence: cash cost; goodwill rises. - Run a counter-campaign to persuade union members to vote it down. Lead time 30 days. Consequence: cheaper than conceding if successful, riskier if not.

Three scenarios:

Player location	Lag	Sees event on day	Time remaining	Options offered
Same region	0	1	60	All three
14-day postal lag	14	15	45	All three (counter-campaign needs 30, fits)
35-day postal lag	35	36	24	Ignore + Concede only (counter-campaign needs 30, doesn't fit)
75-day postal lag	75	76	−16	Ignore + Concede only — event has waited past its deadline; player must resolve immediately on awareness

In the last case, the event has been festering for weeks while the player was unaware. It does not auto-apply the default — it waits — but by the time the player sees it, every lead-time-positive option is gone, and the only remaining choices are the immediate ones. The simulation reflects the situation that has accumulated during the unwitnessed period.

Stop Settings¶

The player controls which events stop the running sim and which simply accumulate in the inbox. Because the sim only advances when the player drives it, this is the core signal-to-noise dial of the pacing model (the Football Manager / Out of the Park "what should interrupt me" preference).

To keep this from becoming the settings-bloat that drowns deep-simulation games, the control is per category, not per event. For each category the player picks one of:

Stop — when an event in this category becomes known (after any information lag), the running sim halts and the event demands attention before the clock moves on.
Log — the event accumulates quietly in the inbox; the player engages when they choose. Defaults auto-apply when deadlines pass (see Default Choice).

Categories are a curated, manageable set — by severity (trivial / routine / significant / major / critical) and by a few high-level kinds (a contract or financial deadline, a labor action, a project incident, a rival move, a government / regulatory matter). Sensible presets ship by default (e.g. "stop on major-and-up and on any hard financial deadline; log the rest"), so a player need never open the screen — but can tune it.

The design intent is that the player deals with events rather than filtering them away. Clout still shapes prominence (high-Clout stakeholders' events sort to the top of the inbox; their decisions feel weightier), and severity still informs the consequences of each choice. Whether an event stops the sim is the player's call, by category.

The Inbox¶

Pending events accumulate in the persistent inbox — every event that has fired and become known but is not yet resolved, alongside informational notices and offers. The inbox is the player's correspondence queue and the surface the sim stops them at (per UIArchitecture — the inbox).

Ordering: by deadline urgency, soonest first. The most pressing item is at the top, so the player's eye lands on what most needs attention. (High-Clout stakeholders' items weight upward within that ordering.)

Each inbox entry shows:

The event title and one-line description.
The deadline (date and remaining time).
The stakeholder(s) involved with their Clout indicators.
A summary of the available options and their consequences (per Event Structure) — with inline action buttons where the choice is simple, or a link to a modal / profile page for a fuller decision.

Opening an entry presents the full event — letting the player choose immediately, or close without committing (the event stays pending until its deadline, when the default auto-applies).

For categories the player has set to Stop, a new event halts the running sim and surfaces immediately; for categories set to Log, it lands in the inbox for the player to find when they next stop (see Stop Settings).

Interaction with Other Systems¶

Goodwill. Most goodwill modifiers come from event resolutions — both player choices and auto-applied defaults. Decision prompts label modifier consequences up-front.
Construction. Events fire on active projects (incidents, surveying surprises, labor disputes); some events offer the player project commissioning opportunities surfaced by scenario triggers.
Business Dealings. Bond, equity, and contract opportunities arrive as events. Procurement deals can also arrive as time-bounded offers.
Populations. Population shifts are driven partly by event resolutions; events about a region typically affect that region's interest groups.
Information lag. As described above, lag delays awareness and shrinks the option set on arrival.
Stakeholder Clout. Clout determines how prominently an event appears in the inbox and what tooltip detail it gets — but not whether it stops the sim. That's the player's stop setting.

All major Events design questions are currently resolved. Specific tunable values — deadline ranges per event category, default lead-time exceptions, exact log ordering tie-breakers — are scenario-tunable and will need playtesting.