Yet another Orbital implementation idea

Hi,

I started writing this the other night to expand on an orbital idea I posted previously, but am now a bit hesitant to show it as it seems everybody has their own views of orbital and I'd just be adding to the bunch rather than agreeing with the limited choices already offered. That being said I thought I should at least finish it in the hope that it offers some spark of inspiration for Uber or other people to expand upon. I admit it takes a lot of the ideas already proposed, but I put my own spin on things.


Orbital Paths

As suggested many times, orbital units will exist on a shell around the planet. This shell will are an arbitrary radius based on planet size that will represent the geo-synchronous region. Orbital units can get launched up to this shell from any point of the planet, but instead of just hovering there (as with the current implementation) they will perform circular orbits.

Let me be clear on something here, just because I say circular orbits doesn't necessarily mean the unit will move across the surface of the parent body. This idea is relying on the planet underneath actually rotating such that satellites can assume an orbit with the same angular velocity and therefore "appear" to hover. That being said, the latitude of a unit has an important effect on any movement that could occur. Let me explain.

If you launch at a high latitude then having a satellite just hover there doesn't make sense, but you kind of want it to. The way I propose to deal with this is to have the satellite create a geo-synchronous orbit (not geo-stationary!), whereby it creates an inclined orbit with the same orbital period as a geo-stationary satellite. This will result in the satellite being fixed to the same vertical line on the planet, with some slight deviation, but its latitude will "wobble" up and down by whatever amount it was originally offset by, thus producing the figure-8 pattern people have mentioned.

Like this:


This means that when a satellite first launches it assumes an orbit that best minimises this wobble. Also, if you tell a satellite to stop or it finishes a move order then it's default behaviour will be to assume a geo-sync orbit with it current point being either the peak or trough (more on this later), not just carry on as others have suggested.


Unit Behaviour

Before I go into the following section I should clarify that I am imagining orbits to be the by-product of movements around a rotating sphere, not entities in their own right. So when I say things like "change the orbital inclination", I just mean it applies thrust to change its the direction of it's velocity vector, whilst keeping the same speed. If you were to show a visualisation of the orbit then an inclination change is what you'd see.

Orbital units will have your basic move, stop, attack, and patrol orders.

Movements will be requested the same as any other unit, by selecting a point on the planets surface to go to. To achieve this the satellite will change the inclination of it's orbit (at its current point) to directly fly over the target location. Whilst doing this it will also proceed to accelerate up to its defined top speed. The difference here from other ideas is that once the unit reaches the location it will perform it's stop routine, rather than carry on that orbit.

The stop routine is where the unit takes its current latitude and creates a circular geo-synchronous orbit about that point, the same as if it was launched from that location, and over the course of an orbit will wobble with the figure-8. A stop can be automatically performed after other commands or forced by the user. This is the closest you can get to having a satellite actually remain at a point because it is in fact always moving, so it's velocity will never be zero. Note, by continually pressing stop over the course of an orbit the satellite will gradually reduce its inclination and eventually produce a geo-stationary orbit (a pure stop), or the player could just command the satellite to move to the equator and it will perform the stop routine once there anyway.

Attacking would work the same. You select the target and the satellite adjusts its orbit to move within range, or fly over if performing a bombing run, and then behave like other sorts of craft, either change its orbit to perform another pass, or perform the stop routine.

The main thing here is that the underlying move order logic doesn't change, or need any special UI to achieve. The only change is the movement orbital units are capable of, the same way that aircraft move differently to land vehicles.

Patrolling is the only new bit that may need consideration. Two options could exist for their:

1. It could be kept exactly the same as other units implementations (in that you place down several waypoints) and have the satellite fly over them at it's top speed and change it's orbit to fly over the next. Again this would require no special logic as it's all part of the movement routine.
2. The UI has the option to allow you to place down an orbit as others have said. Instead of doing the whole click and drag thing I imagine it would be much easier if you just selected a point on the ground and have it create an orbit that intersects that and the satellites current position. The satellite then proceeds to it's top speed and follows the orbit around. If you select a new patrol point the same process applies. You wouldn't be able to queue up patrol points, but really in this case you may not want to. Instead you could place down multiple move orders and a final patrol and the satellite will enter that patrol path at the end.

With both of these approaches the patrol points could be repositioned (like Supcom) if that was a wanted feature.

One thing I briefly mentioned in this was the "accelerate to top speed". This sounds straightforward enough, but to give it a better sense of realism it could be made such that the altitude of a satellite is a function of it's velocity relative to geo-stationary. By this I mean all satellites that are moving relative to geo-stationary, and therefore any ones that are moving "faster" should be lower. I know this isn't completely correct, as if you go against the planets spin then you're actually slowing down but this seems like an unnecessary complexity. So whenever you tell a satellite to move it will accelerate and lower it's altitude (which can be arbitrarily defined per planet). Having a low acceleration would be quite interesting as it mean normal movements won't change altitude much, but an orbital patrol will eventually get up to quite a fast speed after its first orbit. This will give that Low Earth Orbit effect others have suggested, without the need to create a second layer.


Unit Coordination

I am really eager to see on-orbit construction enter the game. This concept lends itself well to that. If you have a lot of orbital fabbers all over the place then you can select them and instruct them to build something. You can place this "structure" anywhere and it will automatically be positioned on a geo-synchronous orbit based on what latitude you select (using the same mechanic as launching satellites and the stop routine). The fabbers will then move near to the position following the already described move routine. Once arrived they will assume geo-sync orbits and proceed to build. To avoid potential drift of the craft, it could be made such that the orbits they choose match that of the construction with a positional offset, thus allowing them to all move together as a complete entity. Maybe there are simpler ways of doing this though, such as having them each re-evaluate their relative position and move accordingly. This would also apply to any other situations where groups of units need to congregate.


User Interface

Two things are required for this idea (but are probably needed for all others anyway):

1. A working orbital shell, allowing players to issue orders on that rather than the surface. This should feature a way to relate orbital positions to surface positions, such as a line from one layer to the next, allowing players to exactly place their satellites over their equatorial bases if desired.
2. An optional orbital path visualisation, showing the orbit a unit is on based on its current velocity vector. This would only need to be shown when units are actually selected.

All controls work in exactly the same way as existing units, with the exception of patrol which may not allow queuing depending on the method chosen. If the latter method is chosen, then perhaps a further orbital path could be shown to say "this is the orbit you will be on". This would disappear once the main orbital path aligns with it.

Conclusion

In summary, what I am proposing here is that:

• Satellites follow purely circular orbits.
• They exist on a shell and travel at geo-synchronous speeds to try and maintain their place above the planet (with some figure-8 wobble).
• Players control them using the same commands as any other units.
• Move commands consist of the units changing their inclination and accelerate to fly over the target
• The stop command (either manually pressed or called automatically after a move) changes the satellites orbit back into a geo-synchronous (not geo-stationary!) orbit.
• Patrols are issued using a single click, using the satellites current position as the second reference point.
• (Optional) Faster moving satellites lower their altitude to give visual separation between them and stationary craft.
• (Optional) UI only requires the orbital shell to be implemented, and a way of showing the current orbital path of a unit.

Thanks for spending the time to read this if you did. I know I haven't discussed the types of units etc, but I felt this needed to be specifically about the core mechanic.

Please have a serious think about some of the suggestions I've made here today. I imagine there are a few situations I haven't accounted for in this design, so please raise them and perhaps together we can find solutions.

Kind Regards

(Now time for sleep)

this sounds like it could maybe work with queing up orders (right?), I like.

That was one of the things I wanted to address with this idea, yes. I admit my thoughts on patrol aren't as solid as the rest in that regard, hence suggesting two ideas.

This all sounds pretty doable on top of the basic system I'm implementing. Kinda like mine but not allowing stopping.

I really like this, i prefer an absence of stopping.

I like this, but I would make the figure-8 wobble a little less realistic....so it doesn't need to wobble across the equator and back. I don't think distance from the equator should be such a big gameplay consideration. Others may disagree.

I on the other hand, would prefer if they could stop.

I have a programming background so like to design systems that I personally have the ability to implement

Essentially, yes. I think the main thing here is that by having the planet rotating underneath and the new "stop" behaviour being to travel geo-sync with it's surface, you end up with a system that is different from other craft but that controls virtually the same without having units percieved to just hover. That being said if you really wanted to a satellite could be made to hover around a point by giving it move orders, but then it's continually changing its orbit to make that happen so is "realistic" .

Having the figure-8 wobble IMO would be interesting for gameplay, as it makes the equatorial line a more important territory (as thats where zero wobble occurs, giving you a complete "stop"). Bear in mind that these orbits will match the rotation of the planet, so could take 2 to 5 minutes to complete.

The wobble here is the byproduct of giving satellites circular orbits to follow that intersect through the planets centre (as real orbits do). If this was to be reduced or removed then this idea becomes no different from the original orbital shell neutrino proposed, and that people felt was "unrealistic".

Just think of this as a caveat of orbital unit motion, in the same way the motion of aircraft causes them to circle around targets rather than just hover there (ignoring the few exceptions).

I like this idea although I worry that the UI would be prone to abuse which results in a degenerate system. Basically I like this idea because it is not the current implementation and seems to have a good UI. I would need more information on how satellites move between orbits to be able to judge the UI.

I like that the equator behaves differently to the poles. With no other terrain in the orbital layer I think a system which I would like needs this feature.

I am worried that the UI could be abused such that we're left with a degenerate system. By this I mean that players could use the UI in an unexpected way to workaround many of the mechanics in the system, they would make the mechanics inconsequential.

This is my worry for the system. As far as I can tell you are proposing that satellites use very powerful engines to move between orbits in an "unrealistic" way. What is to stop players from hovering satellites over any location by spamming move orders in an area around the location?

I understand what you are saying. In the system I'm proposing satellites are always in motion around the orbital shell, but their "idle" speed matches the rotation rate of the planet underneath. When it comes to changing orbits the player selects a point on the planet the same as they would for any other unit. In the case of an aircraft that is already in flight it will arc around until it is travelling towards the target. Satellites would do the same thing, rotate their velocity vector such that the orbit will pass over the target. This would be controlled by their "turn rate", with satellites having different values based on role and how manouverable they are meant to be. I don't see how this is unrealistic in any way, as you'd get the same effect if you applied a perpendicular force to a craft in KSP, i.e changes the direction of it's pro-grade vector.

As for your other concern about people creating hovering satellites, well there's nothing to stop the player from forcing the orbital unit to change its orbit all the time, and I'd argue nothing should. They are actively instructing it to do something and as a result you'll see the orbital path continually change. That being said, you'd never actually get a pure hover. This is because the satellite is using it's move order so wants to "fly over" the target location at its top speed. Once it does that it has to turn around in order to line up with the next target. The best you'll ever be able to get then to do is a looping pattern around a given area, with the loop size being dependent on top speed and turn rate. So if the player wants a satellite to do this then the system should allow it, but be visually clear that the satellites are actually doing work to pull it off.

I hope that clarifies matters.

Edit: I should say aswell, you could concievably introduce a command to have a satellite to hover at a point with this system, whereby it matches the velocity of the ground and applies a turn rate to keep it there. This would produce that latitude band others have suggested, but rather than being an arbitrary 40 degrees, the lattitude possible would be dependent on the turn rate of the satellite in question. However, I do not like this as it introduces a special command for orbital units and goes against the concept of this proposal of using only the existing control framework.

The fact that there is nothing stopping players from microing a satellite such that it circles around a small area (relative to the planet size) breaks the entire system. Circling around an area on a planet is tactically superior to roaming all over the planet. By default people want their units to stay put and they'll do so if it is at all possible. This post in Compromising on Orbital Mechanics is relevant.

You're forgetting though that the default "stop" behaviour of these satellites would be to create a geo-sync orbit. They wouldn't just carry on all the way around the planet. The fact that you're giving it repeated move orders goes against its wish to stop moving relative to the planet, and if the satellite has low turn rates then you'll end up with it travelling over a larger portion of the planet than you potentially want it to.

That being said, I understand your points in the other thread and this is where the dilema comes in. The system I propose requires no new UI elements to achieve interesting unit motion. However what you say could be true of any other vehicle when it comes to motion, in that microing it could lead to paths that the player wants but can't do normally. I made an edit to my last post just before your reply that may offer an option:

This seems like it would achieve that behaviour the player wants, but without introducing an arbitary limit on what latitude is allowed. If you choose too high then a satellite will try its best to hover there but fail and end up with the wobble. Maybe this could be automatically included into the stop routine instead of the original idea i proposed of the figure-8 wobble?

Well if this is possible, you've got my vote. Sounds like a great way to do it.

Thanks. I'm going to have a think about this for a while and see how I can refine the concept further. One thing I'll have to explore is whether the turn rates you'd actually want for gameplay would result in hovers being achievable at stupidly high latitudes. I don't mind there potentially being one or two recon satellites that could do this, but they all can then you're getting back towards neutrinos original shell idea, and this is meant to offer something different from that...

I understand why the wobble happens on real satellites. I think having satellites slowly wobble a bit makes them feel more realistic, because you can tell it's in motion...but it doesn't have to be quite so realistic. I'd rather turn it into a mostly aesthetic feature with fewer gameplay consequences, which is what I want.

Maybe you could give all the orbital units a little particle effect to indicate that they're shooting along at a hundred miles a second, even if they're actually standing still.