Skip to content

System Ownership by Presence

This page explores how the game decides who owns an orbital system as a whole — separately from who claims individual stellar objects inside it.

It does not describe final game behavior. It captures the current direction and unresolved design choices.

Goal

Define system-level ownership as a computed, dynamic property of an orbital system — not as something a player explicitly claims. Make the question "whose system is this?" answerable from observable state inside the system, recompute it continuously, and let other game systems (notably player-built gate construction) read from it cleanly.

Core Problem

The broader Stellar Object Holdings model handles ownership at the per-stellar-object level: a planet can be Surveyed, Claimed, Frontier, or Colony, each tier escalating one player's hold on that single object. That works well for individual planets, moons, asteroid belts, and so on.

It does not answer a coarser question: who controls the orbital system as a whole?

This matters because some game systems care about system-level control rather than object-level control. The clearest case is from Player-Built Connectivity, Direction 9: a gate built into an orbital system is a system-level structure. It should only be buildable by the system's owner, not by anyone who happens to claim a single stellar object inside the system.

The tension: players cannot reasonably claim an entire orbital system the way they claim a planet — a system contains multiple stellar objects, and a single player may not hold all of them. So who, if anyone, is the system's owner at any given moment?

Working Directions

1. Ownership is computed from presence, not stored

System ownership is a derived property, not stored state. At any moment, the system's owner is the player (or alliance) with the strongest measured "presence" inside the system.

  • Presence is recomputed regularly — possibly on every relevant state change inside the system, or on a tick.
  • A system can have no owner if no player crosses the presence threshold. Such a system is "open territory" — anyone may operate in it but nobody has system-level rights (like building a gate).
  • The current owner is visible to players in the UI, but the exact presence numbers may not be exposed (or only at a coarse level), to discourage players gaming the formula.

2. What feeds the presence metric

Multiple inputs combine into the presence score, weighted to discourage trivial tricks:

  • Stellar-object holdings inside the system — the strongest input. A player with a Colony in the system has high presence; a player with a single Surveyed claim has weak presence.
  • Anchored fleet strength — a fleet stationed inside the system contributes presence proportional to its weight class and dwell duration. Drive-by fleets contribute little; long-stationed garrison fleets contribute a lot.
  • Active infrastructure — buildings, defenses, gate slots already filled by this player contribute.
  • Recency — recent activity (events generated in the last N hours) weighs more than dormant activity. A player who garrisoned three months ago and has not been back is less "present" than someone who has cycled through this week.

Exact weights are tuning targets, not design commitments.

3. Presence transfer is gradual

Ownership does not flip on a single event. It transfers as the presence metric crosses a threshold and stays there for some duration.

  • A new claimant must out-present the current owner for dwell time D before the system flips.
  • Brief raids do not transfer ownership.
  • A defender losing presence has time to react — bring fleets back, repair holdings — before the system is taken.

This avoids "blink-and-you-miss-it" ownership flips, which would feel unfair and would make downstream system-level rights (like an enemy suddenly being able to remove your gate from a system you had owned all month) jarring.

4. Ownership at zero presence — open territory

When no player crosses the presence threshold, the system is unowned.

  • An unowned system cannot host a gate. Whoever wants to build there must first establish presence and become the owner.
  • Unowned systems may have a slow decay on residual infrastructure — abandoned buildings degrade over time — but that is a separate idea.
  • Open territory is contestable: any player operating inside it can be the first to cross the threshold and assume ownership.

5. Read-side projection for consumers

System ownership is a derived state, but consumers (gate construction, traffic-tax checks, garrison-bonus mechanics) need a fast lookup. Resolution: a projection maintains a per-system "current owner" record that consumers read directly. The projection updates whenever presence inputs change — a fleet enters or leaves, a colony levels up, a building completes.

This keeps the gate-construction path simple: ask the projection, get an owner (or "none"), gate the build accordingly. The presence computation happens on the projection's write side.

Open Questions

  • The exact presence formula. Specific weights for holdings, fleets, infrastructure, recency. Playtest tuning, not design.
  • Whose presence counts when an alliance is involved? Per-player ownership, per-alliance ownership, or a layered model (per-player ownership but alliance members can act on each other's systems)?
  • What is "dwell time D" for transfer? Seconds, minutes, hours, in-game days?
  • Visibility of the presence metric. Should players see a numeric "you have 73% presence, the rival has 22%", or only the discrete result (you own this / they own this / nobody owns this)?
  • Does the system's owner have rights beyond gate construction? Tax on traffic? Veto on other players' construction? Defender bonuses? Or is gate-build eligibility the only system-level right for now?
  • Edge case: contested systems. Two players with near-equal presence — does the system flicker between owners, hold "contested" as a special state, or stay with the incumbent until a clean threshold is crossed? Direction 3's dwell time partly answers this but leaves the question of what happens during the contest.
  • Does presence decay when a player goes inactive (logs off, vacation)? Or is dormant presence preserved indefinitely for offline players?
  • What about presence in a system you've never visited? A player with a probe transiting through a system has trivial presence; should that count at all, or only after a meaningful action (anchor a fleet, claim a stellar object) is taken?