[Parent issue] Star hopping

[aggregate1166877]

Subtasks

• #7
• #38
• #55
• #57
• #58
• #59
• #60
• #65
• #73
• #76
• #79

Brief description

Implementing rapid travel to other stars via hyperspace is now feasible to implement. This task seek to define the set of features to achieve this.

Definition of done

• User can choose a star as a destination.
• Ship modules exist to facilitate navigation.
• User presses a button to initiate a jump.
• Skybox and 3D stellar object should update as part of the jump.

Full description

Note: the below was a brain dump meant only for myself, so it's all over the place and needs to be improved. It eventually became a lengthy document so I decided to paste it here.

Units

Large: parsec
Small: centiparsec (0.326156 ly)
Tiny: meter

Navigation

Universe global coordinates are in parsecs. All other coordinate systems are derived from those coordinates.
If in doubt, application will get location in parsecs and convert to smaller units from there.

Your local coordinate units are in meters. Your local coordinates always snapped to the nearest
gravity well (i.e. nearest star in sane space, nearest black hole in busier
space). If you are in a star's coordinate system, and while travelling you find
yourself nearer to another star, your coordinates will suddenly drastically
change to reflect this new positioning. Note that this means recalculating ship
position relative to the rest of the universe. We have the difference in x,y,z
coordinates relative to the new star, we can change our coordinates using that in a
calculation.

This can be seen as a feature: your nav system detects ambient gravity and
orients you accordingly (or, maybe it's a hidden number and no one knows /
cares about it).

Point is, we need local coordinates in meters else things will be jumpy, but on the
hand, we can't travel more than 0.95 ly or things get jumpy anyway. So this is
a trade-off that will, at least in theory, have minimal or no graphical
glitches. If we do end up having glitches, we can invent controls to work
around this.

Procedural generation

The procedural engine always works off global coordinates (units in parsecs).
The engine will then convert this to local coordinates (in meters) for the ship
to fly in.

Development

#59 [now complete] Create a real star skybox, but just plain - nothing fancy. Does not update as
you fly through space. It's plain, boring. Maybe later add dust and whatnot for
pretties. But keep the logic basic. The only not-so-basic bit is that it needs
to be done in a web worker.

• https://stackoverflow.com/questions/15558418/how-do-you-save-an-image-from-a-three-js-canvas
• https://stackoverflow.com/questions/26193702/three-js-how-can-i-make-a-2d-snapshot-of-a-scene-as-a-jpg-image
• https://stackoverflow.com/questions/16431318/webgl-single-frame-screenshot-of-webgl

#55 Start by procedurally generating ~4 stars. Place Sol in center, and Alpha Cen +
friends nearby. This gives us 1 manual, 1 triple manual, and 4 procedural
stars. These are not part of the skybox calculations. At first, just draw
them as normal dots via shader in the sky. For easy pseudo-realism, you may
choose to hardcode an Alpha Cen exclusion in the skybox code.

Code in support for star gravity. Warp drives should experience drag closer to
these bodies.

Somewhere during all this, you'll need to put a sun shader on your stars.

Now, code flying between stars. The procedural stars should support
the whole coordinate snapping mechanism. The requirements are as follows:

• You should have navigational systems that understand finding stars, setting
  stars as jump destinations, etc.
• The coordinates should snap / translate to the new system either before,
  during, or after, the jump (whatever ends up making more sense).

The keep the skybox working properly, it might make sense to unsnap from the
local star after 0.9ly. This could even be the standard in-game definition of
unspecified territory. In that, maybe just snap to local imaginary area. If
coordinates are displayed in-game, the area name should be 'void space'.

This might also be a good time to start with writing ship modules. Creating
a nav module in tandem with writing the navigation system could, for example,
reveal non-obvious problems that should be dealt with sooner rather than later.

Once you can fly between stars properly, start with the skybox implementation and
optimisation. That way you don't see a jarring 10k stars fighting for depth
accuracy.