-
Notifications
You must be signed in to change notification settings - Fork 2
Trajectories Explained
Note: This is barely implemented in the code
A Trajectory class describes the movement of objects when they're not loaded in the physics engine, following the "strategy pattern." Objects in space, known as the Satellite class, should be able to follow many different kinds of paths in space. Satellites can be orbiting, landed, falling through an atmosphere, etc... Hard-coding orbital mechanics into the Satellite just isn't right. Having interchangeable strategies makes it easy to manage the state of a Satellite, as well as allow for all of the possible ideas discussed elsewhere, such as N-body, to be implemented cleanly.
Some trajectories don't have to be updated every frame, and can just be functions of elapsed time or something.
Some ideas:
- Landed Trajectory: for Satellites landed on a surface
- Kepler Orbit Trajectory: Patched conics whatnot
- N-body Trajectory: RK4 intergrators or something There should be a set of configs written somewhere that describes rules for which Trajectory should be used for what situation.
For an example of how this system might work, let's say a player is landed on the moon. The craft has active physics and is loaded, but is stationary and not moving. The player exits to the menu, causing the lander to get unloaded. The lander's Trajectory is then set to a LandedTrajectory, which only saves its spot on the surface relative to the planet. The player comes back to the lander after a few minutes, and the moon had rotated pretty far. For the game to know the lander's new position, it calls its Trajectory, which is set to a LandedTrajectory. LandedTrajectory calculates the craft new position based on it's stored relative position, and the current rotation of the planet.
Some crazy ideas:
- In-Flight Autopilot Trajectory: Plane eats fuel while moving through the atmosphere at constant altitude
- Parabolic Flat Earth Trajectory: because why not ¯\(ツ)/¯