Meteor Showers

That would be tricky to implement but it would be cool to see this work. I think the stars should move maybe every 6 or 12 hours in a real time game. Any ship sent before the stars move has the same arrival time. With loops the times would always be changing so that would be a little tricky. The time would get shorter and shorter for collecting ships.

You also have the possibility of a loop getting destroyed when a star is destroyed. Would the carrier go back to the previous planet and the loop no longer functions or would it continue towards the old star and get destroyed by the black hole?

Also instead of stars randomly disappearing, there can be some sort of countdown to destruction when the stars start getting close to the center of the galaxy. Every player should be able to see this countdown on the star about to be destroyed.

Donā€™t over think the math. Move the stars slowly. Compute the ETA at the time of departure as if the star wasnā€™t moving. Unless someone is jumping really, really long distances, I would think this would be close enough.

Haha, people yell at me when a carrier arrives 1 hour later than the predicted ETA.

In a worse case scenario, I can just step through each tick moving the star and carrier and count how many until they collide.

Sadly, Jay is right, if you are planning an invasion from multiple stars, timing can be critical.

I think the easiest (but not very efficient) way to calculate time would be (starting at time t1):

t2 := t1 + 1
while Time_to_travel(Star1_location(t1), Star2_location(t2)) >= t2 - t1 
    t2 := t2 + 1 
end while
return t2 - t1

You gain a lot because youā€™re using discrete hour jumps. For continuous values, you can easily calculate intercept if youā€™re using linear motion, but I think you probably want elliptical motion.

Of course, if you want to model the gravitational effect of stars on each other, find an astrophysicist. Modeling multi-body motion is hard.

EDIT: Of course, the loop can stop once youā€™re out of a decent hyperspace range, which is pretty small, so the looping is not too costly.

Before any math, we have to set how the stars will move. Will they move straight at constant speed towards the center? Will they move accelerated? Will they go down through a spiral accelerating?

And since we will have moving stars, it is very important to set how the carriers will move in relation to the ā€œsourceā€ star:

  1. Will the ships move at a fixed constant speed relative to an absolute frame of reference? or
  2. Will their velocity be affected by the ā€œsourceā€ star velocity?

(1) is simpler, but may feel strange if the ship goes on the same direction of itā€™s source star movement, because it may appear to be going slower. It may even appear to be going backwards, if the star speed is greater than the carrier speed.
In (2), if the carrier cannot accelerate and the ā€œsourceā€ star is going on the opposite direction of the target star, the carrier may even have zero speed relative to an absolute frame of reference, so the player may not see it moving at all.

In any case, it may happen that the target star is unreachable, and there will be moments where is better to wait the source star to be closer to the target star before launching the carrier. It will demand something that tells this to the player.

Ouch, this discussion is sending up KISS flags everywhere i look

My idea was that the ETA for a ship is what the ETA would be at the point in time when the ship starts in a non-moving galaxy. Calculating ETA for multiple orders should be easy since the shrinking should be deterministic.

My idea is that physical distance wonā€™t affect hyperspace difference. Changing star positions will not affect carrier travel time at all.

Basically, eta might change before launch, but after a carrier is launched the eta will stay constant

An astrophysicist would tell you : ā€œBlack holes donā€™t work that way!ā€.

Rotating or free-moving stars may be interesting, but Iā€™m not sure what is the advantage of (non-sensical, but thatā€™s beside the point) falling stars.

True enough. I was just figuring who deserved to be saddled with an explanation of the n-body problem :-).

Even if a black hole didnā€™t work, the star would still burn up when it got to the center of the galaxy. The gravitational pull would pull the stars towards the middle of the galaxy. We would be speeding up the process slightly to try and make the game more exciting.

Things might not work that way in a real universe but it would be much easier in the game to calculate things based on just the departure time than to try and redo all the time calculations in the game according to the star speeds and angle of the approach to the star since every star would be different for the speeds. In order to calculate things this way it would take WAY too much work to figure out. Having stars moving in all different directions would just be crazy and the math would be impossible. The idea would be cool though to have an universe working that way. The best way would be to calculate everything based on the departure times. The movement of the stars should be slow enough that there wonā€™t be many display errors. The math should work out fine though. I think all stars should move at the same speeds towards the center of the galaxy just to make things easier with the math in the game.

The biggest errors would be a star arriving slightly early or late on the map and either hovers over the star or is an hour behind on the map. The timing would be correct for the arrival time and the carrier positions on the map would be corrected when the star lands.

With some simplifications I can work out the math. For example if we choose the stars to have two distinct movements: a circular movement around the center of the galaxy with a steady linear speed and an accelerated radial movement towards the center of the galaxy, carriers with fixed speed in an absolute frame of reference and star speeds limited to maximum the same speed of the carrier. This should do the job.

This is what I think about carrier speed and etaā€™s.

Between two moving objects, their distance changes constantly. The carrierā€™s eta is calculated using the distance at launch. This eta will not change, even if the two systems get further away or closer together. However, a carrier I sent an hour later can have a different eta.

This gives us the simplest math and the easiest understandable concept.

If the path of the stars is known and fairly simple (i.e. elliptical around a point (with varying speed based on distance) or constant acceleration towards a point), I could work out the math fairly easily [1].
Realistic star movement would require a full n-body calculation to determine the etas, which would quickly become unwieldy to calculate (especially for large galaxies).

In my opinion, the best mix between realism and ease of implementation would be a single black hole in the center with the stars in stable elliptical orbits around it. As the stars would be in known orbits, ETAs could be caulculated based upon the location of the destination at the arrival time, with fleets either flying in straight lines (easiest) or partial ellipses around the center (difficult math, but possibly most realistic, depending on your model of ā€œhyperspaceā€).

Ships should not be allowed to fly over the central black hole. With straight line paths, either the carrier is destroyed when it gets to close or such flights are simply disallowed. With curved paths, approaching the center too closely would not be possible, as the path would simply curve around it.

Either way, the ETA of a launched carrier would not change during flight, but a carrier sent at a different time may (would) have a different ETA.

[1] I have a BS in physics. Iā€™m used to this kind of math.