Compromising on Orbital Mechanics

What looks more costly to implement; 1) Crysis, or 2) Schulti's interface proposal. It's very much like what I'd like to see. The only change being that I wouldn't use the satellite's current position as one of the markers.

sure, you could define orders in an orbit setting. In this case it would be the shifting between two orbits, which can be started and completed. The actual problems probably start when defining the unit "states" between two orders. Air and land units are in one position with no speed and direction vector (other than its orientation on the ground), an orbiting unit would be in a moving state.
My guess would be, that this is the point where the existing internal unit and state model can't be applied to such orbits and you would have to design something new. Depending on how the existing system is designed and integrated into the simulation parts that can get messy, but that's just my guess.

I dont think so. Imagine a bomber which flys straight forward. if you give him a movecommand that is left or right from his perspective it will fly a curve (depending on its turnradius) and not fly an edge.
Of course spyplanes do this ... it seems so, but actually this looks so because they turn that fast.
So just give the sats a wide/huge turnradius and dont let them be too fast and it will look like smooth as is should.

No idea. I have no idea how well the rendering pipeline would support the techniques required to reach such graphical fidelity.

Equally, I have no idea how much work with regards to the game engine would be required to create a radically-different interface.

To me, it doesn't seem that radical. If you limit things to a fixed altitude, and non-elliptical paths, then all you need is a bit of maths to float the satellite about, and to know where on the surface of the sphere you've clicked. As far as I'm aware, PA has been doing that since the first launch of the Alpha.

Floating the satellite about is the part I don't know. Even then, I'm not asking for perfect Newtonian mechanics.

sure you can make transitions between two orders smooth, that wasn't my point.

my issue is, that depending on how the simulation is designed internally, an usual unit, which is not part of any order (move, attack, attacked, influence of some 3rd party effect), doesn't need to be updated in every simulation step since it stays where its last location in an unchanged state. An orbiting satellite would be on the move even if all orders for it have been completed and it's position has to be updated constantly.
(I'm aware, that I make some assumptions about the inner-workings and I don't mind being corrected if I'm totally wrong. )

I get your point. I dont know it either. Would love to see some feedback from Uber to this point.

My best estimate (I do graphics work) is about $1m in cost difference, assuming the engine already supports everything (extremely doubtful).

UI is comparatively both extremely cheap and easy to implement.

Oh, I wasn't talking in monetary cost, though I presume you can reduce man-hours to how much each position is worth (3D artist, animator, texturer, etc compared to engine programmer, UI programmer, UI artist, etc).

You aren't understanding me. You can't enforce a "satellites must keep moving" rule, as well as being able to chain commands. Chaining commands requires that every command ends. Orbiting doesn't end, unless you treat it as a "move to this point, then travel in a straight line". Except that's just normal movement, with an added side of annoying, as you would be forced to perform micro to emulate geostationary behaviour, because it is far superior strategically and tactically than letting it move itself. I've read schulti's idea, but there are issues with it:

• Giving an attack command to a satellite behind yours could never be fulfilled. Actually, giving an attack command to almost any other satellite on it's own orbit results in pretty unpredictable behaviour, as you'll never know where the turns would take place. This gets worse the more satellites are involved.
  
• The "wait till next rotation" can easily be worked around to allow the satellite to turn on a trajectory without waiting for the next trip, thereby forcing massive amounts of micro (simply by doing turns immediately in front of you until you've turned > 90 degrees). If you don't enforce this, then you now have many, equally valid paths a satellite can take to a given move order - how do you chose which one?.
  
• Getting your satellites to group up together would be a nightmare.

But the biggest issue is that the whole time the system is actively working against the best thing a player can do. Because in most situations, exact control over a satellite is ideal. This is still possible, but now hidden under piles and piles of micro. No doubt the mods to do this for you would come thick and fast, which begs the question of why have it in the first place?

Uber themselves came to the same conclusion:

I'm sorry Raeven, but I'm not sure you have a grasp on how orbital mechanics would actually play. Every example you have given is not even close to how an orbital system would play out. I understand this confusion, as it's difficult to imagine if you don't have the example in front of you, or haven't been dealing with these kind of interactions on a daily basis for a long time. Suffice it to say that although imagining it in your head might be difficult, manipulating orbits in an actual game is not. People on the KSP forums have given examples of their 8-year old daughter managing to manipulate orbital paths without issue and without guidance, and that's just from experience gained in playing around with the tools, not some sort of mathematical child-prodigy. Furthermore, the systems that most people are proposing would be far easier to manipulate, and far simpler in execution than those in KSP.

To address the examples you give.

• Chaining commands works perfectly fine. The difference is that you are thinking in terms of moving to a point instead of moving to an orbit. Each orbit, and family of orbits represents a distinct point on the specific orbital energy/inclination landscape. Once a satellite has achieve one orbit in a chained path, it then goes on to achieve a different orbit. This allows units to patrol between different orbits or orbital families with ease. Likewise for assisting friendly units and attacking enemies, either on the ground or in orbit, both of which would start with a rendezvous with the target.
• Attacking an enemy with a negative phasing angle with respect to the original craft is easy. The low energy path would be for the attacking satellite to temporarily boost to a higher orbit, causing it to slow down and allow the other unit to catch up with it, whereupon it could engage. This is a trivial operation and would be no different to giving a normal attack order, and would be just as predictable in it's outcome as with any other unit.
• Choosing an interception path isn't particularly important, as long as the system is consistent. For example i suggest the immediate low energy path, but bi-ecliptics are also fine, providing the same trajectory type is used every time. I understand that you may have trouble visualising this, but that's what the game would do for you. The player need have no more input than clicking on the target they want to intercept. The trajectory taken would be every bit as predictable as land-side unit pathfinding.
• Getting your satellites to group together is easy, from a player perspective at least. Band box select a load of units, and give an assist command to a single unit. They would all rendezvous and flock together. The maths behind this isn't easy, but the outcomes that the player would see are pretty predictable.

These problems have already been solved in the real world, and the lessons there can apply here with interesting outcomes. All of these behaviours are emergent from the simple physical rules which govern orbital mechanics, yet generate a lot of interesting things for players to work with. I would urge you strongly to find a simulator and play about with orbital mechanics a bit, before making these statements.

That argument is actually quite heavy.

It's the same, as we will have mods to make our bots dance automatically without manual micro, unless the bots learn to do that as their stock behavior. Or simplified controls for aircraft, so we don't ever have to bother with avionics (which is already in place and default in every RTS game).

In the end, all left by the "controls" would be weird (and not really predictable) intercept times, resulting from the internal chaining of several maneuvers in the boundaries of orbital mechanics which only exist for the sake of ... orbital mechanics?

I think having to think about where your stuff goes and continues to go is just a little more entertaining than having to think about where your stuff goes and parks itself. I think that is the point of orbital mechanics.

I don't want orbits because they're realistic, or because they look pretty when flashy lights whizz past.

No, I want orbits because they're different,

because they're new,

because they require tactics that can't be found elsewhere.


The 'shell' approach really shouldn't be called the Orbital Layer. It should be called the Gunship Layer. Currently, that's exactly how satellites behave.

because our brain can tell the difference. It's what made us so addicted to simulated projectiles.

To say that orbits are working against what a player wants to do and therefore bad is as odd a statement to make as conventional movement is working against what a player wants to do because the ideal solution would be to have units which can just teleport everywhere.

The whole point of orbital mechanics is that the limitations it places on unit movement introduces interesting and varied strategy. In the same way that a base in the middle of a rocky gorge means players will have to act differently to one built on a flat plain, or by a large ocean, so are there differences between an equatorial and a polar base. It adds situational strategy that the player must take into account just as every other form of landscape does. Furthermore, the concept that satellites can still move as in a fixed shell model, just with lots of micro is just factually incorrect for any T/W ratio < 1 which would really be a no-brainer in terms of implementation I'm sorry, but all this does is highlight a misunderstanding of how orbital mechanics works.

As far as i can see, we have three factions here. Those who don't understand orbital mechanics and don't want them, those who do, and thus think they offer something interesting to the game (whatever that may be), and those who also understand orbital mechanics, but fear for those who don't.

Personally I think it's hard to tell what the orbital layer is going to add to gameplay. I do not know of any games that allow for a similar interactions. What I do know is that orbital should be:

• Not too similar to aircraft movement
• Providing you with a new type of gameplay and interaction
• Immersive and fun to use.

I think the immersion is achieved by making it feel like it obeys some of the natural rules. That doesn't mean that it actually does obey natural rules, it just has to look and play like it does. This means that as long as it's called "Orbital" we should atleast have large portion(but not all units) in the orbital layer that follow this behaviour to some extent, and those that do not follow this behaviour should have the appropriate lore and appearance to indicate that it's something that futuristic technology made possible.

That's why I think it's good to think about what the orbital layer should actually provide to gameplay. I think when we clearly define the role orbital layer is going to provide, we can also determine the amount of realism needed to achieve such gameplay.

I agree with mushroomars that having poor acceleration and high top speed would go a long way to compensating for true orbital mechanics being too complex. I have one suggestion though - have a command which automatically plots a patrol path around the planet, so if you want the unit position to change constantly as though it were orbiting, you have a quick easy way of doing it. I'm happy for it to stay as simple as that, but if people wanted a little more control, you could just add a factor that allowed you to control the direction of "orbit"

Just to pick up on this, I made a suggestion in neutrinos thread that I think could work well: https://forums.uberent.com/threads/orbital-units-2-directions.51008/page-8#post-780246.

The essence of it was that satellites would follow orbits as you say, but have their stopping behaviour be to establish a geo-synchronous orbit with an inclination up to their current point. This would be their 'idle', meaning they will remain at the same longitude, but perform the figure-8 wobble if at high latitudes. This has the added effect of if a satellite is commanded to move to the equator, it will automatically establish a geo-stationary orbit when it arrives. Similarly groups of satellites could easly be commanded to move to the same point as they would all adjust their orbital paths to get there and become geo-sync once they arrive.

You could still perform patrols or queue up move orders exactly as you describe, but the default behaviour of a satellite would be to establish an orbit that minimises it's overall movement path over the surface. If you really wanted to i'm sure a satellite could be made to hover over a pole by continually adjusting its orbit on a patrol path, but at least it would be believable, especially if turn rates were low.

Thanks

I really don't see the problem here.

If we're going to have an orbital layer, then it should behave like an orbital layer. This means that all objects in this layer are orbiting. Now if you want an orbital object to 'stay still' then it needs to be in geostationary orbit- i.e. rotating at the same rate as the planet. This works in real life, can't see it being a problem here. The alternative is to have a non geostationary orbit (i.e. its orbiting faster than the rotation of the planet). I don's see this as a problem either.

If you want to queue up commands- treat the orbit itself as the start and end points. The way I see this working is you order a 'move' command to a satellite- you get a blue line around the planet indicating the current orbit, and you drag this to a new line (green perhaps) indicating the destination orbit. The satellite engages its thrusters and shunts itself over until it reaches the new line- command ends. This is a queable system as it doesn't deal with the fact the satellite is travelling in a constant loop- it just deals with the loops themselves.

I would imagine Geostationary orbits would be in a different (higher?) layer, and should be limited to intelligence equipment or transport way points, or possibly defences aimed away from the planet to ward off invaders. To have geostationary planet facing weapons could really unbalance things. The lower orbit stuff could have weapons- the orbit mechanics would mean it would only be in range of a particular point for a finite amount of time- where it can both attack and be attacked form said point on the surface. I think this would avoid a scenario of everyone simply teching up to orbital stuff.

That's my thoughts on the issue anyhow...

One word: Poles.
There is no such orbit which would be able to provide practical coverage of the poles. And, except for the metal planets, the poles are a perfectly valid location for bases, unlike our world where the poles are rather boring due the fact that they are covered with ice.