Detailed Real-ish yet Simple Orbit Proposal

There are many orbital ideas, it seems that every 10th post in neutrino's thread proposes a slightly different system. These proposals are insufficiently detailed with their major flaw being their UI. neutrino often opposes a more realistic orbit system by saying the UI would have to be completely different and too complicated. I see his point, I know from experience that a game mechanic has to have a very accessible UI to be useful. Most proposals neglect the UI entirely, I am going to address it thoroughly.

In some sense this thread is YourLocalMadSci's "A comprehensive Example of Orbital Combat" but with a focus on the movement mechanics in the orbital layer and the UI. I feel that YourLocalMadSci's system is far too complicated in terms of UI, nobody needs to make elliptical orbits, and their inclusion makes the UI complicated/poorly defined. Many proposals also lack information on how units move between orbits.

The system I present is based on the two level (close and geostationary) orbit system which seems to be in favor at the moment. I have fleshed out the mechanics and added a way to move between layers. I think this fixes the 'lack of staging area' problem which has been bought up against real orbits. This system is in no way meant to be realistic, it takes some inspiration from real orbits and condenses it to two simple orbit types which should mostly cover the range of what players would actually do if they had real orbits. One of the strongest parts of this proposal is that I explicitly explain how the UI works and that the UI would be very similar to the UI used for ground combat.


System Mechanics
There are two layers of orbit. Close Orbit and Geostationary Orbit.

Close Orbit
Close satellites move along the great circles of a planet and always over the same terrain. A close orbit cannot be changed once it is entered but (most) satellites are able to move into a geostationary orbit and then pick a new close orbit.

Satellites in a close orbit move rapidly. They would take 2 or so minutes to circle a size 2 planet and could be positied about 2 to 3 times higher than current aircraft. For simplicity all close orbits are circular and are at the same speed.


Geostationary Orbit
Satellites in geostationary orbit can only move on a band around the equator about 20 degrees wide on each side. I will call this the Geostationary Band. This does not need to be a hard limit. As satellites approach the forbidden area they could slow down. This is exactly like a unit in TA which is stuck in a parabolic valley, it moves progressively slower as it tries to climb the valley walls until it stops at a gradient it cannot climb.

Geostationary satellites move similarly to the currently implemented satellites; they are very slow and float in place. This orbit would be placed 2 or 3 times further out than the close orbit.

Moving Between Orbits
Many satellites would be able to move between both orbits. The maths and unit AI required to do this is fairly simple.

First note that every Close Orbit intersects the Geostationary Band in (at least) two places, they are on opposite sides of the planet. To switch from Close Orbit to Geostationary a satellite would, as it approaches the intersection between it's Close Orbit and the Geostationary Band, decelerate to halt it's sideways velocity and 'float' upwards to match altitude with Geostationary. In general, a satellite moving from a Close to Geostationary Orbit only has two choices of when to switch from one to the other and the Geostationary Band can be approximated as a circle. It is easy enough for the AI to calculate the travel time of these two options and choose the shortest one.

Moving to a Circular Orbit from a Geostationary Orbit is the reverse of the above process. Move along the Geostationary Band until you are on one of the points which the desired circular orbit intersects. Then drop to the circular orbit altitude while accelerating sideways. Also it just so happens that most of the time the player given order will choose exactly which 'launch point' from the Geostationary Band is used.


Types of Satellites
Within this system there are three movement classes of satellites; close, geostationary and both.

Close - These satellites are launched into a close orbit which can never be modified. These would be fairly cheap fire-and-forget satellites (because they lack engines). They are unable to change their orbits because they don't have any engines to speak of.

Geostationary - These are satellites which restricted to the geostationary orbit. Some may not even be able to move. This movement class would be well suited to large base-type satellites or giant death lasers.

Both - As expected, they can move between layers (these satellites have somewhat powerful engines). This grants great versatility and I would expect most satellites to be of this type. Most ground attack or intel satellites may only be able to affect the planet surface when in a Close Orbit. For them the Geostationary Orbit acts as a staging ground.

The UI
For simplicities sake I am going to say that movement related orders can only be given on the Geostationary Band.

Move and Patrol
There are three types of movement so I'll define the movement command for each type separately. It will become clear that the movement command for the restricted satellites is actually a special case of the general movement command for satellites that can move between obits.
Close - Satellites restricted to Close Orbit are unable to be told to move anywhere. The orbit of these satellite can be specified with a modified move order. To give this order the player clicks to give a move command, drags along the ground to define a vector and then releases the mouse. While the mouse it held the vector should extend to display a great circle on the planet. This exactly defines a Close Orbit and should be fairly intuitive to use. This order can be queued from a factory.

Geostationary - Satellites restricted to Geostationary Orbit have a similarly simple UI. The UI requirements for this type of satellite are effectively already implemented in the latest build.

Both - These satellites use the same drag-mouse-vector movement orders which are used to specify Close Orbits. Players will need to be able to give move orders to move around on the Geostationary Band as well as define Close Orbits. This is done as follows.

If a player right clicks on the Geostationary Band and releases without dragging then the satellite is given a move order to that point on the Geostationary Band. If the player right clicks on the Geostationary Band, drags a vector and releases then the satellite moves to that point on the Geostationary Band and then launches itself into a Close Orbit as defined by the vector.

This UI combined with the unit AI for moving between orbits (described above) create a full movement system for the orbital layer. Order queuing can happen in a very natural way. For the purposes of order queuing a satellite considers a dragged move order 'done' when it launches itself from the Geostationary Band. Now that move orders can be queued it is easy to see how to handle patrol orders. The main difference is that an attack command is inserted in front of the patrol order if an armed satellite encounters an enemy.

Just a subtlety, if multiple satellites in a clump in the Geostationary Band are given the same move order they should all have the same orbit. To make room for this they may need to nudge each other out of the way visually but the underlying orbit should remain the same.

Attack
Again, the attack order is the same for each type of movement but I'll split it up for clarity.

Close - Their movement cannot be controlled so any attack command is just preferential targeting.

Geostationary - The attack command for these satellites is basically a copy of the command for ground units. When told to attack ground units they should move to the nearest point to that unit even if the unit is impossible to target (the target could be near a pole).

Both - I envisage that these satellites would have to be in a particular orbit to attack ground units (most of the time this would be Close). If they can attack ground units from both orbits they would have to have a state toggle to define what they should do.

For any point on the planet there is always a direction that a satellite Geostationary Orbit can launch itself (into a Close Orbit) such that it passes over that point. Attack orders given to satellite currently in Geostationary Orbit but which attack from Close Orbit would simply need to cause the satellite to launch into Close Orbit such that they pass over the target. I am unsure if the satellite should continue to orbit in it's orbit once the target is dead or whether it should return to it's position in Geostationary Orbit. I don't think satellites should decide for themselves (as in without player intervention) that they should enter Close Orbit to attack but this could be a firestate.

It is also possible (easy maths) to launch a satellite from Geostationary Orbit such that it intersects with the Close Orbit of any other satellite. This could be used for inter-satellite combat within the Close Orbits. I'm not sure if such combat capabilities would be good for gameplay but it's always an option. Because all Close Orbits are at the same speed an orbit with causes two satellites to meet will always cause them to meet.

If an attack command is given to a satellite in Close Orbit and if the target is never going to enter the range of the satellite then the satellite should move into Geostationary Orbit at the next opportunity and launch itself into a better Close Orbit. This would be problematic if a satellite is trying to chase and kill another close satellite which is why I suggest that satellites in Close orbit don't interact with each other. Or if they are able to interact they should have decent smart AI to deal with this situation.


Consequences/Extensions
Here are some minor things which can be added to the system. They're here because they are not important for the core mechanics.

Energy Cost for Transition
Maybe moving between the Close and Geo all the time should be discouraged. To do this satellites could drain energy when moving between the layers. To 'prorate' this system the satellite could take longer to move between layers. In the case of a complete stall the satellite would fail to move between the layers and drop back into the old layer, perhaps the energy cost should be spent in the early stages of the transition otherwise there could be issues.

Fast (but Dangerous) Travel
Satellites should take a quite long amount of time to move around on the Geostationary Band. For long distance movement it may be faster to drop into a Close Orbit along the equator and then go return to Geostationary. This would be dangerous and may cost energy so it would be a bad thing to do all the time. There is a tradeoff here but it would be a nice to have a movement state to toggle this behaviour.

Relative Safety of the Levels
The different levels may be vulnerable to different types of ground based defences. Geostationary satellites could be too far away for most weapons to reach while the Close satellites may move too fast for some weapons to hit.

Unit Diversity
Most of the unit types and roles suggested so far for the orbital layer can fit into this system. I think the inclusion of the interacting Close and Geo layers will create good unit diversity. There have been plenty of unit suggestions so I won't add any here.

'Too Much' Depth?
In retrospect there may be too much in the mechanics of this orbital proposal. The mechanics themselves are not complicated but I think you could create a whole RTS just within the orbital layer. It may overshadow ground but I think this is mostly dependent on the orbital unit composition. In the end I think we need depth in the orbital layer. PA is the first game with an orbital layer so it would be best to not under do it. Also the orbital layer is likely to be your first point of contact with an opponent's planet so it would do well to be interesting.

(I accidentally wrote 2,000 words, time for sleep)

Just a note on the transition between the two orbit types. I know that the physics at the transition is completely fudged. It is done this way because the transition between two states in a discrete system is the part most prone to abuse. The transitions between layers are kept local and short to justify removing control from the player during the middle of the transition. If the unit was always able to be controlled a player could spam orders such that a unit floats mid-transition in an illegal location.

For example if it took multiple orbits for a Close Orbit unit to reach Geostationary the unit would be further away from the planet while over the poles than it is allowed to be otherwise. A player could spam transition orders back and forth to abuse this. The alternative is removing control from the player for an extended time.

Also it could be good to let units move between Close Orbits without passing through Geostationary. I think the the transition will be messy and hard to define, too hard for it to be worthwhile. But I'm all ears.

What I'm about to say is very subjective, but to me, this kind of system adds more complexity than a system which just goes ahead and implements the actual orbits, and less actual depth. See, I come from a fairly scientific background. This means that if something is based purely on the physics, i find it less complex. I can extrapolate the behavior necessary from the system if it's based on physical rules. The rules of actual orbital mechanics, even if they were clamped and limited, are fairly straight forwards, hence the depth from them is emergent based upon these simple rules.

With systems like the one proposed i don't have that guideline to go with. Aspects of it become patched and special-cased such that it tends to require a lot of learning of the rules before being able to make sensible guesses about what's going on. The best example i can give is in countering units. If the question of which-unit-counters-which is determined by the confluence of projectile-physics vs unit movement parameters, I can pick that up very quickly. But if it's hitscans and armour-types, I have a lot more to memorise if I want to play proficiently. Particularly when some games can have ten or more different armour-types.

WHen it comes to orbital movement, there have been a lot of systems proposed which aim to make orbital mechanics less deep by adding in complexity with special cases and arbitrary rules. This doesn't make me happy. However I acknowledge that this is likely an implication of how my head works.

I have to endorse this method, it seems to take the most advantage of the orbital layer. My concern has always been how they would make it feel unique, just like air land and sea, while all similar, all have their own feel. My only recommendation would be to include a quick five-ten minute tutorial level on this in the final release. Otherwise I truly believe that this method, or one close to it, will make the greatest use of the orbital Layer, without, as many people say, turning it into Air 2.0.

YourLocalMadSci, I see where you are coming from with that reasoning. When analysing a system it is nice for the system to have few underlying rules. Systems which are patched together are somehow 'ugly'. But (at least for most people?) there is a big difference between sitting down to analyse a system and trying to interact with a system in real time in a competitive environment. A system could be rich and deep but it's useless if the UI is too unwieldy to use it to do anything particularly exciting.

It does not have to take a long time to learn a system with many rules. A well designed system will be very intuitive and have few actions which can be used to complete many tasks. Also a system with a small elegant rule set is not automatically intuitive as it could take a long for players to learn/discover the subtle ways in which the rules interact to create complex behaviour which can be used while playing the game.

Anyway, it is down to personal preference. In this instance I prefer a predictable system and I think there is a much higher chance that Uber will implement something like this than a full physics system. I partially wrote up this system because your system was the only other detailed proposal for a system. It was the prime example of a 'real' orbit system so it's flaws were taken to be flaws of any type of orbit simulation.

I like this as a compromise between the current system and the full orbital system. The only change I would suggest (and this mainly the space nerd in me, so feel free to ignore it) is instead of floating up you use transfer orbits (see GTO in RL) . They can take same amount of time you propose and happen at the same intersection points, but if you start on side A, you end up on side B. I think it would look much cooler, but you may need to drop it depending on how intuitive it ends up being

This seems awesome and simple 100% back this being implemented

Transfer could easily look like GTO. I may have been unclear in defining the transfer because what I am thinking of already looks a bit like GTO. I am thinking in polar coordinates. The satellites simultaneously float upwards and decelerate with respect to tangential velocity. This will form an arc. Satellites don't stop and then float upwards.

Sorry then, I just misunderstood

I love the fact that you are posting this but I have to agree that this is too complex. Multiple orbital layers?

Perhaps the issue here is that I see PA as fundamentally being a fairly simple game. There is simply no way I would ever do something as complicated as what you've described here. I also think it fails the smell test of being at the same level of complexity as the other layers.

BTW I'm curious how blunt people want me to be? There are an awful lot of things people come up with that fall into this category and I usually keep my mouth shut. I'm wondering if by not wanting to spread negativity I'm not giving enough insight into my thought process which people think means I'm not listening.

Perhaps a solution would to merely have one functional layer and merely have pathing steer the orbital units above and below others as needed to prevent collisions?

Why would collisions ever be a concern? Why not just handle it like the air layer?

it depends on whether they want the units to be visibly going though one another, like air, or if they want them to not share the same space like land and naval units.

I think it's less about being blunt and more about being honest and at least saying 'no' and if appropriate explain why as well. It might not be entirely pleasant for the person who crafted the theory it's helpful for everyone else and gives us more context to work with when crafting or refining our own ideas. "Oh Neutrino doesn't like X, my idea has X but I think I can tweak the idea so that X isn't present or not an issue" type of thing.

Mike

Depth vs complexity is somewhat difficult to understand. I'm just going to leave this here...



Simply put, the goal is to make it elegant. More elements to the UI, or things to learn, etc. make it more complex, but don't necessarily add depth. Elegance is making a simple system that allows many choices and gameplay variations (for instance, japanese Go pretty much has two rules and people spend lifetimes trying to master it).

It's always fun to see complexity in games (cough Dwarf Fortress) but the trick is crafting elegant solutions with simple systems. The implementation of orbital as detailed here is at least 4 times as long as the devs' explanation of the entire economic system, and I don't think it offers nearly as much depth to gameplay as the free economy does.

You've very elegantly summed up my thinking.

For example I highly object to adding custom interfaces to the game for the different layers. We have an order system, I don't want to create an entire new order system for orbital units. They need to work within the same context as everything else and with a similar level of elegance and overall complexity. I cannot emphasize that point enough because I think many people ignore it and want to clutter up the UI. UI is evil.

Totally agree that more feedback could be good for people to understand my thought process. However, I'm not very good at breaking things to people nicely and I'm worried things would get combative quickly. Everyone has their own pet ideas about how things should work....

It's true that most people could find your negative straightforward replies as rude and inappropriate but thats cause most people never dealt with direct honesty.

I fully agree that the UI needs to function on the same principle on all layers. The game needs to be simple, we as players choose how complex we want to make it. This is why I love TA, it has exactly that.
I don't know if you already said something about this but I would like to know is there a specific gaming audience you aim for, like strategy gamers, or you would like to try and bring non-strategy gamers to the game, or it doesn't even enter your thought process?

If its bad, say so