Perilune

Flight View
Flight View 2
Moon Surface
Moon
Earth
LaunchPad
Title Screen
Earth Surface

Inspiration

I have always been fascinated by spaceflight, but following NASA’s Artemis program gave me a new appreciation for the difficulty of planning and flying a mission beyond Earth. Professional mission-planning software is highly specialized and difficult for newcomers to access, while orbital mechanics, gravity turns, rendezvous, and atmospheric entry can feel abstract when explained only through equations. I built Perilune to make those ideas interactive—to let anyone design a spacecraft, fly a mission, learn from failure, and experience what it is like to think like a flight director.

What it does

Perilune is a browser-based orbital engineering game set in a physically scaled Sun–Earth–Moon system. Players design rockets in the Workshop, launch from Earth, reach orbit, create maneuver nodes, transfer to the Moon, rendezvous and dock with other spacecraft, land, and return home. Guided scenarios provide a structured introduction: First Light teaches launch and orbital flight. Second Light introduces lunar transfers. The Artemis IV preview expands this into a representative guided lunar mission involving Orion operations, rendezvous, descent, landing, ascent, redocking, atmospheric entry, and splashdown.

Players can also manage (in-development)multiple active vessels, create alarms, operate communications relays, predict atmospheric entry, and plan transfers. Pip, an optional AI flight director powered by GPT-5.6, evaluates live telemetry and provides concise, evidence-grounded recommendations. There are three primary ways to play: unrestricted Sandbox, Exploration—where recovered science unlocks technology—and Space Program, which adds a constrained budget, launch costs, contracts, hardware recovery, and reputation.

How I built it

Perilune is written end to end in TypeScript and rendered with Three.js on a required WebGL2 runtime. Celestial bodies are evaluated analytically from orbital elements, keeping their positions stable under time warp. Vessel state is stored relative to its sphere-of-influence parent using JavaScript’s native f64 numbers. Before rendering, positions are converted into small, camera-relative f32 coordinates so the GPU maintains visual precision across distances approaching one astronomical unit.

Earth and Moon assets are produced through a deterministic compiler using public NASA and NOAA datasets. Vitest covers the simulation core, Playwright exercises complete browser flight paths, and Supabase provides cloud saves and server-side flight-director auditing. Codex with GPT-5.6 was used throughout implementation, debugging, technical review, provenance verification, and test-driven iteration.

Challenges we ran into

The most difficult rendering problem was preserving double precision across solar-system distances while ensuring the GPU only received small, camera-relative coordinates. Atmospheric entry was another major challenge. Heating and visual intensity needed to respond to actual atmospheric density, velocity, and vehicle orientation. Glow, trails, bow-shock effects, and particle breakup therefore emerge from the simulation’s heating signal instead of a scripted visual trigger.

For Artemis IV, the challenge was factual as well as technical. NASA’s mission architecture is still evolving, so the scenario uses explicit accuracy boundaries and labels its unmodified 2019 Starship concept as a visual stand-in—not an accurate HLS model or a reproduction of NASA’s final flight plan. Accomplishments that we're proud of Perilune now includes a genuinely playable progression slice: workshop → launch → orbit → transfer → landing → recovery. Docking, multi-vessel control, transfer planning, entry prediction, progression, and recovery operate through the same underlying simulation rather than disconnected scripted sequences. The Artemis IV preview adds an 11-chapter, resumable guided mission built around real player input and simulation predicates. It covers lunar approach, rendezvous, docking, descent, landing, ascent, return, entry, and splashdown while clearly separating representative training content from confirmed mission facts. I are also proud of the renderer: authored material tiers, atmospheric scattering, independent oceans, dual cloud layers, terrain transitions, and measured performance budgets all work together from orbit to the surface.

What I learned

Measure before reaching for the “obvious” heavy tool. I though about a legacy system initially which can still be accessed in settings , moving numerical systems into WebAssembly, but benchmarks proved TypeScript was best. The AI model tends to over-engineer a problem. Quite a lot of times I was struggling to pull it back from not rendering custom solutions. I also learned that asset provenance and factual boundaries are much easier to establish from the beginning than to adjust to a evolving real-world mission.

What's next for Perilune

The immediate goal is to complete Artemis IV release certification, including browser-matrix testing, accessibility checks, performance verification, and calibrated visual baselines. After that, I plan to integrate the whole solar system and keep the project upto date with the new mission parameters from NASA