Orbital units - 2 directions

Imo this here is where there's a significant misunderstanding between neutrino and some of the pople who root for orbits.

The reason I'm for "realistic" orbits is because the lead to emerging gameplay in a similar way that simulating projectiles do. The fact that areas near the equator or areas near the poles would have different values in regard to orbital gameplay is an incredible advantage to me while neutrino (seems) to think that this could be an issue with the design. (As has been mentioned, stay at the poles savely while giving up orbits yourself or risk enemy orbits near the equator while also having your own orbits there, tradeoffs. )

Its not that I want realism for realism's sake but that I believe that orbital units bound to certain paths leads to interesting gameplay and reinforces its role as a support layer.

Personally I'm very concerned that a design of high top speeds with low accelerations leads to a very micro focused layer. In general I'm concerned that shell-like orbital layer will distract from ground game play. Its only really useable on a high zoom level and direct control with it AND the ground level will be almost impossible.

I don't want to move units around in orbit similar to ground units while also having to control on the ground. My attention is allready stretched to its limit dealing with a very large base and my half a dozen tank forces rumbling around the planet, having to zoom out all the way to deal also with orbital units sounds very painful to me.

My idea for orbital units would have it to be a very hands off approach where micro is almost impossible, but that seems to be something neutrino doesn't like.

Coupling a shell-layer with units which can't stop (but without giving the advantage of an orbit-ui) or are slow in acceleration sounds to be that we get a very labourious layer where I have to constantly monitor and upgrade the move orders of those units. To me this sounds like even more work then setting up fixed orbital paths for units at their construction.

(Here's a post on how I envisioned orbital units, not really important or interesting since the decision seems to be a done deal. )

Oh well, we will see eventually.

(Edit: Adding links to a post with the new forum software is as painful as pulling a teeth. I had to add them multiple times until they showed up in the post itself. XD )

Hmmmm, **** it, can you just scrap orbital for now, get interplanetary travel and asteroid smashing done, then come back and do orbital when it has more context. What is orbital actually going to add to the game?

Genius post.

I am also happy the discussion happend and you should really have props for reading as much as you did!
But i feel like people have just brushed over that more polish and immertion work(Better art, smooth transitions,No banking sats) on the current system will make it more awesome, but people only saw big gameplay changes as a fix for the current meh looking system...

We've had many detailed posts about orbital, now I am curious as to what the results are.

Is there anything that the community suggested that will potentially see it's way into the game?
Has the community managed to improve or change how Uber Entertainment envisions the orbital layer, if yes, in what way?
Are orbital units going to be like those in the alpha, or will we see something else entirely?

end note: In Maver we (I) trust

There is a summary post by @neutrino a few pages back that pretty much lists his thoughts and there are a couple of things there that suggest a some of the simpler and more logical community suggestions will be looked at.

I hardly think that will be the extent of the changes required. For starters any plans for orbital defenses would have be scrapped.

In FA when i load air transports I select the units I want to transport and right click on the transport (while it has that little underscored up-arrow icon). If the game mechanic isn't broke don't fix it right?

To be fair he also works for you. It's in his best interest to not make more work for himself and to agree with you, especially on topics you are passionate about (just sayin lol).

These kind of comments are really disappointing... It makes me wonder if that's what happened to the megabot too? That sets a sad precedent where you run away from tough decisions and I'm hoping that's not true. Remember, deciding to not make a decision is still a decision (and probably the worst 1 you can make). If you find yourself typing stuff like that do everyone (including yourself) a favor and step back to take a break....

With more development resources (i.g. a larger budget and larger team), it would probably be more feasible for Uber to experiment with additional ways of making orbital mechanics more distinguished and "new" as you stated.

The current direction sounds like it will integrate very well with the UI system (which is still being developed) and the overall design of the game while minimizing the amount of required development resources.

And as has been pointed out by Neutrino, orbital mechanics will be distinguished from land, sea, and air mechanics even if it is not to the extent that you hope for.

Additionally, Uber may at some point (perhaps via patch, DLC, or expansion) iterate further on orbital mechanics in order to make them more distinguished. What has been discussed thus far is mostly the initial implementation for the official release version of PA:

And even if Uber does not iterate on orbital mechanics further following the official release of PA (which I personally doubt), PA is being designed with high modding support. In fact it wouldn't surprise me at all to see mods that change orbital mechanics during beta prior to PA's official release (assuming of course that such modding support is available during beta).

The beauty of how Uber is developing PA (crowdfunding, no publisher, iterative development process, etc.) means that it will be relatively easier for them and the modding community to evolve PA over time. I think that a lot of members in the community become hyper focused on the design/implementation details for the official release version of PA and forget that many of these things are not set in stone. Sometimes we need to reset our perspective in order to see the bigger picture. The following quote snippets from Neutrino illustrate this part of his vision for PA very well:

and:

big up to the above. I've repeated this platform thing in countless of my posts.

Guys, I listened to what Neutrino said about thinking the ideas through and how it needs to fit into the current movement protocols and interface. I have literally spent all day drawing diagrams.

Please read my post, respectfully submitted:

https://forums.uberent.com/threads/...s-intuitive-queuing-of-movement-orders.51056/

Well movement types aren't my battle, So I'll be skipping that in favour of cooler basic and advanced units:

TB - Tier Basic

• Spy satellite: fast, hard to hit but has a very poor sight radius, directly below it meaning that multiple passes are required to scan a large base, possibly in a flock, although that would make a AOE missile quick to take them down.
• Leech: Reclaimer satellite, designed to slowly drain the HP of enemy buildings and possibly slow ships due to its sort range and slow acceleration or something. Enemy can repair faster then you reclaim, but that's just more money they are feeding directly to you.
• Skyfall: Raider satellite, designed to make small meteors and throw them inaccurately at enemy forces, not much damage but good at littering an area, requires metal to fire, good at softening tank columns.
• Guardian: Space superiority satellite, designed to attack enemy satellites with a small laser system, not the best but in small groups can clear our enemy Skyfalls and Leechs quite quickly, but is very vulnerable to ground based missiles.
• Replicator: Satellite fabber, designed to build other satellites and gas giant power plants for cheaper then a launcher, but at triple to construction time and energy cost.
• Hoover: Power plant satellite, built around gas giants, produces power extremely well.

TA - Tier Advanced

• Matrix: Slow spy satellite, uses radar to detect surface targets, is also a players best choice for detecting enemy satellites at long range.
• Protector: Space superiority satellite, designed to use anti-satellite missiles to deal with enemy satellites very quickly, but has a slow firing rate.
• Multiplier: Advanced satellite fabber.
• Dominator: Power plant satellite, like the Hoover but instead of drawing more power this satellite has an in build energy cannon that uses a portion of a players energy to fire powerful energy beams that easily take down enemy satellites and are a good way of dominating a gas giants space.
• Infiltrator: Space based unit constructor that fabricates T1 land units to then be immediately shot down at the planet, designed to allow players to sneak forces on to a new planetary surface for construction of new bases and factory's, but at a very slow rate.
• Scorcher: Satellite AA, designed to fire a rapid fire cannon at enemy aircraft, much like the skyfall requiring metal to fire and inaccurate, designed to weaken an opponents air force.
• Bombarder: Satellite based nuclear construction facility, designed to produce low yeald nukes to be targeted at unsuspecting enemy bases, much like a nuclear sub, has a long construction time.

Admittedly not the best list in the world I think I covered a lot, raiders, engineers, scouts, combat units, powerplants and the like.

This is my first time on the forums but thought this might be important...
I have my own idea's (close to the devs idea) for orbitals but I won't be offering it....
and this is why;

I think a lot of anger has been directed at the devs or rather people have been passionate about one position or another. The devs can't please everyone and personally I like the direction they are taking things.

There have been great ideas and not so great ideas. That's not the issue. There has been a mildly (and maybe at times not so mild) demanding tone, which may not have even been intentional at times, which seems directed in an angry way at the devs (speaking as someone who has given money to this as well). I'm sure it would serve everyone best just to give our ideas politely and in a friendly way, that way the devs are more likely to pick it up if its a good idea, and well if its not its not.

There will be Mods and the game may be expanded in the future.

As some of you may know programming can be stressful as a job and can leave you with many sleep deprived nights (I'm not saying just from the programming itself). It was very nice of them to open up this thread but I would please invite the devs to close it now that most ideas have been exhausted and for their own peace to work on making an awesome game.

I haven't played any proper game in years and this was the first one that really tempted me back.

Respect to the developers and to everyone who has given good suggestions.

my only remaining question is "will there be space elevators"

I think there should be a couple of (invisible) orbit rings around the planet. When a satellite is launched you chose an orbit lets say for example the most middle one. The satellite orbits the planet in a slow manner. If you would want for the north pole become mapped you have to launch another satellite in the orbit near the North pole. This way it really functions as an orbital unit without being really disturbing. The amount of rings should be depended of the planet size a bigger planet has more orbit rings than a small planet. This is also strategic more interesting because if you know your opponent has one satellite in the upper ring you make sure you build/expand your base in a blind spot for example where ring 2 is in the drawing in case not satellite is in that orbit. Launch another satellite in the same orbit and the satellites view in that same orbit spreads evenly (automatically). This way you can map 2 sides of the planet at the same time.

even though I'm can feel the heat of KSP fans' unforgiving stares I honestly find the above to be a great idea.
It is of course unrealistic to the utmost but it certainly finds that sweet spot between an orbit by definition means constant movement around the body --and-- air 2.0

Honestly in a thread like this one, the only stupid idea is one that isn't posted. Like Mavor himself has said, in the end he makes the final call, but IME if you can stand to sort through a large pile, more information is good. Not less.

It's like someone asking what you want to eat, and you saying "I know what I want, but I don't wanna tell you".

As for demanding tones, this is the internet. Everything "sounds" the way you want it to for the most part, unless someone practically writes an essay on what tone you should read their post in. Sure it can be hard to read stuff neutrally (neutrino pun?), but if the devs can pull it off I'm sure a re-read of this thread would be even more of a gold mine.

/rant

EDIT: I've put my 2 cents worth in and feel better for it

While what I was talking about was not the most complete, and frankly anyone who knows me will tell you I suck at explaining my ideas, I'd like to point out that what I was suggesting was done from the perspective that it would utilize the current in-game UI. In the end we're best off using the same UI for all layers, from both a cost and Coherency view point. It definitely flattens the learning curve just a bit.

Reposting from earlier in the thread - I think it's possible to achieve a good deal of interesting orbital mechanics with just two commands: "intercept target" (moves current unit to target unit's position) and "move to position" (adjusts orbit to pass over spot on the ground).

This would work by giving orbital units an orbital speed, which would be constant for the planet, with a direction that can slowly be changed, plus an "adjustment speed" that lets it move faster or slower along its orbit path. Units with faster adjustment speeds could also change the direction of their orbit faster.

Intercept Target would work by turning the unit's orbital path to intersect that of the target, then turning it back until the two orbits match - meanwhile, the adjustment speed would be making the unit go faster or slow - whichever would lead to it intercepting the target sooner.

Move to Position would just adjust the orbit direction to pass over the specified ground area - meanwhile, the adjustment speed would be going forward at maximum along the orbit path.

Since this seems like a simple, readily implementable way to add dynamic orbital mechanics, I'm hoping someone notices this. Unless there's some drawback that I missed...