# Building (simple) stellar systems

I'm currently looking at how to easily simulate some stellar systems (meaning some central stars and then some planets with maybe satellites), in order to allow later some space based strategy game (hence with space ships moving around). This should all be based around time (so the state of each system differs through time)

I'm quite struggling with the math behind this topic, like for example:
- ellipse related math,
- creating the path from planet A to B having time in mind (respective positions will change over time)...

Do you know of any resources for that ? I wouldn't mind even buying books about it...

side note: how to display all this stuff isn't a matter at this point in time, I'll simple plans for that (basically sticking to 2D and a "high level view" with no space ships/planets details, just markers)

-
is the ellipse math about the motion of satellites about the planets ? –  brainydexter Feb 21 '11 at 16:12
the ellipse math is because I thought planets are following an ellipse in their course around stars. Is it wrong ? The ultimate goal is about representing quite properly the planets' courses in a system. –  space borg Feb 21 '11 at 21:09

I am not a math brain, but my S.F. reading and Google lead me to this page on orbital mechanics. It starts with explanations I can follow and follows it up with equations I can't. The type of motion I was looking for is called a Hohmann Transfer Orbit, which is one that uses the least fuel.

-
thanks a lot Jason: I had searched for similar content with no success. Still, it's only about space physics, not how to apply them in a game kind of way (how to map them down in a strategic 2D kind of display). Still, it's the closest I've seen, thanks a lot :) –  space borg Feb 21 '11 at 21:44
To map them to 2D just remove the Z dimension, all of the math should still work just as before. As far as applying them to a game goes, they are just formulas.. I would assume with a known start point, the formula for motion and a offset time value you could always calculate where each celestial body would be. –  James Feb 22 '11 at 1:17

Do you even need to solve this? Hohmann transfer orbits are SLOW--1/2 the orbital period of the outer body and they also require a proper alignment of the planets to work.

Do you really want to limit players to such motions? And if you're doing that you are obviously using some sort of jump drive to get to the other star systems--why can't you use that within a system?

If you have any sort of continuous thrust system of non-trivial power you don't need to do such fancy orbital calculations. Instead:

1) Figure the velocity change needed between the bodies. This is both orbital velocity and the energy needed to move to the new orbit.

2) Figure the distance between A and B at their current positions.

3) Adjust this for the burn needed in part #1. If you're going outward figure an extra burn at the start for the velocity change, if you're going in the extra burn is at the end. Subtract this distance from the distance between the planets, add the time needed to the total time.

4) Take the remaining distance, divide in half and figure how long it will take your rocket to do this. Double the result.

5) Add the times involved, figure where the target planet will be after that burn is over. If it's moved too much use the new location of the planet as your target, redo the calculations. This will rapidly converge.

Yes, this isn't up to NASA-spec but it's plenty close enough for game use.

-

As Jason mentions above, take a look at this web page -- it goes pretty deeply into orbital mechanics...

http://www.braeunig.us/space/orbmech.htm

I am wondering if you might be able to work out a simple rule based system for navigation. Simply "launch" the vehicle on some vector, then on each pass of your event loop, have it look at it's current trajectory in relationship to the destination, and apply a correction.

When it gets tricky is where you have to take into account what you might call the motivations of the spaceship. Does it have a finite fuel supply? Is it better to get there faster, or to use less fuel? Is the velocity you approach the target important? I.e., can it just come flying in at a high speed or does it need to slow down to enter orbit?

-
Doh - I just realized I duplicated Jason Pineo's post above in referring to the orbital mechanics page. I'm removing that part of my answer and just keeping the "simple rule system" part. –  Tim Holt Feb 25 '11 at 0:32

There is another issue which you may want to give some thought to as well besides the physics of simulating a stellar system.

Floating point precision will likely be an issue depending on how much of a "simulation" it is. When you think about it, the actual distances between a planet relative to the distance of an object orbiting around one of those planets is huge. Trying to simulate both a distant planet and an orbiting object in the same "environment" would likely break under the limitations of floating point accuracy.

http://www.floatingorigin.com/mirror/oneil_01.htm

-

creating the path from planet A to B having time in mind (respective positions will change over time)

Lookup linear interpolation. It lets you update a position from point A to B along a straight line using a function of time.

This link might help.

-
I believe the question is asking how to calculate the route between point A and B when point B is moving while you are moving towards it (ie: how to 'lead' the target planet so when you arrive its not on the Other side of the central star) –  James Feb 21 '11 at 18:45
@James: "(respective positions will change over time)" :-> It isn't exactly clear if the points are constantly in motion or if A and B are fixed and then they will change later on. If points are fixed, IMO linear interpolation is the way to go. –  brainydexter Feb 21 '11 at 18:55
Sorry man, I can not find a way to read that line where its not stating that points A and B will change over time... –  James Feb 21 '11 at 19:24
indeed it was between 2 planets, so between moving points, hence linear interpolation is out I guess. Yet thank for the link :) –  space borg Feb 21 '11 at 21:38