Compromising on Orbital Mechanics

Reposting this glorious response from schuesseled192 because not enough people saw it.

I'd also like to make my own addition to it; once a satellite reaches its destination, it retains its velocity and does not decelerate. This way we have a pseudo-orbital pattern without all the mucking about with change in velocity, ellipses and n-body simulations.

Uh, deceleration would be part of what schuesseled192 suggested, although the unit would have to start deceleration half way to the assigned target, just as it accelerates for the first half. (This would have to be controlled by the game. You just assign the waypoints, not the acceleration/deceleration nodes, although the game COULD let you provide the later ones if you feel a bit masochistic.)

The goal isn't to reproduce the disadvantages of orbital mechanics (being unable to maintain a position), but the unique feeling of moving in space (the lack of brakes, so deceleration takes just as long as acceleration).

I was thinking you could give a Stop order to force the satellite to decelerate to a geosynchronous orbit, no matter its location on the planet. That part of the post was in my brain but not in the OP.

You can't give a move order to a building, so why does Uber want to give move orders to satellites?

Because satellites aren't buildings.

And they aren't Land, Sea, or Air units either.

Sounds like an excellent compromise to me. It would give orbital an orbital feel (especially the turning towards their destinations and "drifting" as they course correct, but that part could come later), and differentiate itself from the air layer. All this and all that is required from the devs is editing a text file for very high speed and low acceleration and low turn speed? Excellent.

This could even be tried in the next patch to see if it would keep the community from rioting over orbital's perceived lack of pretty much everything.

To spin that around, "You can't give a move order to a building, so why does Uber want to give move orders to land units?".

It's a meaningless statement without noting the assumptions behind it (namely, for what reason should satellites act entirely like buildings, and why are they not in the same style of unit as land, sea and air?)

You can however give a move order to a factory, not that the factory moves.

Good to see someone gets it.

The 'shell' system assumes that anything explicitly not a building works the same. We've got this fifth layer to play with, and people want to use it like three of the other layers we've already got (counting buildings as a layer in their own right).

But there's nothing intrinsically right or wrong about that. There is, however, several UI and gameplay issues with having an entirely different movement system for a subset of units in the game. For example, the inability to queue up orders when one of those orders doesn't have a defined end point (ie. orbiting).

There's gameplay issues with having a subset of units that can pass over walls and oceans. Air units aren't an insurmountable problem. Neither are Orbital units. So no, I don't believe those issues are show stoppers.

Do you consider orbitting as an actual action the satellite does, or do you consider it to be what the satellite does when its idle?

If you equate oribitting to patrolling, then yes - it doesn't have an end point. I should pose this question; is queuing orders after a patrol path an illogical mistake the user has made, or the game has made?

I like the idea posted in the OP. It sounds like an orbital system and still retains some balance aspects and keeps orbitals feeling like they are in space, but without orbits and other more gameplay detracting things, it will also make the orbital layer something that requires forethought and moves slower than the others, so you don't need to spend as much time concentrating on it.

That depends on what you are proposing. Many people are suggesting that satellites can't/shouldn't be stopped from moving, and must always exist in an orbit (that is, they have no concept of "move to a point"). This means they can never have orders queued up (an order to move to an orbit never "ends"), and can only have orders manually given one at a time.

It's more akin to Assist than patrol in the way it doesn't move past the first queued order (patrol orders will move on). In this case, it's the equivalent of the game only proving an assist command, negating the ability to shift queue orders. I call that a game design mistake.

They aren't shop stoppers, they just severely limit what is possible with very little gameplay benefit (in my opinion).

I have no problem with the idea of having satellites radically change their orbits (as unrealistic as it may be). I think, implicitly, that would allow people to consider them on specially defined patrol paths. Because of that, you could queue go shoot that other satellite into the patrol queue.

If you did that with Air, there's every possibility that said Air would fly somewhere dangerous. That's a choice you make as commander. Telling your satellites to go shoot something might be inadvertantly telling them to fly over something dangerous. The only difference is that in the Orbital situation, it may be more difficult to tell in advance that a certain decision will end badly.
​

Really, I don't agree with you when you say that you can never have orders queued.

I'll counter, you can make orbital units feel different and even more space like by making them move incredibly slowly.

For the units which are not planet hopping it is incredibly more useful for them to not constantly be drifting around. not to mention maintaining constant orbits will be confusing for most players and the high speed but poor acceleration means a very good micro player will be able to slingshot his units past you quite quickly which is kind of what the planes are doing now anyways.

Rather, if orbitals moved incredibly slowly, maybe even had little thrusters on their models to show that they aren't truly in orbit but are simply out of atmosphere where it's much easier to stay up, then it would make them feel very distinct.

Aircraft already move very very fast, making a faster unit layer would be very difficult to manage than an expensive slow layer.

Orders only progress to the next order when a unit completes it's current one. How do you "complete" an orbit command? That's the issue here. You can tell a satellite to attack (overriding the current command). You can't shift queue a satellite to attack. Just like you can't tell a unit to assist, then go attack something. If the first order doesn't complete, it won't progress.

This is a very good threat!
I hope that many people will post here to get this heard.

Never. But you can replace it with an other command.
A satellite that orbits, moves forward until you give it another order so that the satellite must change or stop his course activly - orbiting is something passiv.

What could possible commands (for a satellite) be?
- orbit = move/left click
- attack = same as all other units/right click
- hold position = stop command/"s" or click "stop" in UI

To have satellites a huge turn-radius would be good thing. As aircrafts do have this when bombers hit their target and then fly a circle to hit it again. A satellite should have a really wide turn-radius (3-4 times a bomber or even more?)

They are no buildings. And if they are buldings, just change them to units - where is the problem?

I think, you can queue orders. But maybe it is necessary for the satellite to first do another trip round the planet before it is able to reach a new orbit, or attack a traget, or stop at a certain point.
I think a visualisation of the order you want to give the satellite would be great to see directly, if you are able to give the order early enough. if not, you can give the order nevertheless, but the satellite will do it after the next pass.
I will try to show this with my awesome paintskills

1) Sat (blue) - not moving at the moment (maybe just after launch into space)
2) select Sat with mouse an move courser (red) to give an orbit command
3) immediatly the possible orbit (green) will be displayed by the UI
4) right click - sat starts moving/orbiting
5) want to change orbit - select sat (blue) and point with mouse (red)
6) immediatly the new orbit (brown) will be displayed by the UI
7) in addition to the new orbit the turnradius (pink) of the sat is beeing displayed
8) because the satellite is not able to change his orbit atm, because his turnradius is to high (or wide?) the sat must do an other trip around the planet until it reaches the point where it can start changing the orbit (thats the pink point)

In this model the player has nothing more to do to control a sat then to control a tank.
But with the difference, that the sat will act way slower and maybe not instantly after an order.
But thats the deal with the orbital stuff, isnt it? Therefore we have great advantages in addtion and to support our "lower layer"-units. That should be the purpose of the orbital stuff (as many others had said before).

I think it should be no problem to display the neccessary information to the player because all this data (way of unit, turnradius) is already avaiable and only needs to be shown visualy.

I hope that this sort of a compromis between real orbiting mechanics and something that is intuitive and similar to all other game mechanics (move orders etc) will fit well to all of us.

Have a good day everyone and that you Uber for making such a great game!


*Sorry for my english. please tell me if i should rewrite a passage for better understanding. thank you*

@raevn:

Why the hell not? Seriously, we're not talking about SupCom modding where we're limited to what we've been given. If Uber wants something to behave like that... then they can bloody well make it behave like that.

Unless that takes more work than the implemented mechanic will benefit the game.

The game could have Crysis-level graphics. They could "blood well make it" look like that. But it is not feasible. An extreme example, but hopefully illustrating the point. I am very tired of pedants on these boards, hence the exaggeration.