Player-Built Connectivity

This idea explores a world in which inter-region and inter-galaxy travel does not exist until players build it. Every crossing between regions or galaxies is constructed by a player or alliance, at cost. Until somebody builds a gate, no path between those regions or galaxies exists.

Naturally-occurring Wormholes — two-way crossings spawned by the universe rather than built by players — are a separate concept and are out of scope here. See the dedicated Natural Wormholes idea page. This page covers player-built gates only.

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

Terminology

There are two player-built gate types, distinguished by the boundary they cross. Both are one-way (see Direction 3).

Jumpgate — connects two regions (inter-region).
Voidgate — connects two galaxies (inter-galaxy). Named for the intergalactic void it crosses.

Goal

Replace the pre-generated, "always-there" inter-region and inter-galaxy topology with a topology that is emergent from player action. Make the act of connecting two regions a strategic event — something that costs resources, takes effort, leaves a visible mark on the map, and changes the political shape of the universe.

Secondary goals:

Make every gateway-bearing orbital system a strategic prize, not just a logistical waypoint.
Give early movers a real, lasting topological advantage.
Allow the server-side topology to grow lazily — only what's actually been connected exists in the database.
Bound the total topology with a hard universe size cap so server cost stays predictable even at long horizons.

Core Problem

In the current model, every region adjacent on the galaxy map already has Jumpgates between it and its neighbours, generated at world-creation time. Every adjacent-galaxy pair already has Wormholes. The map is "wired up" by the simulation, and players just walk it.

Two consequences fall out of that:

The topology is flat. There is no scarcity in how many places you can reach. Adjacency on the grid is destiny.
There is no investment in the map itself. Players invest in holdings, fleets, and combat — but the roads are free infrastructure handed to everyone.

A player-built model creates scarcity and investment at the topology layer. It also opens up a server-side simplification: regions that nobody has connected to never need to exist as persisted state.

Working Directions

1. Pure player-built model — no natural gates anywhere

The starting universe contains only the spawn region(s). Every Jumpgate and every Wormhole is constructed by a player or alliance. The map grows outward as players build. Strict — even the first jump out of your spawn region requires you to build a Jumpgate. There is no natural connectivity anywhere in the universe; the topology is entirely emergent.

The cost is that the early game leans heavily on construction rather than exploration: a brand-new player must first invest in their home region before they can travel at all. That tradeoff is accepted in exchange for the topological scarcity and strategic weight that builds give every subsequent connection.

2. Asymmetric construction tiers — Jumpgate vs. Voidgate

Jumpgates (inter-region) are a normal mid-game industrial project: any established empire can build one. Voidgates (inter-galaxy) are an alliance-tier endeavour — they require resource pooling, multi-player coordination, and possibly a one-of-a-kind "Anchor" megastructure on each side.

This creates a natural progression: solo and small-group play occupies a galaxy; only coordinated alliances cross between galaxies. The first alliance to span a galaxy boundary has bragging rights and a real advantage.

3. Gates occupy a system-defined slot, are defendable, conquerable, destructible, and one-way

A built gate is not a new stellar object inside an orbital system. Instead, every orbital system carries a dedicated gate slot at its outer edge. Building a gate fills that slot; destroying the gate leaves debris in it; conquering the gate transfers ownership of it. The slot's contents change — the slot itself is part of the system's structure.

Aggregate boundary — the gate is its own aggregate; the slot lives on the system.

The gate is a separate aggregate, not state carried inside the orbital system aggregate. A gate has a rich, independent lifecycle — built, damaged, conquered (owner transfer), restored, destroyed, plus cooldown/queue state and access mode (Direction 4) — with its own invariants and its own change cadence (it is attacked, queued, and recharged far more often than the host system's structure changes). That clump of behavior is the gate's consistency boundary.
The orbital system aggregate owns only the slot's occupancy, modelled as an explicit state: Empty | Occupied(GateId) | Debris. This mirrors the explicit empty/occupied-slot representation already used in the orbital system map. The system knows that a gate occupies the slot and which one; it does not know how the gate behaves.
The reference is thin and two-way: the system holds the GateId; the gate holds its host SystemId.
Because the two are separate aggregates, state that must stay consistent across both (conquest, destruction) is reconciled by domain events, not a single transaction. Example: the gate raises GateDestroyed, a handler flips the host slot to Debris. Eventual consistency is acceptable here and fits the existing messaging/outbox stack. Do not attempt a two-aggregate single-transaction update.

Slot status — not a stellar object.

The slot is part of the orbital system aggregate, not a separate stellar object. Building a gate does not increase the system's stellar-object count N.
Because N is unchanged, departure and arrival hop costs stay exactly as defined in add-stellar-pathfinding-and-distance: (N + 1 − Order) × HopDelta. The gate sits conceptually at position N + 1 (the system's edge) — which is the same place every departing fleet has to reach anyway. No extra hop is introduced.
Further constructions on the gate slot are still possible — defensive batteries, capacitor banks (see recharge below), supply caches, cosmetic markers. These attach to the slot, not as separate stellar objects.
A destroyed gate leaves a debris field in the slot (using the existing debris-field concept already defined elsewhere in the design — no new interpretation is introduced here). The slot remains occupied by debris until the field is cleared.

Placement constraint.

One gate slot per orbital system, always at the edge. Every system has exactly one slot, and the slot is at the system's outer edge by definition. Players do not choose where in the system the gate goes — only whether to fill the slot at all.
Reach-the-edge before jumping. A fleet that wants to use the gate must first travel from its current position to the edge slot. This uses the existing departure-leg cost rule — (N + 1 − originOrder) × HopDelta hops to reach the edge — and is not bypassed by gate ownership or upgrades. Going through an active gate is instant once you are at the slot.
Only the system's owner can build the gate. A player cannot drop a gate into someone else's system — the host orbital system must be owned by the would-be builder. Ownership of a system is not claimed; it is computed from presence inside that system (see Direction 9 below). A player cannot claim a whole system explicitly — they accrue ownership by being there and dominating it. This is the only place the connectivity idea intersects the broader holdings model: gate construction is gated by computed system ownership.
Gates are direct connections; there is no "overfly". A Jumpgate from System A in Region 1 to System B in Region 7 does not physically pass over Regions 2-6. It is a direct point-to-point connection. Nobody in the intervening cells can interdict the connection just by being underneath it — they must attack the gate itself at one of its two endpoints.

Defense, damage, and conquest.

The gate must be defended to survive an attack. Defenses come in two forms, possibly combined: an anchored fleet stationed in the host system, or built defenses layered on the gate slot itself.
Enemy fleets can target a gate directly. Outcomes are graded:
Damaged / disfunctional — the gate stops working but is not yet wrecked. The owner can repair; an attacker can press the assault further.
Conquered — instead of finishing the gate off, an attacker may take it. Ownership transfers, but the conquered gate is still disfunctional until the new owner restores it. This is the route for an aggressor who wants the gate working for them rather than gone.
Destroyed — the gate is wrecked. A debris field occupies the slot. The slot must be cleared before a new gate can be built there.
Destroying a gate severs the connection immediately. Damage and conquest also disable jumps until repair / restoration completes.

Jumps are instant; only fly-to and the queue take time.

Going through an active gate is instantaneous — there is no "in-transit" state between source and destination orbital systems. A fleet either is in the source system, or it has arrived at the destination system. Nothing in between.
Two things take time for a fleet using a gate:
Flying to the gate inside the source system — from the fleet's current orbital position to the edge slot. This is the existing departure-leg cost.
Waiting in the gate's queue — once at the slot, the fleet joins a queue and waits for its turn. The queue's throughput is governed by the cooldown rule (see Recharge / throughput above). A bare gate may have many fleets waiting; a highly-upgraded gate clears the queue faster.
If the gate is destroyed (or damaged, or conquered) while a fleet is flying toward it, the fleet completes the fly-to leg and arrives at the slot, then goes idle waiting for further command. The player is notified that the planned route is no longer available. The fleet is not stranded mid-jump because there is no mid-jump — it is sitting at the slot, fully retargetable.
If the gate is destroyed (or damaged, or conquered) while a fleet is in the queue, the fleet is bumped out of the queue and is left idle at the slot's position with the same player-notification, same as the fly-to-interrupted case.
A chain of destructions that strands fleets and colonies on the far side of a now-broken topology is intended — it is the strategic consequence of taking out an enemy's connectivity, and players are expected to plan for it (build redundant gates, keep return paths defended). There is no "long-range distress" or auto-recovery mechanic.

One-way construction.

Every gate is one-way. Building a Jumpgate from System A in Region 1 to System B in Region 2 enables fleets to travel A → B. It does not enable B → A.
A return path requires a separate gate built on the other side — typically by the same player, but anyone may build it (creating interesting political dynamics when the return side belongs to an enemy or neutral).
A fleet that jumps through a one-way gate is committed: it must find another route home, or be stranded until somebody builds a return gate.
This rule applies recursively to Voidgates. An inter-galaxy expedition that does not pre-build or pre-arrange a return Voidgate strands its fleet in the destination galaxy — perhaps for hours, perhaps for the rest of the campaign.

Recharge / throughput.

After a fleet jumps through a gate, the gate enters a cooldown period before the next fleet can use it. This caps single-gate throughput and creates congestion at popular crossings.
Buildings constructed on the gate slot lower the cooldown per level. A heavily-upgraded gate throughputs many fleets per real-time minute; a freshly-built bare gate is slow.
This makes a single highly-upgraded gate a strategic chokepoint, and creates a natural reason to build redundant gates between the same region pair when traffic warrants.

Damaged gates can be repaired indefinitely. Each repair is paid for in resources but does not introduce its own cooldown — there is no "repair count" limit. The same applies to restoring a conquered-and-disfunctional gate, once the new owner has it.

Sub-questions specific to this direction:

Conquest: does the attacker need to occupy the system for a duration before ownership transfers, or is ownership instant on the killing blow that would have destroyed the gate?
Can defenses be siege-cracked gradually over multiple attacks, or does each fight resolve independently?
What is the cost and process to clear a debris field from a slot so a new gate can be built there?

4. Access control — public, allied, tolled, blockaded

A built gate is owned by its builder (or by the alliance that funded it). Ownership grants control:

Public — anyone may pass freely.
Allied — only members of declared alliances pass.
Tolled — passers pay a fee, going to the gate owner. Creates a real "trade route owner" archetype.
Blockaded — owner shuts the gate, denying passage entirely (perhaps with a window of warning, perhaps not).

This turns gateway orbital systems into the most politically charged pieces of real estate in the game.

5. Targetable destinations are bounded by knowledge, not by a build-reach radius

There is no separate "build-reach" research radius. An earlier framing gated how far you can build behind its own research tracks (Long-Range Jumpgate Engineering and a counterpart for galaxies). That lever is removed: it overlapped with the exponential per-jump travel cost (Direction 5a) and duplicated distance-punishment. Two clean levers remain:

Knowledge — you can only build to a target you have discovered. Discovery is governed by the Astronomy / exploration system (Direction 6 and the dedicated Knowing the Universe page), not by this page.
Travel cost — distance is punished economically by the exponential per-jump cost (Direction 5a), not by a hard reach cap.

So: buildable = discovered AND affordable. If you know a target exists and can pay its flat build cost, you may build a gate to it — regardless of how many galaxy-map cells away it is. The exponential jump cost is what makes a far gate a questionable investment, not a research wall.

When the player orders a build, the UI presents a list of possible targets — the set of discovered regions/galaxies — and the player picks one. Players do not enter arbitrary coordinates.

Implications:

Non-neighbour connectivity becomes normal. Two regions in the same galaxy that are not grid-neighbours can be directly connected by a Jumpgate, provided one of their owners has discovered the target and pays the build cost. This is a substantial departure from the current spec's "Jumpgate connects adjacent regions" rule. The recursive-traversal navigation rule will need to be revisited (see Open Questions).
The "doubly-facing-edge" rule of the current spec largely dissolves at the inter-region and inter-galaxy layers. What remains open is the within-region question: which orbital system in the source region hosts the gate? See Direction 8.
Server-side preview cost. Presenting a list of possible targets requires knowing what is in the discovered set — lightweight summaries of every discovered region/galaxy. Full RegionMap generation can still wait until the player drills into a specific candidate. Open question: what does the "lightweight summary" look like.

Knowledge loss is grandfathered. If a player loses the discovery of a target (intel lost, observation network destroyed, etc.), gates they previously built to it keep working. Knowledge constrains what new builds are possible, not what existing gates do. This avoids cascade-collapses where one loss deletes a built empire's connectivity overnight.

5a. Build cost is flat; jump cost scales exponentially with distance

Two distinct costs govern a gate:

Build cost is flat. Constructing a gate costs the same regardless of how far it reaches. Predictable to plan and budget.
Jump cost scales exponentially with distance. Every fleet that passes through a gate pays a per-jump cost that grows exponentially with the gate's span (Chebyshev distance between its two endpoints on the relevant map). A short hop is cheap to use; a Region 1 → Region 20 gate is brutally expensive to operate.

This creates the core strategic choice: one long gate (cheap to build, punishing to use) vs. a chain of shorter gates (multiple builds, cheaper per jump). The chain is not a free lunch — each intermediate gate needs its own host system, system-ownership presence (Direction 9), and defenses. The two costs self-balance the decision, so distance does not need a separate research gate.

Tuning is out of scope: the exponent base, the per-jump currency, and any upkeep are future work. The one firm decision is the shape — flat build cost, exponential-by-distance jump cost.

6. Knowing what is out there — a separate research/exploration system, dedicated idea page to follow

Building a gate to a target requires knowing the target exists. With the build-reach radius removed (Direction 5), knowledge is the only thing that gates which targets appear in the build list — distance is handled by the exponential jump cost, not by a reach cap. A player can afford-or-not a far target, but can only see it as a candidate once discovered.

There are two natural shapes the discovery layer could take, and they likely both exist side-by-side:

Active scouting — sending a probe or survey fleet outward to investigate specific regions or galaxies. Slow, cheap, deliberate. The probe goes out, learns something, comes back (or transmits).
Passive observation — a telescope or sensor array built on a colony passively reveals nearby regions. Range scales with the instrument's tier. Rewards established players whose territory has matured into permanent settlements.

Both flavours generate a player-specific knowledge map of the universe. Knowledge can be shared, sold, or stolen between players (an explorer archetype that profits from intel trade is a strong design hook).

Exploration is out of scope for this idea page and will be captured in a dedicated future idea page for exploration / knowing the universe. The only connectivity-relevant takeaways are:

Targets in Direction 5's possible-targets list are filtered by what the player knows, not just by what the player can reach.
The same dedicated exploration page should also cover the universe-map UI question — what does the player see for cells they have not yet drilled into? Possibilities range from "everything visible by default" (today's behaviour) to "only espionage-discovered cells visible" (the explorer-empowering variant).

7. The universe map's initial size is the implicit cap; no second universe is planned

There is no separately-tuned "universe cap". The universe map generated at first-player spawn defines the maximum extent of this universe. Players can build gates anywhere inside that map, subject to all other rules, until every cell has been built into. Past that point, no further expansion is possible within this universe.

This keeps things simple:

The bound is geometric (the universe map's dimensions), not a separately-configured number.
Players know the limit from the start: it is whatever the universe map shows.

There are no other universes in scope. Standing up a second universe is a speculative far-future possibility — something to consider only if a live universe ever becomes so dense with players that more space is genuinely needed. How that would work (inter-universe links, isolated parallel worlds, migration, ...) is out of scope for this idea and almost certainly for the next several iterations.

8. Generation happens before construction starts, and the remaining within-region placement question

Server-side, regions and galaxies are generated lazily — but generation is a precondition of starting a gate construction, not something that happens at build completion. Because the player must explicitly choose a target orbital system (not just a target region or galaxy) when ordering a build, the target system must already exist by the time the order is placed.

A workable flow:

Player browses the radius (Direction 5). Regions and galaxies inside the radius show up as lightweight summaries — enough to identify them, not enough to drill into specific orbital systems.
Player drills into a candidate region or galaxy. At that moment, the target is fully generated: its RegionMap is generated, its orbital systems are laid out, and the player can pick a specific orbital system as the gate's destination.
Player commits to a specific target system. The construction order is placed against an already-generated target.
The build runs, finishes, and the gate becomes active.

The consequence is that generation is driven by player attention, not by gate-completion. A region the player drilled into but never built a gate to is still generated — and stays generated for the rest of the universe's lifetime. That is acceptable because the bound on total generation is the same one that bounds everything else: the universe map's dimensions (Direction 7).

This is a small but important shift from the previous framing. The previous framing said "only regions with an incident gate get generated". The current framing says "only regions a player has chosen to look at get generated, and any gate target is by definition one of those".

Within-region placement — the remaining geometric question. With the research-radius rule (Direction 5), the target region is no longer constrained to be a galaxy-map neighbour of the source. The doubly-facing-edge rule of the current spec dissolves at the inter-region and inter-galaxy layers — there is no "edge facing the target" when the target can be anywhere in the rectangle. What remains open is: inside the source region, which orbital system hosts the gate?

Three candidate models for the within-region constraint:

Outer ring only. The host orbital system must be on the region's outer ring (any side). Geometrically clean; makes outer-ring systems the prime real estate inside every region. Direction-of-target is irrelevant because the target may be anywhere in the radius.
Any orbital system in the region. Interior orbital systems are equally eligible. Maximum agency; the outer-ring premium disappears.
Outer ring as default, interior as expensive override. Soft compromise: interior gates are possible but pay extra cost or require special structures. Preserves the outer-ring premium without banning interior placement outright.

The same question recurs one layer up for Voidgates: given a host region inside a galaxy, which orbital system inside that region carries the Voidgate? — but with the same three answers and the same tradeoff.

Sub-questions specific to this direction:

Does the within-region placement decision affect the cost of using the gate in navigation? (Inner-region hosts mean a longer intra-region walk to reach the gate, which is naturally captured by the orbital-system-layer hops without needing a special rule — but the player should see this cost when choosing the host system.)

9. System ownership is computed from presence, not claimed; only the system owner can build the gate

System-level ownership in this game is not a claim a player puts down explicitly. Players do not "claim a system". Instead, ownership of an orbital system is derived from presence inside it — whichever player (or alliance) has dominant presence in the system, by some computed metric, is the owner for as long as that holds. Lose the presence, lose the system.

This rule has direct consequences for player-built connectivity:

Only the current owner of an orbital system can fill its gate slot. A would-be builder must first establish presence in the host system to the point of becoming its owner, then build the gate. They cannot drop a gate into someone else's territory.
Losing presence means losing the gate too. If an owner loses the system to a competing presence, the gate slot's ownership transfers along with the system — even without an explicit attack on the gate. (Note: this is presence-loss-driven, distinct from the explicit conquest-by-attack mechanic in Direction 3.)
The same rule applies on the destination side for the gate's target — the destination orbital system also has an owner (or is unclaimed), and the relationship between a built gate and the destination's owner is its own design question (see open questions).
This interaction with the broader holdings model is deliberately narrow: gates do not interact with Claimed → Frontier → Colony-style stellar-object holdings directly. The only thing gate-building requires is system-level presence ownership, which is a separate (computed) concept.

The exact "presence metric" — what counts, how it is weighted, how quickly it changes — is out of scope for this idea and belongs to the system-ownership idea/feature wherever that lives.

Open Questions

Within-region placement: outer ring only, any system, or interior-override? See Direction 8. The three candidate models there are unresolved and have very different consequences for what counts as prime real estate inside a region.
Currency for the exponential jump cost. Direction 5a fixes the shape (flat build, exponential jump) but not what is spent per jump — a fuel/energy resource, ship-mass-scaled, a flat per-fleet charge, etc. Undecided.
A "gate type" intermediate between Jumpgate and Voidgate. Possibility kept open for future improvement — for example, a long-distance intra-galaxy gate that reaches across more region cells than a normal Jumpgate but cannot cross a galaxy boundary. Not yet thought through.
Navigation cost when Jumpgates connect non-neighbour regions. With Direction 5's research radius, two non-neighbour regions can be directly connected — meaning a route can skip galaxy-map cells between them with no pass-through region traversal. The recursive-traversal rule in add-stellar-pathfinding-and-distance still applies within each connected region, but the inter-region cost stops being a simple sum-along-the-galaxy-map-path. The cost shape (fixed-per-Jumpgate, scaling with Chebyshev distance, scaling with grid cells skipped, ...) is not yet decided and is something for future tuning when a gameplay mechanic actually depends on travel cost.
Destination ownership and gate eligibility. Direction 9 says only the system owner can fill the host slot. The destination side has its own owner (or is unclaimed). Can a player build a gate that points at an orbital system they do not own? If so, who controls the destination side's gate, traffic, and cooldown? This is the open political question on the receiving end.

Captured in dedicated idea pages

Exploration and knowing the universe — how players learn that regions and galaxies exist (active probes, passive observation, intel trade, espionage), how knowledge is shared/sold/stolen, and what the universe-map UI shows for unknown cells. See Knowing the Universe. Direction 6 above references it.
System-level ownership by presence — the exact metric, weighting, and transfer dynamics of presence-driven ownership. See System Ownership by Presence. Direction 9 above references it.
Spawn ring & candidate selection — how a new player's spawn location is picked when only part of the universe is available for search, while still keeping the spawn ring as the controlling rule and narrowing candidates through hierarchical clipping. See Spawn Ring and Candidate Selection.