31 minutes ago, LorenzoGatti said:

generate flight plans automatically

Which is not as straight forward as you think!

Let me show you the following graph - it is a maneuver calculation result for Earth to Mars transfer. On the x-axis you have departure date, on the y-axis you have arrival date. The color represents total delta-v (change of velocity in prograde direction of Earth's orbit around the sun).

Calculating the transfer automatically is huge problem in reality, you need more information to supply.

Do you want lowest-energy transfer (e.g. lowest delta-v), which results in highest mass transferred from Earth to Mars?

Do you want shortest time possible (it will differ based on phasing angles of the planets)? Also for that you need to know how much delta-v is ship capable of spending for the transform.

...

A bit off topic note: In real world you always balance this - spending more delta-v means you need to carry more fuel into orbit. Spending long time on the way to the designated object is again counter-productive, as devices have certain lifetime and it may results in changing mission objective or even critical failures.

It is also common to do multiple corrections along the way - in space, you will not execute anything precisely enough (and slight imprecision of few m/s at Hohmann transfer burn, can result in being millions of km out of target body, and missing the gravity well of target body completely). Their amount is often dependent on the total distance you have to travel.

...

In a game you would most likely have to define specific delta-v capability for ship, and at any given point you would start transformation to get there as soon as possible with given delta-v (this means that you may actually wait). The math can be done, but is definitely not straight forward and simple (it requires multiple inputs).

There is always a question, can you hack it? You may try, but it won't be easy (assuming you want your motion to be convincing).

6 hours ago, Vilem Otte said:

Calculating the transfer automatically is huge problem in reality, you need more information to supply.

Do you want lowest-energy transfer (e.g. lowest delta-v), which results in highest mass transferred from Earth to Mars?

Do you want shortest time possible (it will differ based on phasing angles of the planets)? Also for that you need to know how much delta-v is ship capable of spending for the transform.

...

A very good point, there can be a slider (to interpolate between shortest time and largest payload) or some automation (produce the fastest plan with a given fuel budget that depends on the player's payload requirements, or the plan with the maximum payload for a given arrival deadline). Delta-v and fuel capacity should be fine stats to distinguish different spaceships.

Regarding computational difficulty, it's a computer's job; there are relatively few variants to consider.
Errors can be assumed to be corrected and extra fuel margins can be estimated depending on distances, ignition power and duration, etc. without adding complexity. 

On 9/21/2018 at 10:42 AM, Vilem Otte said:

If you'd start moving planets around the star you would need to introduce physics - the concepts of gravitational based motion for planetary bodies.

This is just plain incorrect. Adding full orbital mechanics to a typical "TwoDSpace" game is overkill, and definitely not necessary to make planets rotate.

---

Are you planning to make just the planets rotate, and not stars too? I assume you are working on a galactic scale here. If you were to move stars as well, that would be too much of a mess.

Assuming you have only a couple planets per star, making them rotate shouldn't be an issue, as long as they are not rotating too fast. Travel times don't need to be an issue either, if you make all planets rotate at the same speed, so they always stay at the same distances. (That is unrealistic, but so is everything else) And it will look pretty, you get to be called "the game that actually has rotating planets" The only issue left is interstellar travel. If your travelling ships always enter the system from the same side (if you have hyperspace lanes or some sort of straight-line travel), your battles may happen differently depending on where the planets are. That may be a good or a bad thing. If you have more control over your fleet movement, you can choose from which side to enter the system when you get there, depending on where the planets are. Overall you can make it have as much or as little gameplay effect as you want.

13 minutes ago, 1024 said:

This is just plain incorrect. Adding full orbital mechanics to a typical "TwoDSpace" game is overkill.

I disagree (especially in context of original author's post - which was (and in following discussion) about not just moving planets around the sun, but also moving ships between these planets), from experience basing algorithms on physics can be way less complex than making it just look like. I'll go a bit off topic now, but let me explain why.

Rotating planets around the sun is simply just rotating around the point at constant velocity (when simplified - as you said) right? Yes, so what you do is to set parent in scenegraph for each planet to be your sun, and just increment rotation around some specific axis.

Now, let's go further and add a shit around one of the planets - again, do it simple - parent is the planet center and you rotate around.

Now I'll give you a very simple task - move the ship from that planet to another one, in a believable way (e.g. NOT along the line, and it must not go through another planet or the one it is orbiting, and it must not pass around other planet that would make it look faked). At this point you're pretty much screwed - as not only that you can't parent against the planet now at all, but you can't even easily calculate the actual position between 2 planets.

This is why using physics in such scenario is important.

While it may seem more complex, it actually simplifies a ton of things. For rotating planets you don't need angular velocities at all - mass and distance from star is going to be enough (you can go more complex if you want elliptical orbits instead of circular), all are using the same logic and working properly.

Ship (given mass of the planet and mass of the ship, and orbital parameters - again if circular radius is enough), follows exactly the same logic.

Going from one planet to another now becomes clear and straightforward (it requires few additional parameters regarding required delta-v, etc.) but it will give you believable path of the ship, you will also be able to avoid potential collisions with other gravity wells.

All the complexity that would get you screwed in such transformation is solved with just a bunch of equations and defined parameters.

In short - physics actually makes your life easier in this scenario (and many, many, many others).

You completely lost me in explaining why this would be more simple than just skip physics (as all strategy games of this scales do). Anyway, as previsouly stated, moving planets are off the table (down the black hole?) for this project so diving into the details are not of much use:) It's fun to read though.

@Vilem Otte You mention things like delta-v, Hohmann transfers and transfer windows. This may be believable to Kerbal Space Program players, but to everyone else it is nonsense. The space in space 4X games is there just as a backdrop. The only reason you would even consider rotating planets around the star (rotating and not orbiting ) is the layman's expectation of "well, planets rotate, right?", with minimum gameplay effects possible.

I stand by the opinion that your sentence "If you'd start moving planets around the star you would need to introduce physics - the concepts of gravitational based motion for planetary bodies" is incorrect  

@1024 I get what you mean, exactly - and that is road straight to hell - let me point you back to the note that moving ships between the planets is necessary (as stated above in the topic), and I guarantee you that without physics you CAN'T make a believable motion of the spaceship in an easy way (the math required for the computation of the path is way too complex). With anything more simple there will always be problems of:

• Going through or too close to other planets
• Don't flying between the circles for orbiting planets
• Going through stars
• etc.

Not to mention multi-star systems - that will make even more mess when you try to move ship around.

That is why I pointed out that physics is necessary, as it makes these things easier.

You are missing the point. In this context, "believable" does not mean "physically accurate". On the contrary, to average Joes (which are the target audience here), "believable" means "anything but physically accurate". This is why every* space game out there has ships that move like they are actually in air, water or both. But you already know all this  

* almost every, but close enough, you know what I mean

So, since ships have unlimited fuel, unrealistic speeds, and they move in straight lines, all you need to do to save yourself the calculation trouble, and keep the motion "faux-believable" is to make planets move way slower than ships, and then correct the ships' trajectory when they enter the system or whenever. If you have hyperspace lanes or jumps, you can even rotate the exit point in a system together with the planets, and make everything play exactly like when it was static. Except that it moves. Which is good, because the aforementioned average Joe will say "Oh look, this game even has planets rotating, so realistic!"

Aurora4X simulates orbital movement not only for planets but for moons around planets and for asteroids around the star.  The main problem with this is that there quickly get to be thousands and then tens of thousands of objects and it slows down the game incredibly.  Fortunately, you can turn orbital motion off.  If you have a big game like this, you'll want to find some kind of trick to reduce the work of calculating all these object positions.

On 9/26/2018 at 10:23 AM, Vilem Otte said:

Which is not as straight forward as you think!

Let me show you the following graph - it is a maneuver calculation result for Earth to Mars transfer. On the x-axis you have departure date, on the y-axis you have arrival date. The color represents total delta-v (change of velocity in prograde direction of Earth's orbit around the sun).

I'm not sure this is relevant. Travel calculations for real world space travel are complicated because space travel is slow. Very slow. Your graph is based on one year travel times to Mars, for example. Planets move a long way in a year. For a typical space game, however, space travel is fast. This means that the movement of the planets between leaving and arriving is not large compared to the distances travelled by the ships and this, in turn, means that the complexity of the calculations needed is much reduced.