Seeking "simple" orbital path planning for game development

[AlwaysSunny]

Hi PhysicsForums!

I'm a game developer planning a project involving simplified, idealized orbital mechanics. I made this reddit post which did not generate the sort of response I was hoping for, but it summarizes my issue in greater detail for anyone curious: https://www.reddit.com/r/AskPhysics...d_simple_path_planning_for_orbital_maneuvers/

I'd like to offer players the ability to choose a vehicle and a desired situation, and what I need is a "nice looking" approximation of the "best path" to transition from one situation to another. I was seeking a way to "fake" predictions and maneuver planning with some light math, as distinct from actually creating a full-fledged simulation in which to compute accurate solutions. Thanks to knowing the start and end situations in advance, I imagined a simple way to compute a convincing curve from one to the other without - well - rocket science.

The only response I received suggested that I create a full simulation regardless, which may be my best option after all. In which case I'm still in need of an efficient path-solving algorithm, and I have no clever ideas about improving its structure. The only approach which comes to mind involves expensive heuristics, testing hundreds if not thousands of prograde thrust vectors applied at hypothetical times and magnitudes, until one such combination brings the predicted path close to the desired situation (then another round of retro tests at the periapsis of the destination to enter and circularize the orbit).

Surely there are some principles I can apply which might reduce the number of samples required (put me in the ballpark), which is what brings me here. Or better still, an approach which might avoid this simulated model altogether while still producing convincing results. It only needs to look nice, after all.

Any commentary will be most welcome,

Thanks for your time!

 

[Bandersnatch]

Hi,

In the reddit thread you made an off-hand comment about Bezier curves - I think that's a good idea (insofar as I can tell not knowing much about programming).
You could perhaps use them to simulate Hohmann transfers by drawing half-ellipses (or something that looks sufficiently like one) with one end tangent to the planet surface and the other to the target, and the focus at the centre of the central planet. The target here is the position of the second orbiting body predicted for the time the craft completes the transfer.

That this is a planetary moon system, it makes waiting for the launch window almost a non-issue - either you wait for the planetary diurnal rotation to move the launch point into the favourable position, or make it a bit more realistic and make every launch first enter into a low planetary orbit (depending on level of detail either with another section of an ellipse, or just with an eyeballed curved line, or even magically), and let it start the manoeuvre when its parking orbit takes it to the launching spot (in a matter of minutes to hours, depending on the parent body mass).
Launching from non-rotating satellites would require the second approach.

With transfers from a satellite in a higher orbit to a lower orbit, there's a slight issue with first having to leave its local gravitational influence, so that drawing half a transfer orbit to the parent planet does not make the craft collide with the satellite. You could use here a curve that looks like the Apollo free-return trajectory - i.e., an S-like shape (a quartic Bezier curve), or fudge the elliptic shape of the trajectory to look like two ellipses with foci at each of the massive bodies, stitched together.

So you'd have two types of curves for two types of transfers. In calculating transfer times I'd pretend they're all ellipses focused on the parent planet, and use Kepler's 3rd.

 

[AlwaysSunny]

Ah, this is great; what a nice reply! I really appreciate it.

Thanks for helping to validate and expand on this "faking it" idea. Spending dozens of hours refining a true simulation and dynamics calculator just struck me as silly when I merely want to look fancy.

All operations will be broken into their most basic form, so I'll definitely be parking before transferring, which makes launch time a moot issue. Likewise, landing could simply begin when the curve to the destination will appear sufficiently gradual. Rendezvous could have similarly simple logic - either move "out" to wait or "in" to catch up until the resultant curve-to-target looks nice. What properties constitute "looking nice" is something I imagine I can discover experimentally.

Assuming success, that's every other issue taken care of, but creating nice transfers remains mysterious. There are plenty of cases in which starting a transfer "right now" would be impractical (one moon to another), though perhaps I can identify those patterns by experimenting. Care to weigh in on this?

Your explanation led to a fresh idea: By putting the player in charge of when the transfer begins, I eliminate that whole aspect of the problem. I already want the player to schedule many things, so it can be their discretion whether the resultant path and its duration are acceptable. I'll give them an interface to "scrub through" potential departure times, and whatever curve-building function I come up with will take departure time as an argument.

I wish I could say I felt confident that I can build such a function - one which properly responds to any given scenario - though it's fair to say it sounds more practical for my purposes than a bona fide physical simulation.