Game Premise
SolarApp is a sophisticated .NET 10 + Godot 4.7.1 (.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:
🌍 8 Planets
Complete planetary orbits with accurate orbital mechanics, positions updated dynamically based on date/time.
🌙 400+ Moons
Planetary satellites with hierarchical orbital calculations relative to their parent planets.
⭐ 10,000+ Asteroids
Dwarf planets and minor bodies rendered from MPC orbital element databases.
☄️ 1,700+ Comets
Periodic and long-period comets with precise orbital trajectories.
Architecture Overview
SolarApp is built on a layered, dependency-injection-driven architecture with clear separation of concerns:
- Domain Layer (libraries/) — Keplerian physics, spacecraft mechanics, mission compilation, game state management
- Client Libraries (SolarApp.RenderCore / .Presentation / .AppCore) — engine-free render math, view models, and craft/mission services
- Godot Client (SolarApp.Client) — autoload composition root, one scene layer per rendering concern, Control-based glass UI
- Mission Catalog (SolarApp.Scenarios/) — declarative mission JSON compiled through the production solver stack
- Panel Harness (SolarApp.Client/Scenes/Debug) — scenario-driven visual host that renders the real side panels outside the game
Technology Stack
- .NET 10 — Modern C# runtime with LINQ, async/await, records, nullable annotations
- Godot 4.7.1 (.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 — 3D-lit spheres rendered to texture, 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
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.
Learn More
Explore the deep dives into specific aspects of the project:
Astrial API & Physics
Understand how Kepler's equations power accurate orbital calculations and gravitational influence modeling.
Read Article →Missions
Follow a fusion-drive grand tour from declarative JSON through the course compiler to synchronized playback in the game and debugger.
Read Article →UX Architecture
Explore the MVVM pattern, SOLID principles, and the blend of modern UI design with Godot.
Read Article →Data Creation Pipeline
Discover how we built the solar system database using Python, Jupyter notebooks, and sprite generation.
Read Article →AI-First Development
Learn how MemPalace and Claude.md files enforce standards and enable AI-assisted development.
Read Article →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/.runsettingsRequirements: .NET 10 SDK and Godot 4.7.1 (.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.