Fun with Orbital Mechanics

Children of a Dead Earth uses an N-Body Simulation to simulate its orbital mechanics. Most other games which simulate orbits use the much less accurate Patched Conic Approximation, and I’ll go into the details of why in this post.

What is the Patched Conic Approximation, first of all? The Patched Conic Approximation treats all orbits as ellipses around a celestial body. Then, when actually making thruster burns, the current ellipse is swapped out for a new elliptical trajectory. When making an exit from one orbit into the parent body’s orbit, a new ellipse around the parent body is swapped in for the child body.

luna - periodic - bright.png
A perfectly elliptical orbit, although it rotates slightly with each period.

As you might expect, this is rather inaccurate. Indeed, when plotting actual spacecraft trajectories, NASA starts with the Patched Conic Approximation to get a “napkin estimate” of the trajectory, and then they switch to using an N-Body Simulation when they actually need to calculate it precisely.

Originally, Children of a Dead Earth was supposed to use Patched Conics. However, I discarded them when I wrote a simple N-Body Simulator to compare them against, and found the Patched Conics diverge very heavily from the N-Body Simulator. It was also the right choice: Switching to an N-Body Simulator allows a wealth of new orbital features, such as Orbital Perturbation and Lagrange Points.

So what is an N-Body Simulation? It’s simply a simulation which takes into account all gravitational forces in the entire system (in my case, the entire solar system) and applies them at each time step with a numerical integrator. Children of a Dead Earth uses a Fourth Order Symplectic Integrator by Forest and Ruth.

mercury - complex3 cropped.png
An orbit around Mercury perturbed significantly by the Sun.

Orbital Perturbation is a phenomenon that only shows up in an N-Body Simulator, and it makes a world of difference. Perturbation is simply the effects of gravity from more bodies than just the primary orbited body. Patched Conics do not simulate perturbation because they are only concerned with the gravity of one body at a time.

When orbits can be perturbed, they lose their perfectly elliptical shape and become at best distorted, and at worse, completely unpredictable, losing all periodicity.

mercury - simple cropped.png
Some orbits become perturbed so much that they become utterly unpredictable, and don’t seem to behave like orbits at all.

Why is this important? Consider the following story, which happened to one of my Alpha playtesters. He had spent a lot of delta-v injecting into orbit around Oberon in the Uranian system, and didn’t have enough delta-v to rendezvous with the destination space station around Oberon. His injection orbit was highly out-of-plane and succeeding seemed hopeless. But instead of giving up, he simply disabled stationkeeping, letting his spacecraft enter a free falling trajectory. Using the orbital perturbation of Uranus, he allowed the planet to perturb his out-of-plane orbit, gradually flattening it out into an orbit coplanar with the target space station. Eventually, by simply letting gravity do the work over several orbital periods, he had an orbit which could rendezvous with the target with minimal delta-v usage.

perturbed orbit.png
Using orbital perturbation in combat around Ganymede.

In combat, using orbital perturbation to your advantage is another effective but difficult technique to use. Dropping into a low orbit is often a useful tactical choice, as it forces your opponent to expend copious amounts of delta-v. However, it reduces orbital perturbation of nearby bodies.

On the other hand, entering very high orbits causes combat speeds to slow heavily, yet it costs much less delta-v, and it greatly enhances orbital perturbation. A perturbed orbit is much harder for the enemy to intercept because of its unpredictability, and the enemy will have to expend much more delta-v to reach you while you let gravity pull you along.

Furthermore, techniques like Orbit Phasing, which is a very effective way to intercept enemies, get thrown out the window when your target stops stationkeeping and enters free fall. Intercepting the enemy requires much more care than using simple maneuvers. After all, Orbit Phasing and Hohmann Transfers were developed for the Patched Conics Approximation, and are much harder to pull off in an N-Body Simulation.

l point 3.png
A propellant depot in a tight orbit around the Jupiter-Europa L4 Lagrange Point.

Lagrange Points are also simulated only through N-Body Simulations; Patched Conics fail to correctly simulate these. Lagrange Points are five or fewer points around each celestial body and its parent where an orbit that remains stable relative to both bodies. Children of a Dead Earth simulates all manner of Lagrange Point orbits, from simple circular ones to more exotic Tadpole Orbits.

l points 2.png
A figure 8 orbit around Mercury’s fourth Lagrange Point, Sun-Mercury L4. This orbit is a tadpole orbit that is twisted on itself.

That’s all for the N-Body Simulator! There is one additional aspect of Children of a Dead Earth’s orbital mechanics that is unique, and that is the way it handles multiple frames of reference, however, that will be another full post in and of itself.

9 thoughts on “Fun with Orbital Mechanics

    1. There is a sandbox mode with start date.

      Currently, only large mass bodies are modeled, which only includes a small percentage of the asteroid belt and some trojans (only the largest bodies). However, the game will be very moddable, and adding in smaller bodies is very doable.

      Like

  1. What books would you advise to read to program an orbital simulation like this? I’m familiar with programming itself and numerical methods, but still need to read up on their application to orbital mechanics.

    Like

    1. N Body Simulations are conceptually far simpler than most of the other engineering topics covered in the game, and I developed the one for the game without the use of any books. The only literature I used was for the numerical methods (of which there are a ton of white papers). For the actual numerical method I used for the N Body Simulation, look into:

      Forest, Etienne, and Ronald D. Ruth. “Fourth-order symplectic integration.” Physica D: Nonlinear Phenomena 43.1 (1990): 105-117.

      For N Body Simulations themselves, this scholarpedia article should have everything you need:

      http://www.scholarpedia.org/article/N-body_simulations

      Again, the bulk of the work will be in integrator. So if you use an extremely simple integrator like Forward Euler Integration, actually creating an N Body Simulation is trivial. For instance, a simple Euler Integration N Body Simulation is a common task for new computer science students. Here’s a homework assignment I found online after a quick search:

      http://www.cis.upenn.edu/~cis110/13sp/hw/hw02/nbody.shtml

      Like

  2. How are you able to have your future orbital position visualisations shown at an acceptable framerate? Clever caching? Or is your integrator just that fast? I was under the impression that the main reason other simulations used Patched Conics over N-Body Simulation was that they’re much faster, allowing you to look ahead in time to calculate speculative trajectories without chewing up the CPU.
    What number of bodies do you think the final game will be able to handle? Or put another way, how large a fleet will the player eventually be commanding?

    I love how this looks so far. Keep up the good work!

    Like

  3. I approve of the choice, though patched conics might be useful in planning orbits. But I’m not sure that a symplectic integrator is necessary or even helpful (interpolation can be annoying to get right). I’d also point out that the JPL solar system ephemerides (I assume you’re using these?) are calculated with a high-order non-symplectic integrator. But you’ve got one, and it works, so, um, great. But if people want to play with n-body integrators themselves, there are high-quality open-source libraries – the C++ library boost has several solvers, as does (e.g.) scipy. There are also open-source n-body codes (that is, including the right-hand sides and support code), though they’re mostly aimed at more specific problems (like simulating globular clusters).

    Like

Leave a comment