Game Premise

SolarApp is a sophisticated .NET 10 + Godot 4.7.2 (.NET/mono) cross-platform desktop application that simulates our solar system in real-time. Using actual orbital-element data and Keplerian orbital mechanics, it positions and renders:

Architecture Overview

SolarApp is built on a layered, dependency-injection-driven architecture with clear separation of concerns:

Technology Stack

• .NET 10 — Modern C# runtime with LINQ, async/await, records, nullable annotations
• Godot 4.7.2 (.NET) — Cross-platform engine (Vulkan/Forward+) hosting a net10.0 assembly; the domain stack runs unchanged inside it
• Godot Control UI — Side panel, top bar and modals built from Control nodes over a code-built glass theme
• GdUnit4 — Headless scene tests run through plain dotnet test
• Dependency Injection — Microsoft.Extensions.DependencyInjection for loose coupling
• Domain-Driven Design — Layered architecture with .Interface/.Core splits
• Keplerian Orbital Mechanics — Newton-Raphson solver for position calculations
• Real Data Sources — MPC (Minor Planet Center) and JPL orbital elements

Key Features

Dynamic Orbital Mechanics

Every celestial body's position is calculated in real-time using Keplerian orbital elements (eccentricity, semi-major axis, inclination, etc.). The system updates planetary orbital elements over time to maintain accuracy across decades or centuries of simulation.

Layered Rendering Pipeline

The scene is one node layer per concern, drawn in child order — adding a visual concern means adding a layer, not editing the view:

• Bodies — Sun-lit planets drawn as analytic spheres in a fragment shader, sprite fallbacks, minor bodies
• Traces — Orbit paths, velocity trails, and compiled mission courses
• Belt — 11,000+ asteroids uploaded as bulk multi-mesh buffers
• Decorations — Selection halos and sphere-of-influence rings

A planet is not geometry: one quad per body, and a fragment shader that reconstructs the sphere from the pixel's own position — surface normal, equirectangular lookup, and a terminator cast by the real direction to the Sun. It costs no render target, holds up at any size from a three-pixel moon to a full-screen hero, and puts the drawn limb exactly on the diameter the halo rings and click targets are measured from.

All world-to-screen math runs in double precision before anything reaches the engine's 32-bit transforms — at 50,000× zoom, single precision loses the orbit.

Data-Driven Design

The simulation loads orbital data from generated JSON files built from authoritative sources (MPC, JPL). This allows easy updates and integration of new celestial bodies as data becomes available.

Mission System

Spacecraft fly compiled missions: a flight plan is authored as declarative JSON intent (gravity assist here, flyby there, capture at home), solved into a full N-body trajectory by the mission compiler, and replayed identically wherever it is flown. See the Missions deep dive for a four-year fusion-drive grand tour worked end to end.

The fleet opens on a working route rather than a launch pad: four Hermes-class ships fly one Earth–Mars round trip at four different stages at once — one mid-crossing outbound, one a third of the way home, one waiting at Mars to leave and one waiting at Earth. Two of them are deliberately off-window, and they have to be: real transfer windows fall 780 days apart while a crossing lasts half a year, so on minimum-energy trajectories “mid-cruise now” and “departing now” are mutually exclusive. Flying off-window costs 25,579 and 29,782 m/s where the on-window ship buys the same crossing for 14,863 — which is exactly what the extended-tank refit is for.

A Fixed Start Date, Chosen at Launch

The simulation opens on a fixed epoch rather than today's date, so the fleet a player meets is the same fleet on every launch and a test can assert what they will actually see. The default is 16 April 2056; a boot screen offers three other dates alongside it, and the difference between them is which voyages have already sailed — the pinned missions, Hermes to Mars, Trailblazer to the Moon and the three-ship Mars rotation, keep their own departure dates whatever start is picked, so a later start finds them under way or already home.

Every offered date is measured, not assumed: all eleven flight plans are compiled at it before it can appear in the list. The fleet's fuel budgets sit close enough to their tanks that a plausible-looking date can put a ship past hers.

Learn More

Explore the deep dives into specific aspects of the project:

Getting Started

To run SolarApp locally:

# Build the engine-free solution (domain + client libraries)
dotnet build SolarApp.sln

# Build the Godot client (Godot does not build C# for you)
dotnet build SolarApp.Client/SolarApp.Client.csproj

# Run it
godot --path SolarApp.Client

# Run all tests
dotnet test SolarApp.sln
dotnet test SolarApp.Client/SolarApp.Client.csproj --settings SolarApp.Client/.runsettings

Requirements: .NET 10 SDK and Godot 4.7.2 (.NET build) to develop; Windows, Linux, or macOS with working Vulkan drivers to run. Released builds are single self-contained executables — no .NET install and no data folder to copy.