Orbital units - 2 directions

Aren't these both problems you will already have to solve for moving celestial bodies like KEWs and metal planets which is already planned functionality? Players still need to move their asteroids etc. Will that not be intuitive? Especially if they are already doing it in game for those objects?

I don't get why you mention the 2d plane though, that's irreverent. When placing additional moons in the map editor players supposedly wont have a problem, why would players giving move orders in game have any more difficulties?

Having a dozen different ways to do one kind of thing (like movement commands) isn't intuitive.

No? Currently the orbital sim is locked to a 2d plane for ease of manipulation. There are different kinds of KEWs, the kind you build in orbit that is a unit and an actual asteroid. They are pretty different.

In addition your design completely removes a bunch of the stuff I want to do with orbital. Do you realize the timescales you are talking about? The complexity of getting things to sync up for an attack? Your system would basically make orbital useful for only a small number of things IMHO. I want the orbital mechanics tuned to make sense for smashing asteroids which is why it's seperate from "regular" orbital units which live on a different time scale.

One thing to note is that this stuff isn't mutually exclusive though. There may be units that act like you're describing (for example when travelling between plants unit may use a holman transfer orbit and act like a celestial body).

Whats different? I select a tank, left click to move him. I select a factory, left click to set a waypoint. I select engines on a KEW, left click to move them into orbit over specified point on other object.

Basically what I'm getting from this thread in general is that people want orbital units to be it's own complete game that isn't integrated into the way the rest of the units work. People are coming up with elaborate designs that forget that this is a small piece of a puzzle. That is not going to happen, sorry. There simply isn't resources to do that and I think the goal is dubious at best and overcomplicates the game. That's my opinion and nothing I've seen here has made me think that I've missed something with the current design. Yes it's fake. It's a videogame, everything is massively fake.

Units are units and need to be treated as such and work within the UI system like any other unit. Anything that deviates from that better have a huge reason for existing. For example the planet smashing UI and orbital system for planets is a pretty huge part of the game.

We have a set of common commands for all units and that is language that we need to use to describe what orbital units do, how they get orders etc.

Honestly I just feel like there is a huge communication barrier here.

Fair enough.

Make sure you ask your Lore-Writer to come up with a DAMN good excuse for antigrav, Mkay?


...

By the way...

Progenitor Lore?

Don't want to be a pain, but did you look at my suggestion? Its fine if you say its ****, but I would be nice to hear something.

Ok, my last apptempt, I've seen bits of this here and there I think, but I put it together.

Under the constraints of not introducing a new order how does one control an orbit? For a single of shell orbits we need 2 sets of information(assuming it's a proper orbit and orbits the center of mass of the planet) to define an orbit, either a position and a direction, or two positions. Every click introduces a new defines a new 'target' orbit between the clicked location and either the current position or the last chained command. If satellites could turn instantly this is fine, but looks silly, if we set a turn rate the satellites the satellites will turn like planes that have overshot to get to their new orbits, is small enough I think it would end up looking like a transition orbit, but have not verified this. This keeps the behavior of the current move command (i.e. go to THIS point), you just keep drifting past it, and have limited options to get there

If an attack command requires an orbit change, the target location would be used as the move point for the needed new orbit. If attacking an orbiting object in space, you need to match orbits, see below.

Assist and guard commands, this requires matching orbit and positions potentially, the matching orbits is easy, that is just two moves one now, and one where the unit will be/was at any nearby point in time. Matching position in an orbit is the hard part, you give the units some small throttle control so as they slow down/speed up along an orbit (no over/under phasing orbits).

Units that move across orbital and air/lower. Well first we need to know a bit more about the unit, transport/fabber. The transport is simple I think, when you tell it to load a unit or a unit request to load on it, it does a move to shift orbit to align with said unit and then drops down on it. If it can get itself back to orbit, next order given takes it back to orbit, if it needs a big rocket from the orbital factory on the ground, there are 2 options, fly it around like an air unit until you get it to the factory and it takes off, like a normal launch, or the move command you give it defines an orbit between the factory and the order and you auto move to the factory (I like the first better)

Fabbers, well the simple solution is that they can't go down to ground and build anything there, but that is lame. We could make them like transports where they default to orbit (moving between ground side projects is ground->orbit->ground, but would last less than a full orbit, think suborbital flight) and they know if they need to go down or up based on what they're building. We could also try a submersible surface type command, but that adds needless orders I feel, an orbital unit should default to it's base layer when moving (like planes that can land).

When built an orbital unit would default if it had no orders, to an orbit where the factory is the peak of the orbit in the North/South direction, the orbit direction I would default to the planet rotation direction if that exist. A rally point would set the orbit between the factory and the the rally point.

That was way longer than I expected. Yes, this is mostly orbits but occasionally not. If there are other units that move between layers I'd be glad to try and add them in.

Which orbit? Is there no control of that at all? If not how do you control the units? Actual orbits are complex beasts and you want to use the same system as the asteroids, which do have that added complexity.

Honestly I don't see any advantages over the system I've proposed if you aren't going to have the extra orbital control, why not just make it fake?

I'm not responding to everyone's idea. I simply don't have time to do that.

I've already rejected adding yet more complexity (you are suggesting MULTIPLE different orbital systems).

This is basically my system with the added provision that units aren't allowed to stop. Something that we will probably mess around with although I'm dubious that it will lead to better gameplay.

I honestly really don't get the obession people seem to have with "realism". There isn't a single thing "real" in TA, SupCom or PA. Not a single thing.

after initially suggesting the "geosync only at equator" idea, I'm coming around to Neutrino's preferred idea of just treating Orbital as one 2d shell and using the way that the Sat's move to give them that "space-y" feel

most of my reasons for suggesting the limited range of geosync is aesthetic. For purposes of good gameplay, simplicity wins (just having multiple planets to fight across makes for really complex gameplay anyway)

I'll just sit back and wait to see what Uber comes up with for cool new units and UI to make this all fun

What are the advantages over doing it the way I want? E.g. you launch stuff onto a sphere and it sits there and moves where you tell it to. How is that any worse for gameplay?

Basically now I've brought you through the thought process I had. I started out making it complicated but after discussing it with Scathis we came up with the current system. Simplicity wins every time. Of course this thread has been approximately 100x more work than that conversation with Scathis was.

There's nothing (yet) new or different about that. Irrespective of being better/worse, you can't claim that it's original when it's not much more than very high flying gunships.

So, there are a few things to try out;

• Completely unrestricted movement across the orbital shell (much like it is now)

or

• Semi-restricted movement that focuses Orbital units around the +40° and -40°, while allowing them to "pass through" higher latitudes, but not stay there permanently.

And then something we all mostly agree on;

• Low Acceleration, high top speed. The larger the unit, the slower the acceleration (but the higher the top speed?)

Pretty sure Neutrino and the devs have spent way more time pondering the ins & outs of orbital than we have, so I am inclined to let it be made as they see fit and enjoy the result.

Who said it's original? When have I ever said at any point that this game was going to be filled with originality as a design goal? It's not a design goal. I wanted to make a mass scale RTS with planets smashing together and lots of **** blowing up.

I'm not trying to build orbital units to be some kind of second coming. It's simply another set of units to blow **** up with. They are toys to play with, as is the game itself.

Originality is generally overrated.

Just wanted to say that this wasn't my intent at least, I also notice that my thought summary on Orbital got burried under a flood of posts 5 pages ago, I think it's something that more in line with what you want, but I'm not sure.

Mike

I feel it makes orbital essentially air, unless there is a dramatic way of differentiating.