Transit Events
This page explores whether — and how — fleets can be affected by events while they are in motion.
It does not describe final game behavior. It is an open design question with real tradeoffs on each side.
Goal
The goal is to decide what it means for a fleet to be "in transit" beyond just a timer counting down.
A pure timer is clean and predictable but leaves the journey feeling empty. Events can add texture, lore, and strategic depth — but they also introduce complexity, and badly designed events easily become frustrating interruptions.
What a Transit Event Might Be
A transit event is something that occurs while a fleet is crossing a system. Examples include:
- a pirate raid targeting the fleet in a lawless system
- the fleet passing through an active warzone and becoming entangled
- a mechanical failure that grounds part of the fleet for repairs
- an unexpected discovery at a stellar object along the route
- a diplomatic encounter with a faction patrol
These events could operate on individual systems, on region crossings, or on entire route legs.
The Core Design Fork
There are two fundamentally different approaches to transit events, and the choice shapes the whole feel of fleet management.
Passive transit
The fleet travels autonomously. Events are generated and resolved without player input. The player receives a notification after the fact — the fleet took minor damage, or was delayed by one hour.
This model treats transit as logistics. The player commits a fleet to a destination and manages it at the macro level. Events are informational context, not decisions.
Active transit
Events pause or interrupt the journey. The player must respond — choosing whether to fight, retreat, pay a toll, detour, or accept consequences. The fleet waits for input, or if the player does not respond, a default outcome is applied.
This model treats transit as engagement. Each journey is a sequence of choices, not just a timer.
Tradeoffs
| Passive | Active | |
|---|---|---|
| Player experience | Set-and-forget logistics | Managing active caravans |
| Complexity for the player | Low | High — risk of feeling like busywork |
| Strategic texture | Events are flavor | Events are decisions |
| Frustration risk | Low | High if poorly balanced or too frequent |
| Lore integration | Notifications add context | Encounters build the world |
| Suitable player investment | Strategic-level fleet command | Deep fleet-focused play |
The middle path
A hybrid exists between the two extremes: events are resolved automatically, but the player can choose to intervene manually for a better outcome.
Examples of this pattern: - A pirate attack defaults to the fleet defending automatically (taking some damage) — but the player can respond to a notification within a window to direct the defense personally. - A repair delay defaults to a fixed duration — but the player can assign extra resources to speed it up.
This keeps the game unblocked for players who are not watching, while rewarding attention and engagement.
Open Questions
- At what scope do events trigger — system level, region level, or route level?
- Should event frequency be configurable, or does each event type have a fixed probability?
- If the player does not respond to an active event within some window, what is the default outcome and is that always reasonable?
- Can events be entirely avoided by route choice, or do they apply regardless of path?
- Are events based on the state of the system the fleet is crossing (e.g. a warzone event only fires in systems where a war is active), or are they randomised independently?
- Should transit events create persistent consequences (lasting damage, reputation changes) or be self-contained?
- How does the event model interact with multiplayer — can another player trigger an event against a fleet in transit, or are events only environmental?