Orbit Transfer Mini-Game

Version 1.6 includes a “mini-game” to demonstrate the maneuver and orbit transfer features. The scene has a spaceship and three space stations in circular orbits. The player can select a destination and then pick a manual maneuver or an orbit transfer. These actions rely on three key new features in GE 1.6: maneuvers, trajectory intercepts and orbit transfers. A quick demonstration of these is provided in the video below:

Selecting orbit transfer lists the type of transfer that can be used. Hohmann and a beta version of bi-elliptic are the current options (more choices in the next release!). Note that bi-elliptic is only a useful option for a transfer to the deep space station since this is the only case in which it saves energy. The use of orbit transfers requires a system in which there is a single massive body around which the ship and target are orbiting.

A manual maneuver allows the player to adjust the thrust and direction of the spaceship and shows the future path of the ship and target using the trajectory prediction feature. If the game logic detects that the ships path crosses the path of the target it will determine a maneuver to match the ship trajectory to the target trajectory. Trajectories are determined by simulating paths into the future and can be used in more complex gravitational systems where there are multiple massive bodies.

Design of the Mini-Game

The development of the mini-game was an essential tool in tuning the implementation of the maneuver-based features added in 1.6 and adjusting the API. The scene implementation is based on a game controller class model using the UserInterfaceRV script. The game controller loop handles:

  1. User interface state
  2. Ship maneuver commands
  3. Objective selection
  4. Checks for trajectory interceptions
  5. Determining allowable orbit transfers

Additional user interaction is handled in two other scripts:

  • CameraSpin: Handles camera orientation and zoom via keys and mouse (and scales LineRenderers in the scene during zoom via the LineScalar class)
  • TimeZoom: Adjust scene play speed as 1-5 are pressed

The active objects in the scene (1 spaceship, 3 stations) are top level game objects with NBody components and common several sub-components:

  1. A child that contains the model
  2. A child that contains a trajectory prediction component
  3. A child that contains a OrbitRenderer (for the stations) or an OrbitPredictor (for the spaceship)
  4. The spaceship model has a SpaceshipRV component that implements the thrust and rotation of the model.

The use of both a Trajectory and OrbitRenderer component was based on performance experience. In normal evolution the bodies are in a fixed orbit around the central star and an OrbitRenderer is a simple component with low CPU cost to draw the orbit in the scene. During a manual maneuver the trajectory component is required – so the game controller turns off the orbit predictor and turns on trajectory prediction for that game state. In this state the game is paused. Running trajectory prediction in all states can be done but there are some cases where long trajectories and high time zoom is used where performance can become an issue. This can be mitigated by disabling data recording in each trajectory component. Another advantage to the use of the OrbitRenderer is it draws a complete orbit for all bodies.

There is more to do…

This is really the tip of the iceberg, but I wanted to make the basics available early.

Things to do:

  1. Non-elliptical to non-elliptical planar transfers
  2. Inclination changes
  3. Rendezvous/phasing transfers (so arrive at a specific time/match a body in existing orbit)
  4. Transfer to orbit around a second body (e.g. Earth-Moon transfer). Likely via patched-conics.

These are on the Trello board. If you want to nudge them up the list, send an email to nbodyphysics@gmail.com.