Hi,

I'm working on a space-based RTS with "Newtonian" physics - or at least, to the extent that ships move forever unless counter-thrusting, they can stop thrusting and coast without burning fuel, etc.

My mechanics are built around the idea of queuing up maneuvers in sequence for your ships and then broadcasting them for execution, so it's not exactly point-and-click as something like Homeworld. These maneuvers are currently executed by ships as e.g. "Burn with force F for N seconds" - they're all just a start and end time + a means of changing position over that time.

Previously, I went with a Kerbal Space Program style, where you placed maneuver nodes with little handles facing along every axis, and the player would pull on those to increase the DeltaV in the direction that the handle represented, and the DeltaV would determine the force the ship would use to perform that maneuver. This was _way_ too fiddly. Here is a video showcasing the old behaviour: https://youtu.be/PD_E1xV7wPo

Now I am looking at a more RTS-like interface. Each ship has a prediction line drawn from it, showing where it will be in the future (for up to N seconds from now). If the player clicks on the line, we create a maneuver at that location, and the player can move their cursor (from which we intersect against a ground plane to get a world pos) to determine where the ship should fly for the maneuver currently being created. Make sense so far? We also obviously change the prediction line to show where the ship would go if the current maneuver is broadcast so the player has some feedback. I have attached an awful diagram to help explain.

My issue is that I'm having trouble translating this 3D position (can be 2D for now) into a "destination" which the ship must fly through, constrained to a per-ship maximum force/acceleration, per-ship mass, etc, i.e. big ships can't take tight turns, and ships going fast also have more momentum to overcome, and where there is a maximum velocity (globally, but also maybe per-ship).

A fellow developer suggested I look into cubic splines, where I can constrain the 2nd derivative to keep acceleration below the maximum, and possibly also being able to constrain the acceptable destination point, e.g. only allowing maneuvers <= 90 degrees, AND keep the top speed below some global limit so I don't tear my physics engine in half. 
The turn limit would be similar in interface to this UI (BSG: Deadlock): https://youtu.be/sFUVqYG7Jx0?t=932.

I am a bit confused on how to determine the control points for the spline - I wouldn't want a player to have to adjust multiple points for a single curve like it's Photoshop or something. I am also struggling to find any Cubic Spline implementations which are 2D (or even better 3D).

Let me know if you think I am overthinking it - maybe there's some iterative/physics-y solution, but I wasn't sure how to solve kinematic equations for 2D/3D with a range of possible accelerations (0ms^2 - per-ship-maximum) and where I don't know the final velocity (nor care). Seems a bit more complicated than just projectile motion!

Many thanks.
 

Real time in space can be boring ... ?

Question: are you looking for the physics ? First, the force is produced by thrust, not dV. dV describes the ability of a ship to perform a change in velocity over time. It is a simple calculation, based on the ship's mass at the beginning, mass at the end of the manoeuver and exhaust velocity of propellant (Ziolkovsky, rocket equation and all that ...). You can release that dV in a short time with a high thrust (e.g. chemical), or over a long time with low thrust (e.g. electric). The resulting change in orbital trajectory is very different, though the same dV has been released.

Or is it more about the UI to actually set up a manoeuver ? I found the ksp mechanics far too fiddly and very inexact. It was barely okay for the toy planets. There was an addon to help setting up an exact manoeuver by typing in the numbers for the 6 movement vectors (trivial 2-body, ship/planet relative: prograde, retrograde, normal, antinormal, radial, antiradial). I would do that in conjunction with an orbital calculator that precomputes the values based on the current trajectory and a chosen point/time combination where my ship should go to. Like, i want to intercept that other planet/ship/'Oumuamua at a given time, show me when to burn, but pls. take into account for ship's mass change and burn time. KSP never was able to do that when i played it ... Orbiter had an addon, i think ...

Does that make sense ? Sorry if not ... but i am interested in these things as well.

8 minutes ago, Green_Baron said:

Real time in space can be boring ... ?

Question: are you looking for the physics ? First, the force is produced by thrust, not dV. dV describes the ability of a ship to perform a change in velocity over a given time. It is a simple calculation, based on the ship's mass at the beginning, mass at the end of the manoeuver and exhaust velocity of propellant (Ziolkovsky, rocket equation and all that ...). You can release that dV in a short time with a high thrust (e.g. chemical), or over a long time with low thrust (e.g. electric). The resulting change in orbital trajectory is very different, though the same dV has been released.

Or is it more about the UI to actually set up a manoeuver ? I found the ksp mechanics far too fiddly and very inexact. It was barely okay for the toy planets. There was an addon to help setting up an exact manoeuver by typing in the numbers for the 6 movement vectors (trivial 2-body, ship/planet relative: prograde, retrograde, normal, antinormal, radial, antiradial). I would do that in conjunction with an orbital calculator that precomputes the values based on the current trajectory and a chosen point/time combination where my ship should go to. Like, i want to intercept that other planet/ship/'Oumuamua at a given time, show me when to burn, but pls. take into account for ship's mass change and burn time. KSP never was able to do that when i played it ... Orbiter had an addon, i think ...

Does that make sense ? Sorry if not ... but i am interested in these things as well.

I guess it's a two-part question - how to express the maneuvers if my original idea is insufficient - while keeping them as sequential, time-stamped actions - but also how to create those maneuvers using the UI I mentioned, where there are physics-based constraints at play. I can't solve for reaching the point the player specifies (due to my poor knowledge in this area) using thrust, nor am I able to express the constraints and flight path using splines due to my poor maths

EDIT: There are no orbits or the requirement of KSP-level precision. Am looking for convenient way to lay out a series of maneuvers quickly such that a player can do it easily for a bunch of ships.

A PID controller comes to my mind ...

But maybe we can try to specify a graphical solution, and pls. somebody interrupt me if i talk nonsense.

So, initially our ship moves linearly, in a straight line with known speed and mass. The thrust its engine can produce is constant, with known force. For simplicity mass doesn't change because of fuel burn ("infinite fuel"). Let's assume that we allways burn right-angled to the course line for a change in direction.

Then the rate of change per time can easily be calculated (a simple vector addition of course- and thrust vector) and the plotted resulting courseline over a longer time under thrust would ba a circle segment, right ?

Now there is a point away from the course line that we want to cross. A line through that point that cuts our straight courseline some time ahead would be the new course line that we want to achieve in a finite time. Now, to calculate the start of the burn, we "simply" must put our circle segment ahead so that the entry lies on our course and the exit on the new courseline. For that we must have the radius of the circle and the position of the center. The latter is in the same plane as the two course lines, i let someone figure it out, shouldn't be too complicado.

Now, this must be done for every such future change. Allways leaving enough space and time between changes to actually get on the new courseline.
 

I'm not sure what kind of control over movement orders you need in a "space-based RTS" with frictionless flight and correct physics, because it depends on what the units are and how they fight. In general, don't ask the player to perform the menial functions of a flight control computer: orders should be high level, meaningful on the tactical level and not on the physical level.

• For ramming, you need to pick targets, not trajectories and target positions; detailed control can be left to dead reckoning and, in general, to AI. After a ramming attempt the ship can stop automatically.
• You can get a lot of mileage out of ordering a ship or formation to chase and shoot a target, regroup, stop at a waypoint, form a blockade, and other basic generic orders that simple and predictable AI systems can execute well.
• For a patrol route (which might not make a lot of sense in endless empty space) you can click on points to approach and automatically compute a fast and/or a,ccurate and/or low-fuel-usage path between them (or improvise without global optimization). Note that actual ship trajectories tend to be clothoid arcs or something similar, not common splines
• For cautiously approaching slow enemies and shooting each other at long range (without significant dodging, and hopefully from beyond the range of their weapons) you need to offer control of distance from the enemy (possibly including automatic retreating to remain out of enemy weapon range), target selection, and ensuring superior firepower by waiting for the late portion of the attack formation.
• The long range combat could be so slow and naval-like that completely manual control (turn x degrees, brake or accelerate longitudinally to one of a few standard speeds, spin and stop spinning) without waypoints works well.
• For high-speed strafing with short-range weapons you are likely to need the most micromanagement: fly to this point, at this time in the future, with this velocity and direction, and possibly spinning (to spray bullets around) or facing a certain target (to aim at it).  Experiment with basic UI interaction components like clicking on something to designate a target, clicking on empty space to create a waypoint, dragging after clicking to require a certain approach vector and velocity, etc.

Well, it depends a bit on what "Newtonian" and physics here means. I first thought (also because of the mentioning of KSP which basically implements newtonian physics) that it is about movement in space around a body. Since these are allways in an orbit forced by gravity (in game simplified as conic sections), there is no strafing or flying towards, these things simply don't exist under newtonian physics.

In order to meet with another one would have to align orbital planes (via manoeuvers in the ascending/descending nodes) and raise or lower apses (via manoeuvers on the opposite side) in order to fall behind or to catch up. You couldn't even fire a missile any time you like because that'll be bound to its orbit, too. For a space shooter that is of course pretty boring if not irritating, but would surely have its own appeal. A UI for this would surely be fascinating. Orbiter as well as FlightGear have both implementations of the Shuttle orbital manoeuvering systems and controls.

Seems like i was a little mislead and as usual far too much entangled in (pseudo-)realism, because if it is the classical linear movement that counts here (like in the X series of space games), then of course things are easier.

17 hours ago, Green_Baron said:

In order to meet with another one would have to align orbital planes (via manoeuvers in the ascending/descending nodes) and raise or lower apses (via manoeuvers on the opposite side) in order to fall behind or to catch up. You couldn't even fire a missile any time you like because that'll be bound to its orbit, too.

Good points, but this sort of orbital action falls well beyond the boundaries of what I'd consider a "RTS".

We are clearly assuming completely different space and time scales: potential energy, gravity and orbits are relevant at distances that are orders of magnitude larger than a reasonable battlefield, and plausible ship propulsion requires enough time to cover those distances that realtime action becomes too sparse. Unless, of course, we compress and abstract time and space, seriously departing from typical RTS patterns.

Of course I'd expect the OP to have yet another kind of game in mind...