In conjunction with the ALTITUDE CONSOLE suggestion thread, I had an idea to expand it even further by introducing not just orbital altitude to ship mechanics, but also orbital position. Think of it like this: you know how objects in space, like rockets, constantly move around a parent body (like a planet)? They can’t stand still – at least, not without burning a lot of fuel – and as a result have to circle around the planet due to orbital mechanics.
So I was thinking we could apply something like it to the Almayer (and other ships that might be added in the future) – let’s just call it the “ship” from now on. Instead of hovering in one position above the “AO” (area of operations, i.e. the ground map), it circles around the planet in an orbit. This means that at any given time the ship can be either close to, or far from, the AO. For example, it can be on the opposite side of the planet as the AO. Where the ship’s stationed could change several (Marine-only) gameplay elements relating to transit times, recon data, etc.
“Close orbit” refers to an orbit where the ship is above, or at least has line of sight to, the AO. If the ship is in a close orbit, the following happens:
- Dropship travel times are reduced, the effect increasing the closer the ship is to the AO. This also applies to hijacked dropships.
- Orbital bombardments and supply drops take shorter to arrive.
- Bioscans are more frequent.
- Tactical map is more accurate to positioning and updates faster.
“Far orbit” is for when the ship is too distant from the AO that it can no longer maintain a direct line of sight to it without having to pass through the planet. When the ship is in a distant orbit, or on the “far side”, the following happens:
- Dropship travel times take longer since the dropship has to circle around the planet to get to the AO. This shouldn’t be too big of a penalty, though, since sometimes it is unavoidable.
- Remember, this also applies to hijacked dropships.
- OBs and supply drops can take longer, or even get rendered inoperable, depending on the ship’s position.
- Tactical map updates are slower, or may even be disabled if far enough.
For one, there should probably be some unique upsides to a far orbit too, like being able to conduct orbital surveys of the far side of the planet to gain research/tech points, for example, or having some kind of “heat” mechanic that dissipates when you’re on the far side. I don’t know, though, that’s why this is a forum thread and not just outright a PR or design doc. I want your feedback!!
So, you’re probably thinking: being in a far orbit sucks! What’s the point of an update like this if the ship’s just gonna have half its stuff nerfed for half the round?
Well, you see, that’s where astronavigation, a subsidiary department of Command, comes in. Astronav’s job is to manipulate the ship’s orbit by firing the engines to maintain an optimal orbit.
Astronav is made up of navigation officers (O-1s) and answers to the Chief Navigation Officer (O-2), who in turn answers to the CO/XO. Details on this command structure can be tweaked down the line. I don’t even know if the CNO is even necessary.
Astronavigation has a few primary options:
- Burn a moderate amount of fuel to keep the Almayer in an optimal orbit that maximizes time over the AO and minimizes time on the far side. This constantly manipulates the orbit of the ship, and as a result, constantly burns fuel.
- Modify the ship’s orbit type to change its characteristics. More on this below.
- Burn a lot (I mean a lot, this is the laws of physics you’re fighting against here) of fuel to make the ship hover directly above the AO.
- Burn no fuel at all and have the ship coast to the far side.
There would be a few types of orbits that the ship can position itself in. These would be:
Very low circular orbit: The “low orbit” in the altitude thread, this is basically the ship being inside the planet’s atmosphere. Best for emergency runs, because this is insanely risky.
- Extremely fast travel times
- Possibly railguns are enabled (according to what Morrow suggests, at least)
- Most unstable: ship will break apart if staying here an extended time and requires maintenance
- Ship is experiencing atmospheric drag and will crash into the planet if fuel is not constantly burned
Low circular orbit: The standard orbit that provides a lot of benefits to staying on the near side while a lot of downsides to being on the far side.
- Faster supply/OB/dropship travel times
- All the negatives of being in a far side orbit when the ship reaches that point
High circular orbit: Once again tying into the altitude mechanic in a separate thread (we should probably merge these two at some point).
- Shorter OB cooldowns
- Faster bioscans
- Slower supply/OB/dropship travel times
Geostationary: Extremely high orbit that keeps the ship permanently in view of the AO by matching its orbital speed with the planet’s own rotation. Useful for keeping a constant information stream, like satellites do, but not much else.
- Constant tacmap, communications, and bioscan connection to the planet
- Really fast OB cooldown time
- Travel times take as long as if the ship was on the far side of the planet
- Takes a long time and a lot of fuel to get into (and out of) a geostationary orbit
Maneuvers that manipulate the ship’s orbit cost fuel, a finite (but renewable) resource. Fuel is slowly regenerated (how I don’t know, I’m not a scientist) over time, but is expended faster than it is renewed. Fuel management, therefore, has to play a critical role in keeping the ship steady and stable. You can’t burn all the fuel at once, because then the engines run out and you’re left coasting in an orbit that’s screwed up in some way, so you have to ration.
- Fuel is loaded into the engines by MTs (engineering) controlling fuel pumps. They don’t have to haul fuel cans individually but do have to monitor fuel consumption and production.
- Astronavigation (command) has to communicate with MTs to determine how much fuel is needed and how much can be spared.
- Fuel tanks act as buffers, able to store excess fuel and discharge it when the engines are burning.
- Fuel tanks could (maybe) be ruptured with significant damage (i.e. a bomb), destroying them, spilling fuel all over the place and making that tank inoperable until repaired.
- More mechanics on this that I’ll have to consult the General Public™ for.
This is a really extra mechanic and probably should not be added in the first “phase” of implementing this entire project, but hear me out.
Recon satellites are satellites that can be launched into the Almayer to keep a constant ear on operations in the AO. They relay comms, bioscan data, and tactical map data to and from the ship. They can be placed in orbits of their own, too, with varying buffs and debuffs based on the kind of orbit they are positioned in. A geostationary satellite, for example, will have a higher frequency of tacmap and bioscan updates, but will have lower accuracy – not to mention it will use a lot of fuel to get there to begin with.
The Almayer starts with one satellite in high orbit above the planet. While this is sufficient for gathering data, there are still gaps in coverage that happen when the planet passes between the ship and the satellite. As a result, to keep a better data connection, more satellites should be launched.
Recon satellites can be constructed by MTs in a workshop by assembling and printing various parts together, like you’re assembling a machine. Once it’s done it should be loaded into a satellite launching bay and ejected out of the Almayer, where it will maneuver itself into a stable orbit. Launched satellites require fuel of their own to operate, the amount depending on the orbit chosen. Astronavigation has the ultimate authority on deciding what kind of orbits these satellites require, but it is up to MTs to load, fuel, and launch them.
Due to their expendable nature (they are never recovered when operations are completed), recon satellites are built cheaply. This means they have a weak computer that is unable to perform orbital corrections by itself, and they are fragile, making them prone to destruction when facing space debris.
Over time, satellites may drift. MTs will have to calibrate satellites occasionally in order to keep them at the optimal orbit and prevent them from going too far off-course. This doesn’t require much math here – MTs will simply put the orbit desired and ARES will handle the calculations.
Randomly (the chance increasing the longer a round goes on), a satellite may be destroyed or otherwise rendered inoperable by space debris. This requires constructing another satellite to fill the spot of the old one.
What a long project to detail! I have no idea if a lot of this is even possible code-wise, but it’s definitely a mechanic I think would be really cool to add to the game. It adds a lot more activity for shipside to do as well as provide Command with more options on how they want to control the round flow and the ship.
Either way, I hope this interests you too! Feedback and ideas are really appreciated!