Dev Log: Rethinking CelestialBody Hierarchies and Orbital Architecture

Date: May 27, 2025

Over the weekend and into today, I took a hard look at how celestial objects and orbital relationships are structured in the simulation. What began as a cleanup effort turned into a broader reconsideration of how CelestialBody, StarSystem, and related components like Barycenter, AsteroidField, and LagrangePoint are organized. The original design was functional but started showing strain under the growing complexity of multi-body dynamics and rendering.

Motivation: When Composition Outgrows Inheritance

At the heart of the issue was a growing tension between data modeling and simulation responsibility. CelestialBody had become the de facto base for everything in a star system — stars, planets, barycenters, asteroid fields, you name it. But not everything orbiting something else should be a celestial body in the same way.

• Barycenters are not physical bodies; they’re abstract orbital anchors. Including them as CelestialBody subclasses was semantically wrong and introduced risk for simulation drift and logical errors.
• StarSystem itself was treated as a CelestialBody, even though it serves as a container for bodies, not a body itself. This introduced positional ambiguity and led to circular logic during rendering and orbital math.
• Meanwhile, fields and belts like asteroid regions are spatial regions but don’t act like physical objects — they also didn’t belong in the same hierarchy without modification.

These realizations triggered a wider architectural pivot.

Key Decisions and Changes

1. Elevating IOrbitingObject as the Core Simulation Anchor

We’ve formally introduced IOrbitingObject as the shared interface for all orbit participants, whether physical or abstract:

• CelestialBody implements it.
• Barycenter now does as well — but no longer derives from CelestialBody.
• Future support for INaturalOrbiter and IArtificialOrbiter will allow for flexible modeling of both planetary bodies and spacecraft.

This clarified our simulation logic: orbiting is a behavior, not a physical trait.

2. Decoupling StarSystem from CelestialBody

StarSystem is now purely a spatial container. It:

• Defines local simulation context within a Sector.
• Maintains a list of orbiting objects (stars, planets, barycenters, etc.).
• Tracks local offset within the sector (in light-years).
• Will handle rotation/orientation for rendering consistency.

This change makes it much easier to reason about systems as navigable spatial units, not just celestial nodes.

3. Simplifying Edge Cases Like Belts and Fields

Rather than force AsteroidField and LagrangePoint into CelestialBody, we’re allowing them to be standalone orbiting objects with specialized properties:

• Belts can define visual rendering arcs and particle population densities.
• LagrangePoints can host Station, Probe, or Fleet entities later, without violating physical structure.

This opens the door for emergent system structures like asteroid mining zones, defense outposts, or refueling points — all orbit-aware, but not physically rendered like planets.

Why This Matters

This reorganization is about conceptual clarity and long-term extensibility. It gives us:

• A clean divide between physical bodies and orbital anchors.
• A flexible, pluggable interface (IOrbitingObject) that scales across natural and artificial entities.
• A more robust foundation for future features: stationkeeping, orbital transfers, barycentric systems, even spacecraft trajectories.

This wasn’t just a refactor — it was a rearticulation of the simulation’s mental model. And that’s the kind of shift that pays off for years.