October 29th 2015
Since the initial release of Arena Commander, we’ve increased top speed, scaled down the availability of boost, and reduced the power of maneuvering thrusters. While these have all had drastic effects on the game, none have been a fundamental change in the way the game actually works – which goes to show how much stat balance can affect a system! However, behind the scenes, we have been working on some deeper changes to the flight model, and are nearing a point where some of that work can be put in front of players.
The flashiest new feature is the additional flight modes: Precision, Space Combat Maneuvers (SCM), and Cruise. These are all IFCS profiles that focus ship behaviors toward the highly different goals of close tolerance adjustments, combat actions, and long distance flight respectively. Though you can only use one flight mode at a time, coupled/decoupled and the collection of flight assists can still be used to further customize handling.
When you take off you’ll start out in Precision Mode. In Precision Mode, the maximum velocity is significantly reduced and the throttle and acceleration are rescaled to provide improved control when maneuvering in close proximity to other objects. This makes take off and landing much easier, but will also improve control around other objects such as asteroids, derelict craft or when approaching other live craft during In-Flight Refueling or Boarding maneuvers.
Once you’ve cleared any nearby objects and have come up to speed you’ll want to switch into Space Combat Maneuvering mode. SCM is one of the biggest changes to the flight control system, but on the surface it closely mimics the current flight mechanics that you may already be used to in Arena Commander. The real power of SCM mode is that maximum velocity is a now dynamically calculated as a function of force and mass: F/m * T = SCM Max Velocity – this means anything that any changes to the acceleration of the ship (such as loadout changes, picking up cargo etc) will impact the maximum SCM speed. We’ve incorporated the SCM calculation in such a way that it is your ability to brake to 0 on any turning axis (x or z) that determines the top speed your ship is allowed to fly. This means that upgrading the ships maneuvering thrusters generally results in a higher max velocity being allowed by IFCS. Further, this speed is determined by the strongest turning axis of the ship, meaning the best drift control will be achieved by turning on the strong axis, rather than the weak axis. Each ship has a different configuration of strong and weak axes and its up to the pilot to learn them and fly to their strengths.
There is another exciting benefit to SCM: Afterburner. Where the current boost mechanic gives you better acceleration and drift control, Afterburner gives you more maximum velocity while maintaining the same relative control. Here’s how it works: In SCM mode the top speed is set according to your ability to accelerate to a given velocity in a set time. Since boost raises your acceleration your maximum speed also increases. Boost as it currently works is still sticking around, but now players will have the choice on how to spend their limited boost fuel: on max velocity to rapidly change distance, or better braking to improve handling.
For longer distance travel in the same local area Pilots now have the ability to utilize Cruise Mode. If the speed limit defined in SCM gives the pilot control at the expense of velocity, Cruise Mode gives the pilot velocity at the expense of control. And while the top speed is high, the available acceleration doesn’t change, meaning that reaching maximum Cruise velocity will take 15-20+ seconds, turning ability does not scale with velocity and coming to a stop can take much longer using the normal ship retro thrusters.
Since cruise velocities can easily reach 5x or more of the safely controllable velocities allowed by SCM, IFCS enforces controlled turning to ensure pilots do not get into uncontrollable slides. This means that the nose of the ship is locked to the velocity vector and maneuvers in Cruise mode become more about adjusting course than making turns. It goes without saying that Cruise is absolutely not intended to be used in combat, asteroid fields or high-traffic space lanes.
Of course, decoupled mode can always be used to rotate freely at cruise velocity. Savvy pilots will quickly learn to use decoupled mode and boost to brake with their mains as quickly as possible. Conversely, pilots will find that attempting to change course 90 degrees by using decoupled mode is an express ticket to sleepsville since the high sustained g-forces of such a maneuver lead to rapid black or red-out.
Beyond those flight modes will be Quantum Travel, the one place where all ships are limited to the same 0.2c max speed. Once the Quantum Drive is active, the ship will quickly ratchet up the velocity to the 0.2c limit – short jumps might never get going that fast – with the ship itself experiencing relatively little acceleration. At these speeds, tiny variations in angle will result in massively different flight paths, so this is where slower ships will have the chance to escape a faster ship accosting them. Of course, traveling at these incredible speeds is quite dangerous, so the ship computer will automatically pull you out of Quantum Travel if the possibility of collision is detected or the ship has any downed shields.
One of the design goals that goes back to the dawn of the project is the concept that the flight control software should be physically represented as an item within the game world. But up until now the IFCS system has been completely behind the scenes and managed through (relatively) static ship definition XML files. Much work has been done over the last few months to prep the IFCS parameter blocks for migration into an avionics module that can be swapped out and upgraded. Each module is used with a specific ship and contains all of the settings and parameters that IFCS needs to know about the craft to make it fly within the established engineering spec. Behind the scenes this makes it vastly easier for designers to tune and balance ships and thruster upgrades and gives us more flexibility in giving unique characteristics to hull variant ships. But the most exciting part is that soon players will be able to upgrade their flight control software right along with their thruster hardware to build a ship that suits their style.
The biggest change to IFCS is the move to a 3rd order motion control system. Prior to this release, IFCS has used a feedback control system for spaceship motion control. The motion profile for this feedback control system (a PI controller) is an exponentially damped sinusoid. The graph in Fig. 1 shows both acceleration and velocity control as the velocity set-point changes from 0 to 100 m/s.
This is an iterative control system that makes no assumptions about the past or future state of a system, and merely acts to smooth out the error between the ship’s current state and its goal state. Because of this, it is well suited to our needs, where damage conditions and unexpected external forces can cause unpredictable motion.
To further complicate matters, because IFCS is limited by the actual thrust available from ship thrusters, the true in-game motion profile is capped. This profile is shown in Fig. 2, with the uncapped profile shown behind it for reference.
The graph in Fig. 2 is a fairly accurate depiction of the current velocity control for spaceships in Star Citizen, both for linear and rotational control. While there are many advantages to this motion profile, there are some significant downsides, including a) difficulty predicting the future state of a ship that is moving under this controller and b) an asymmetrical control response with an extended settling time. In particular, players have frequently noted that the extended settling time makes the ships in Star Citizen feel “sloppy”.
To address these issues, the new release of IFCS will begin using a bi-level control system. The first level, feed-forward control, will calculate the ideal motion of the ship, while the second level, feedback control, will provide error correction to keep the ship as close to the ideal motion as possible, even under damage conditions and unexpected external forces. So the current motion algorithm will still be part of the system, providing the same error tolerance, but it will no longer be the dominant motion profile (except under extreme system error).
The feed-forward control system will use ideal 3rd order motion, as the graph in Fig. 3 shows.
Unlike the feedback algorithm, this motion profile is completely predictable. At any moment, it is known how long it will take a ship to reach a new velocity or position from any set of initial conditions. Also, the acceleration ramp-up phase can be tuned so that ships have a natural, smooth motion, without the excessive settling behavior of the current control system.
In practice, this will result in a wide range of ship flight behaviors from highly responsive and jerky, like a high performance sports car, to less responsive but smooth control, like a luxury car.
The rate of change of acceleration is called “jerk,” and it is essentially the acceleration of your acceleration. An easy way to understand jerk is to think about how you drive a car. When decelerating your car to a stop if you apply constant and even pressure to the brake pedal your car will decelerate at a linear rate. But if you apply this same pressure to the pedal all the way to a stop the transition to 0 velocity is not smooth and feels abrupt. But if you progressively apply less pressure to the brake as you approach 0 velocity (or ‘feather’ the brake) you change the rate of the deceleration and the stop is much smoother and more comfortable. Feathering the brake is a low-jerk action, while suddenly depressing it is a high jerk action.
For reference, the graph in Fig. 4 shows the typical 2nd order motion (constant acceleration, linear velocity) used in many games.
While 2nd order motion is a much simpler control model, it provides a very stiff, mechanical ship movement. The 3rd order system will allow us to tune ships to be as stiff or as smooth as we need.
Ship flight balancing is one of the most difficult and delicate tasks that we have on this project. The move to a 3rd order system and the addition of a dynamically determined velocity mode have necessitated a nearly complete from-the-ground-up re-balance of the ship handling characteristics. This means that each of the ships are likely going to feel quite different from what you’re used to in Arena Commander. Great care has been taken to ensure that each ship retains its own place relative to the other ships in the universe. We’re aware that any change of this magnitude will likely kick off lively and passionate debate about the old vs the new, but we’re confident that the changes will allow us to make the ships feel more real, and allow them to have more unique personality than has been previously possible and allow more precise control.
The switch to jerk also means that erratic actions for evasive maneuvers are nerfed naturally, since the system is now slightly slower to make contrary actions – dedicated inputs, like the kind used when attempting to pull out of a slide, are largely unaffected. Third order motion is also much more natural for the human brain to internalize, so control will be more intuitive, and overshoot will be less frequent.
With jerk available as a parameter, a new ‘stabilized flight’ behavior becomes available. Essentially. this means that by setting a low jerk value, an engine can be tuned to perform at a greater Load Rating relative to its size, allowing us to create ships – like the Hull or Aurora – capable of hauling plenty of cargo without also becoming the fastest ships in the universe when unladen. And, while all ships will be faster without cargo than they are fully loaded, we can set different ships to have different levels of performance loss when they take on cargo.
The first pass we release to the PTU is simply that: a first pass. It is intended to set the general tone of the direction for each ship, not the final destination. As always we will continue to playtest and tune, and will be watching your feedback to see where we may need to address rough edges or unintended consequences.
There are a few more neat little consequences of this change, but for now, let’s talk about thrust shunting.
Thrust shunting is the process by which thrust is generated in the main engine and then pushed through the pipe system to the various nozzles (or ‘mavs’ as the community has dubbed them) where that force will actually be used. This means that the main engines will become far more important than we’ve seen so far in Arena Commander, and down the line, will mean we can have full engine rooms on our capital ships. Instead of having engines plastered all over the ship we now just have actuated nozzles, so if the main engine gets damaged then all the maneuvering thrusters go with it. When this happens, ships have internal gyros that can be used for emergency or ultra-low power maneuvers, but they are very weak and slow. The fantastic thing is how this opens up new opportunities for damaging ship flight behaviors.
A damaged thruster pipe would scale down the available thrust at the nozzle, and could even introduce unintended thrust at the point of damage.
The nozzles themselves have ratings for heat and power, limiting the total thrust available – a limit you may be able to exceed, though you do so at your own risk. The result is an equilibrium of flight behaviors that are enforced by the design of the ship and the state of the components, behaviors that a skilled pilot will be able to push to the absolute limit to ride the line between victory and catastrophe.
There are many ways that the actual state of a ship can deviate from the ideal state as requested by IFCS. Up to this point we’ve allowed the control system to have perfect control under ideal conditions, and this results in overly mechanical and often “dead” looking motion. With the new release, that will no longer be the case. There will always be some level of thruster and system error overlaid on flight control. This will manifest as minor turbulence in motion under optimal operational conditions, but will become more extreme because of thruster damage, overheating and various other factors.
The graph in Fig. 5 shows a sample ideal 3rd order velocity profile. IFCS would request thrust from the thruster system to achieve this motion.
However, because of thruster error, which can include a number of sources such as incorrect vector or thrust level, unstable vector or thrust level, etc., the actual motion of the ship can deviate from the ideal motion. The following graph shows an extreme example of random thruster error causing the velocity of the ship to deviate from the ideal velocity over the transition from 0 to 100 m/s. Because of errors in actual applied accelerations (all actions for a ship are ultimately applied as accelerations, never directly as positional or velocity corrections) over time, the final velocity achieved during a change in ship velocity can be significantly different from the intended velocity. IFCS requested the above velocity change and it got the one shown in Fig. 6.
This is where the original feedback system comes into play. It looks at the actual state of the ship compared to the intended state and generates additional corrective accelerations to keep the motion as close to the ideal as possible.
The example shown here in Fig. 7 is for velocity error and feedback correction, but a more obvious example in-game will be attitude control. IFCS has a reaction control system (RCS) that maintains the ship’s attitude as set by the pilot (the control frame). Because of thruster error, as well as other external factors, the actual attitude of the ship can deviate from the ideal attitude. The RCS uses the feedback control system to generate thrust and maintain the ship’s attitude at its intended state. In practice, thruster turbulence from imperfect thruster performance will generate a small amount of play in the nose of the ship, especially when firing thrusters at full capacity and when first settling in to a motionless state. But again, the goal is for this error level to be subtle except under extreme damage conditions. This is about the aesthetics of motion more than it is about flight behavior.
Ultimately, the experience of Star Citizen is the combination of all of its systems, so to really explain flight, we also need to talk about combat.
The goal of combat in Star Citizen is to provide frenetic, fast paced action while rewarding thoughtful tactics and planning. This means different things at different scales of ship – from the intense furballs of the single-seater dogfighters, to WWII style turning battles to bring full guns to bear in multi-crew, to outright wars of attrition and spacing on those giant capital ships – they each offer their own unique flavor of combat. However, the philosophy for all of them is largely the same: combat is most fun when juggling different levels of risk, reward, and commitment.
For most ships, the lowest common denominator of any input is rotation. Crew safety limits the really big ships from pulling aggressive flips, but for the smaller crafts, turning is much easier. Offensively, this empowers aim (again, with diminishing returns by scale), but defensively, skilled pilots will try to take unavoidable impacts where their shields and armor are strongest. Rotation inputs will also improve with the addition of an input stabilization mode, which clamps rotations to the lowest maximum rate available, removing a large amount of scalar error in the control frame. The ship properties remain unchanged by this, so maneuvers still realistically favor a particular axis according to their design, but the input itself is more predictable and intuitive.
Ships are generally built to favor main engines, although the strength ratios of this are very much a part of the personality of each vessel. This means drift, as we’ve seen already in recent patches, and that flight maneuvers require a bit of thinking ahead, even with use of boost. This again makes shooting easier, but taking damage is a big part of the experience of Star Citizen and is something we support at every level. The choice to include multiple components of each type allows for more meaningful capability degradation and for ships to remain operational at much greater levels of damage. After the fight, your hull will be scarred with reminders of your most recent adventure. Or, if things are looking dire, you’ll be able to repair ships in the field and triage incoming damage. It’ll probably be a good idea to take care of those failing coolant lines before they lead to an unchecked engine breach and a full power plant meltdown that blows up your ship (looking at you Connie).
With the ability to take more damage comes longer levels of commitment which also means increased management of things like fuel, heat, and g-forces. The more shortcuts that get taken, the more backed into a corner you will become. Captains will have to weigh the longer term risk of the short term reward if they want to emerge the victor.
Of course, all of these things ultimately rely on balance to support the systems, and balance is a long and deeply involved process. It’ll take some time to get this balance right, but the goal is to play into the strengths at each scale, and the gameplay opportunities that these afford. In the smallest ships, maneuverability is king, so the upper hand is earned by forcing your opponent to take more risks, overplay their hand, and become vulnerable to a killing blow. Rotation is easy in space, so you can be sure that any small ship you shoot at will be shooting back soon after. One of the reasons for this is simple physics, as the ships become more massive the thrust required to offer quick rotations scales drastically, and for reasons of control feedback and responsive handling, our ship’s rotations have smaller windows for error than translation does. Multi-crew ships can also afford larger periods of vulnerability, as the upcoming repair mechanics, shield manipulation, and pipe routing offers a ship under fire plenty of ways to improve the situation and swing the tide of battle.
As these ships get larger and larger, the gameplay pushes further into demanding tactical forethought, with positioning and the management of ship resources becoming increasing concerns during a fight. A key goal of this kind of combat is to keep success and failure from ever becoming too binary, or to allow the battle to be determined by ever-fewer, ever-smaller mistakes. At a fundamental level, Star Citizen is a game in which ship-to-ship combat should remain fun and fair even when a cargo ship’s ambushed by pirates, a capital ship’s taking on single-seaters, and the loss of property and life comes at a high price. You won’t always win, and when you do suffer a loss, we want it to feel like it mostly came down to a matter of skill. We want this to be skill based, but we also want to have a sense of progression in the PU. A Hornet F7C should be objectively a better ship than a Mustang Alpha, but the power differences should not be so extreme that the Mustang pilot will never beat a Hornet – it will just be a more challenging fight.
Star Citizen is a game about choices, so every time you leave the hangar you’ll have to decide which ship to fly, what equipment to install, who to have on as crew, what routes to take, even where and when to store cargo. Each ship has its personality, each weapon has its trade off – each path has its dangers. The goal is not to make all things to all people, but to create an ecosystem in which players can find the exact right mix for them. Some will prefer to monoboat, and in the narrow window of their specialty they will find success; others will prefer self-reliance, and will find a varied loadout to suit the varied obstacles that await. These choices affect everything, from the power draw to the heat burden, all the way down to how fast the ship flies, how much it drifts.
Join the discussion here: https://forums.robertsspaceindustries.com/discussion/293412/flight-model-ifcs-2-0-feedback-and-discussion
SettingsOne column Two columns Oldest first Newest first Most appreciated first