Project Plan

The Design a Mars Mission project is an educational software simulator that shows how a spacecraft could travel from Earth to Mars.

The final project is a Docker-runnable Next.js web app that visualises a simplified Earth-to-Mars mission, showing Earth, Mars, a spacecraft, and the transfer path between the planets. It connects the visual simulation to real maths and engineering ideas, so the user can see both the mission animation and the calculations behind it.

Build an impressive Mars mission simulator that shows I can connect maths, engineering, software development and AI-assisted development in one project. It should demonstrate that I can:

• •Understand and explain real space mission concepts.
• •Use maths formulas in a practical software project.
• •Turn calculations into a visual 3D simulation.
• •Think like an engineer by considering trade-offs and mission risks.
• •Use AI tools to help plan, build and improve the project, while still understanding the output.
• •Package the final app with Docker so it can be run and demonstrated easily.

This project is not just about a good-looking website. It is about showing how software can explain a real engineering problem.

During Stage 2, the project developed from a basic 3D model into a calculation-driven mission simulator. Real orbital mechanics formulas are now used to estimate the Earth-to-Mars transfer path, travel time and required delta-v.

The calculated results are shown in a maths panel and connected to the visual scene. The spacecraft follows the generated transfer orbit, and the mission day and completion percentage update as the animation progresses. Mission inputs can be changed so the viewer immediately sees how different assumptions affect the journey.

Making this website has been the part of the project where the maths and engineering ideas turned into something I could actually see and explain. I began with a plain 3D scene, and by wiring it up to real calculations I came to understand how the numbers behind a Mars mission actually shape the journey.

The biggest lesson was that the visualisation only means something when it is driven by the maths. Getting the calculated results to generate the transfer path and control the spacecraft, instead of faking a curve, is what turned a nice-looking model into a genuine simulator.

• •How to build a responsive, multi-page website with navigation that works on both desktop and mobile.
• •Connecting maths to visuals, using calculated results to generate the transfer path and drive the animation rather than hard-coding it.
• •The orbital mechanics of a Hohmann transfer, and how the semi-major axis, transfer time and launch geometry fit together.
• •Working with delta-v and the Tsiolkovsky rocket equation to see how velocity change trades off against fuel and mass.
• •Why Kepler’s laws of planetary motion mean spacecraft follow curved orbital paths around the Sun instead of straight lines.
• •Using AI as a development tool, planning, prompting, reviewing and correcting its output while still understanding the code and the physics behind it.
• •Explaining technical work clearly so that someone without a science background can follow it.

Photos of my own handwritten research notes behind the mission maths. Tap an image to open it full size.

Screenshots of the live simulator captured for the Stage 2 checkpoint. Tap an image to open it full size.

1 · Maths panel

Show a formula, substituted values, transfer time and a delta-v result, with the input controls where possible.

“Stage 2 maths panel showing the orbital formulas, mission values and calculated results.”

2 · Transfer orbit & spacecraft

Earth, Mars, their orbit rings, the calculated transfer path and the spacecraft on that path.

“Calculated Earth-to-Mars transfer path used by the spacecraft animation.”

3 · Changed assumptions (optional)

After changing one input: results update, the path changes and progress stays synchronised.

“The simulator recalculates the mission when an input value changes.”

During Stage 3, the project came together into a complete final showcase. The maths-driven simulator gained an engineering layer that judges whether a mission is actually sensible, and the whole site was pulled into one place ready to present.

The simulator now compares the delta-v a spacecraft can produce against the delta-v the transfer needs, and reports a clear verdict of feasible, risky or impossible. Engineering trade-off cards explain the balance between fuel, engine efficiency, journey time and risk. A new Presentation page brings the deck, the demo script and a readiness checklist together, and the thirteen-slide presentation is exported as a downloadable PowerPoint.

Stage 3 was where the project stopped being just a calculator and started behaving like a real engineering exercise. Adding the delta-v comparison and the feasibility verdict made me think about the mission the way an engineer would: not whether a number can be produced, but whether the design leaves enough margin to be safe.

The biggest lesson was that presenting the work is part of the engineering. Building the trade-off cards, writing the demo script and preparing the deck forced me to explain every decision simply, and that made me understand the maths and the compromises far better myself.

• •How a safety margin turns a raw delta-v figure into a real decision, and why a mission can be mathematically possible yet still too risky.
• •How engineers balance competing priorities, more fuel raises delta-v but adds mass, and a faster journey costs more energy.
• •How to compare available and required delta-v visually so a non-technical viewer can see at a glance whether a mission works.
• •How to turn a whole project into a timed presentation, sequencing the demo and choosing which formula and which change to show.
• •How to document a project in a README so someone new can understand how it works, how to run it and how AI supported the build.