Skip to content

Spawn Ring and Candidate Selection

This page explores how the current spawn-ring algorithm picks which orbital system a new player spawns into in a partially-generated universe.

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

This is the algorithmic companion to New Player Spawn. The broader spawn page covers what happens around spawn — homeworld creation, starter protection, occupied-system fallback, and player-facing rules. This page focuses on the candidate-selection mechanism itself.

Goal

Keep the spawn ring as the main control for new-player placement while making it precise enough to work with lazy generation.

Secondary goals:

  • Keep the search cost bounded as the player population grows.
  • Avoid turning a touched galaxy or region into "all descendants are now candidates".
  • Keep homeworld creation limited to adding a planet inside an existing orbital system, not creating new systems.
  • Distinguish clearly between touched search space, candidate systems, and actual generation work.
  • Make the candidate-calculation rule still definable if galaxies or regions later stop sharing uniform dimensions.

Core Problem

The spawn-ring principle is already the right direction. The problem is that some descriptions of it blur together several different concepts:

  • a single canonical spawn radius in universe space
  • hierarchical clipping at the galaxy and region-map layers
  • candidate eligibility at the orbital-system cell layer
  • generation work that happens only for the final chosen system and whatever maps are needed to descend into it

Once those concepts get mixed together, the description drifts into wrong assumptions:

  • a touched region sounds like all systems inside it are direct candidates
  • the ring starts sounding like it operates at the stellar-object layer inside a system
  • species compatibility sounds like a property of systems, even though the homeworld is created as a new species-matching planet
  • "generate a region" starts sounding like "generate every system in that region"

The page needs to describe the current algorithm more sharply, not replace it with a different one.

There is also one real unresolved extension case: the current settled implementation direction keeps uniform dimensions per map layer because that makes clipping cheap and predictable. That does not answer how candidate calculation should work if galaxies or regions later have genuinely different sizes. If that variation is allowed back in, the candidate rule must stay ring-based without falling back to "touched parent means all descendants".

Working Directions

1. One canonical square ring

The current direction keeps exactly one spawn ring in universe space.

  • The ring grows outward from the universe centre as founded holdings increase.
  • The ring is not redefined separately per galaxy, per region, or per orbital system.
  • Galaxy and region layers only receive a clipped local view of that same border.

This keeps spawn expansion legible: one radius decides where the live frontier for new-player placement currently sits.

2. Descend and clip, never flood descendants

The ring applies to the RegionMap layer and above. It does not jump from "this parent was touched" to "all children are candidates".

  • If the ring touches a galaxy footprint, the algorithm descends into that galaxy's map.
  • If the clipped border touches a region footprint, the algorithm descends into that region's map.
  • Only orbital-system cells whose footprints intersect the final clipped border become candidate systems.

This preserves the spawn-ring principle without letting one touched parent explode into hundreds or thousands of immediate candidates.

3. Mixed-size layers need explicit footprints, not implicit translation

If galaxies or regions have different dimensions, the current cheap "translate the same clipped square into local map coordinates" model stops being sufficient.

The viable direction is to calculate candidates from explicit child footprints at every level:

  • Every galaxy footprint is expressed in universe-space units, using its real width and height.
  • Every region footprint is expressed in galaxy-space or universe-space units, using its real width and height.
  • Every orbital-system cell footprint is expressed in region-space units, using its real size and offset.
  • The spawn ring still stays one canonical square border in universe space.
  • A child is touched only if that exact child footprint intersects the border segment that reaches its parent.

That means mixed-size candidate calculation becomes:

  1. intersect the canonical ring with each galaxy's real footprint
  2. clip the surviving border segment to that galaxy
  3. test that clipped segment against each touched region's real footprint, not against an assumed fixed-size region slot
  4. clip again
  5. test only the final orbital-system cell footprints against that clipped segment

This keeps the spawn ring intact even when sibling galaxies or regions are not the same size. The key change is that candidacy comes from real geometric footprints, not from layer-local cell counts or uniform-size assumptions.

4. Mixed-size traversal probably needs a read-side spatial summary

The geometry above is correct but can get expensive if every spawn must test many differently-sized child footprints one by one.

The likely support structure is a read-side summary per map layer:

  • each child entry carries its absolute offset and real footprint bounds
  • parents expose enough bounding data to reject untouched children cheaply before deeper clipping
  • optional edge summaries can answer "which children can this border possibly touch on this side" without scanning every child

Without that kind of summary, mixed-size support risks turning each spawn into a broad geometry walk. With it, the algorithm stays ring-bounded even though the children no longer share a common template size.

5. Candidate systems are not species filters

The candidate-selection step is about choosing a valid orbital system, not about finding a pre-existing species-matching planet.

  • The homeworld is created as a new species-matching planet inside the selected orbital system.
  • A system does not become invalid just because it does not already contain a species-compatible planet.
  • Species compatibility belongs to homeworld creation, not to the ring geometry.

This keeps the selection problem focused on placement, occupancy, and ranking rather than on the wrong system-level filter.

6. Region generation does not generate its systems

The description needs a strict distinction between parent-level readiness and child-level generation.

  • A touched region means the algorithm can evaluate that region's map surface for touched system cells.
  • It does not mean every orbital system inside the region is generated.
  • The spawn flow still generates only the final selected orbital system.

This is the key lazy-generation boundary: search can descend through map surfaces without turning every possible child into a fully generated world object.

7. Fallback expands the same ring model

When the current ring yields no valid system, the algorithm should continue outward through fallback expansion rather than switching to a different candidate model.

  • The first player still uses the same algorithm with the initial non-zero radius.
  • Later players still use the same algorithm with a larger preferred radius.
  • Fallback should mean "expand the same ring and try again", not "count generated children", "search stellar objects", or "treat all systems in touched parents as equivalent".

This keeps the algorithm coherent across first spawn, normal spawn, and late sparse-universe cases.

Open Questions

  • How is "central" defined when the universe map has no exact centre cell (even dimensions, off-by-one)?
  • If galaxies or regions really do get different sizes again, what exact footprint data must each map expose? Absolute coordinates, parent-local coordinates plus scale, border intervals, or something else?
  • For mixed-size layers, what is the cheapest pruning structure that still preserves exact candidate correctness? Full child-footprint lists, edge summaries, interval indexes, or another spatial index?
  • Is mixed-size support worth the extra traversal complexity, or should uniform dimensions remain a hard rule for spawn selection even if other systems would benefit from variation?
  • What exact surfaces must exist to descend through a touched galaxy or region? Is aggregate generation enough, or must the relevant map surface be available independently of child-system generation?
  • How does spawn interact with player-built connectivity? Under fully player-built connectivity, does spawn have privileged rights to open the necessary search surfaces, or must it stay within the same discovery limits as normal expansion?
  • What is the right fallback cap for sparse late-game universes? The algorithm should expand the same ring model, but how far can it go in one spawn attempt before the game accepts an occupied-system fallback?
  • What happens when the ring touches plenty of systems, but all unoccupied systems are exhausted? Should occupied-system fallback happen at the current ring immediately, or only after one or more outward expansions?
  • What does the algorithm do when the universe itself becomes saturated and even widened fallback rings stop producing acceptable results? Refer back to the universe-cap discussion in Player-Built Connectivity Direction 7.