Space Exploration Stack Exchange is a question and answer site for spacecraft operators, scientists, engineers, and enthusiasts. It only takes a minute to sign up.
Sign up to join this community
I'm in the process of programming a space game which will involve a 3-body system. I'm thinking of making a simplified version of the restricted 3 body problem where:
Body A is fixed in space,
Body B is in a fixed, circular orbit around body A,
and body C is of negligible mass and is influenced by both body A and B.
I need help with body C's equations of motion.
@Woody is certainly correct; anything beyond two body Keplerian conic trajectories (be they simple or be they patched like KSP's) will require numerical integration somehow, somewhere, and your mission should you choose to accept it is to decide if you want to do it live in real time during the game, or use pre-calculated trajectories, or a combination of both.
Numerical integration sounds scary at first but is not hard once you get your feet wet. Some computer languages will have libraries with canned numerical integrators already available, and there are really simple to code yet fairly accurate methods modified Euler and backwards Euler and the split-step backwards Euler all of which are a few lines of easy code.
RK45 is my favorite as it also allows you to add a dynamically variable step size function based on the current situation.
Related:
As with all models, they're all wrong, but some are useful. If you are programming an interactive game with limited computational resources you may find yourself always trading off between accuracy and speed. You will have to find your own way through this, it will become a big part of your game design decision making.
Woody's idea of pre-calculated trajectories is great, but the problem here is that if you want to go for a long time in an unstable and chaotic n-body trajectory, they tend to bifurcate wickedly! A tiny difference at one point in time can mean way way different trajectories later on. (cf. the butterfly effect).
One way to make the computation time issue a feature not a bug is to make it part of the game, something like "Mr. Sulu, plot a course..." during which time the calculation happens in the background and the gamer has to sit in their current orbit like a sitting duck until it's ready.
See for example this answer to What sort of orbital elements are used to describe halo orbits? and references therein, from which I will include the following screenshots (click for full size)
Ilmari Karonen is right. An exact solution would be numerical, which would occupy a fair amount of computing power for a game application. It may be more practical (if less accurate) to use an approximation model which is easier to compute. This is analogous to the way Kerbal uses patched conics.
One strategy would be to pre-calculate nested invariant manifolds in the orbital plane, since most of the game action will be in that plane. With only 2 massive bodies, the manifolds would be much less complex than those you may have seen for the Sun/Earth/Moon/JWST system. The parameters for the pre-calculated manifolds could be stored in a look-up table. The game spacecraft could be assigned to the nearest manifold. If the spacecraft’s state vector does not match a manifold, you could revert to patched conics.
I may be completely OTL with this since I am not a gamer, programmer or mathematician. I hope your project works. One great thing about Kerbal is the way it displays the projected track in real time as you vary the control inputs. It’s a great way to acquire an intuitive understanding of orbital mechanics. I hope your game will display the surface of the manifold your vessel is currently travelling on, as well as showing the manifold shape change with control inputs.
Good luck with your project.
https://www.aanda.org/articles/aa/full/2006/25/aa4653-05/aa4653-05.fig.html
