 | |||||||||||||||||||||||||||||||||||||||
| 系列 | Design | ||||||||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 類型 | Transmission | ||||||||||||||||||||||||||||||||||||||
| ID | 13951 | ||||||||||||||||||||||||||||||||||||||
| 發佈日期 | 2014-06-16 | ||||||||||||||||||||||||||||||||||||||
| 來源 | | ||||||||||||||||||||||||||||||||||||||
| 系列文章 | |||||||||||||||||||||||||||||||||||||||
| |||||||||||||||||||||||||||||||||||||||
FROM THE CHAIRMAN: FLIGHT MODEL AND INPUT CONTROLS
Greetings Citizens,
It’s really great to see so many of you taking to space to try out the first taste of what space combat will be in 星際公民. I, like the rest of the team have been avidly watching the Twitch streams of backers playing and reading the forums for your feedback. Two of the hot topics of debate have been the Flight Model and the advantage or disadvantage of various input devices. So I thought I would take a moment of your time to share some insight on the two topics.
Flight Model
Most space games (including my past ones) greatly simplify the simulation, usually as an atmospheric flight model without gravity and air resistance – ships have predefined pitch, roll and yaw rates, linear acceleration (that is applied to a simplified point mass) and a capped top speed. When you want to turn, the joystick or mouse input is mapped directly to the specified turn rate irrelevant of the ship’s moment of inertia. Damage is usually handled as a multiplier on the turn rates and linear acceleration.
Star Citizen doesn’t do that. We model what would be needed on an actual spaceship, including correct application of thrust at the places where the thrusters are attached to the hull of the ship – in our model moment of inertia, mass changes and counter thrust are VERY necessary. Star Citizen’s physical simulation of spaceflight is based on what would actually happen in space.
There were a couple of reasons why we went this direction –
- Because we were planning on modeling and simulating spaceships with a fidelity that hadn’t been seen before I felt we needed a simulation that would let the player have different flight behavior if a thruster is damaged, a wing is blown off or a pilot overloads his ship with weapons and ammunition? I wanted a system that could feel distinct for a huge variety of ships, with wildly different sizes and roles because in Star Citizen you can go from a single seater ship 15 meters in length to a huge capital ship over 1km in size crewed by many players. I wanted these ships to come with their own identity and feel much like similar sized cars, even if equivalent in mass can feel radically different. I wanted ships to have their own personality – not just a slower of faster version of the base ship.
- The second is that Star Citizen will have a significant amount of player vs. player combat. I don’t know how many people played Wing Commander Armada (the first Wing Commander game to feature multiplayer) but it wasn’t that much fun in battle mode (the head to head mode). When you design a single player game you can deliberately dumb down the AI to allow the player to get on the tail and shoot down multiple enemies, which gives the player a sense of achievement. There’s nothing more fun than single handily clearing a wave of 10 enemy Kilrathi fighters. But let’s be honest, in single player games the ability for the player to gun down waves of enemies has less to do with the skill of the player because the player is usually overpowered in respect to the base enemies he will fight. You can’t do this in player vs player, and it’s likely that multiple players will have the same ship. Without a sophisticated simulation and flight model, with lots of options for a pilot to fluidly try different tactics to get the upper hand the battles can end up as a frustrating stalemate when both pilots have the same ship as no one can get on the other’s tail because you don’t have the same forces that affect air combat (namely gravity and air resistance) to bleed energy from the maneuvers.
These reasons are why we went out of our way to fully simulate the physics that would involve controlling and moving a ship in space with no short cuts.
In the very same way we also simulate the ship systems. Every function is tied to individual items that are 「plugged」 into the ship – the weapons, the thrusters, power plant, heat sinks, radar, fuel tank, batteries, targeting system, CPU, HUD and even the Intelligent Flight Control System (IFCS) are all items that tie into various 「pipes」 that connect the systems – there’s a pipe for power, heat, fuel and CPU cycles. The targeting computer needs power from the Power Plant and CPU cycles from the Ship’s Computer, positional information from the Radar to resolve targets. If there aren’t enough CPU cycles to go around the targets will resolve slower, not enough power and the targeting computer may stop functioning all together. If you don’t draw off enough heat from the weapons, they may overheat, malfunction or even become damaged. If one of your wings gets blown off with its attached heat sinks, you better scale back your heat output.
By fully simulating both the systems and physics of powered spaceflight we allow for a huge amount of emergent behavior and variety in the final game. Ship load out becomes very important not just for functionality but also for actual flight and responsiveness. Just like in real military aviation design, you could decide to have redundant systems for better battle survivability or you could maximize your hitting power at the expense of maneuverability.
Sounds pretty cool right? So why all the fuss?
Proper space flight simulation is inherently different than an atmospheric flight model. In space there is no aerodynamic force (lift or drag) and so both angular and linear inertia becomes much more important. Unless you apply a counter force to arrest the angular or linear momentum of an object in space it will continue unaltered. When a player pulls back on the stick the thrusters apply thrust to create rotation, which accelerates the ship’s angular velocity. When you let the stick return to zero or move it the other way, the IFCS now has to apply counter thrust to first retrograde the current angular velocity and then move you towards the new desired angular velocity. Unless the ship has hugely overpowered thrusters, this will not happen instantly. As the IFCS isn’t clairvoyant and doesn’t know when you wish to change angular velocity it can’t anticipate your actions, so unless the pilot himself eases into his desired orientation, it’s likely he will overshoot it. Think of it as stopping in a car; you normally have a good feel for your stopping distance and so when approaching a stop sign you start to slow down. You don’t expect to go from 50 mph to zero instantly. This behavior is quite different from an airplane which uses control surfaces that alter the airflow over the wings/tail to maneuver. In this case the angular velocity change is normally directly proportional to the rudder/flaps position.
This means that to a certain extent you need to anticipate where you want to be and ease into that position. If you’re used to an atmospheric model when first flying in a model where momentum is much more important it is pretty easy to overshoot your desired heading. Then as the counter thrust isn’t instant you can overcorrect the other way. This is why the ship can feel 「twitchy」 when trying to line up a target.
As this is different than what people are used to, a portion of our community clearly feels the current flight model is 「wrong.」
But if you think about what we are doing, we actually allow for a LOT more variation and nuance in flight and combat than a simplified Wing Commander/X-Wing style flight model. Like learning to drive a car really well…it requires some learning. You have to anticipate where you want to be and plan for it.
Does this mean I think the system is perfect?
No!
This is one of the big reasons we wanted to get it into all of your hands. It’s been great seeing people play the game and provide their feedback. It’s been really great to see quite a few people who first hated the flight model, come around to seeing its potential after some other members of the community have shared their insights. This doesn’t mean everyone is sold but it’s always heartening to see people being open to new possibilities.
But that doesn’t mean that I’m satisfied with where we are. My goal is to have all the nuance that I describe above for the players that want to go deep but also make it accessible in the way Wing Commander was for someone new to the game (and genre).
The key thing to remember is that the Intelligent Flight Control System is just the interface between the physical simulation of the ship’s movement via its thrusters and the force they exert. It’s not the model. I see a lot of posts talking about the desire for 「Newtonian」 mode. The physics simulation is already a full Newtonian rigid body simulation. For what we are trying to achieve there will always need to be a fly by wire interface between the players input and the actual physics as no human can simultaneously direct eight thrusters simultaneously, specifying their thrust and attitude to achieve desired movement. Within the confines of physical reality the IFCS can do pretty much anything we want. The key is determining what we want the player’s input to map to.
The first pass of various modes – basic IFCS, De-Coupled, G-Safe and Comstab are all different modes that we felt would be useful at various times. It doesn’t mean it is the end of the modes, or how they are implemented is the only way they will be. A lot of people have been asking for 「true」 6DOF available all the time – basically having strafe available during normal IFCS flight mode and to make strafe additive to the ship’s velocity in decoupled mode. These are all things that we will experiment with, along with quite a few other options e.g., an additional G-Safe mode that is turn limited rather than speed limited and we’re also going to be playing with thruster power as currently the maneuvering thrusters are about a half to a third of the power of the main engines which is fairly overpowered Just be warned the weaker the maneuvering thrusters the more the ship will 「slide」 at speed before vectoring to the desired direction.
To give you even more insight into how the IFCS works, John Pritchett, the engineer who wrote the current implementation of the IFCS has written an in-depth piece that goes into the detail of how the system works. I hope you will all appreciate the level of detail we are aiming for in Star Citizen. Don’t forget there is so much more to the game than just Arena Commander – and even in Arena Commander there is so much that cannot be appreciated yet as we are blocked by a work in progress HUD and lack of items to equip your ship with – both of which will open up new possibilities and tactics.
Control Devices
There has been a lot of debate about mouse control vs. joystick control and the worry from some portion of the community that the mouse scheme makes the game too 「arcadey」 and HOTAS users feeling that their control mechanism of choice has not been supported properly.
Firstly let me state the goal for Star Citizen will be controller agnostic. No one control mechanism should have an advantage over the others. Personally I am a joystick pilot (either through HOTAS or Gamepad) as opposed to a mouse pilot. I just feel like I have more precise flight control with a joystick. In our various studios there is a huge variety of controller use – some prefer mouse, some joystick, some HOTAS and some gamepad. This is the best guarantee that any one control mode will not dominate.
Having said this we recognize that the control input schemes need work in flexibility/customization to achieve this goal.
One of our top priorities for Arena Commander is to allow users to customize their key bindings form inside the game. We are actively working on this and hope to deliver something next month.
We also will be working on the various HOTAS profiles, as well as fine tuning the control filtering for joysticks to hopefully allow for crisper maneuvering during smaller movements of the stick. There are also some additional head look modes that haven’t been implemented yet that will allow a joystick player to take advantage of the gimbaled weapons the way the mouse player can. And of course if you feel the mouse, with its greater precision allows for better aiming you could always fly the ship with a joystick and look with a mouse!
Yaw vs Roll
There has also been some discussion around the fact that yawing does not impact your pilot in terms of negative G effects (i.e. the black and red out of the vertical G forces). There are a few things to consider here. First, pure yawing turns, without any bank, are certainly possible in space, but that isn’t the optimal way to turn. You can generate more thrust by combining your side and lower thrusters than you can with just your side thrusters. IFCS automatically banks a ship to optimize its turning thrust, and this is where vertical G forces come into play (note this is different from atmospheric flight where banking is necessary for turn stability). Second, the amount of bank in any yawing turn will depend on the amount of side thrust that your ship can provide, which means the amount of vertical G forces in a yawing turn will vary based on the situation. Third, black/redout and loss of consciousness are consequences of vertical g-force exposure only, where blood is being either drained from or forced into the pilot’s head. Properly constrained pilots can withstand very high levels of horizontal G forces without any significant loss of cognitive ability.
For horizontal g-forces, the limiting factor is structural. Unfortunately, that limitation has not yet been implemented in our model. Once it is, there will be consequences for extreme unbanked turns. Instead of blacking out, you might rip off a thruster or a wing from the sheer magnitude of the horizontal Gs. And if enabled, G-safe mode will guarantee the structural integrity of your ship by limiting the amount of thrust in any maneuver.
Turreting
A portion of the community has expressed concern about the ability for players to 「turret」 by going into decoupled mode and spin around to fire at their target, feeling this removes the skill level of dogfighting. I know people think this but I can assure you that in our internal multiplayer tests pretty no one exclusively decouples and 「turrets」 as they would get destroyed very quickly. The key to surviving a dogfight is about being constantly on the move and not being predicable with your movements – sitting still or moving in a constant vector (which is what happens when you decouple) will get you killed. Decoupled mode is best used by going into briefly for a quick orientation change then dropping back into coupled mode. As we tweak the power of the maneuvering thrusters to make the main engine more significant going into decoupled mode, making a quick orientation change and going back into normal flight will be a great way to maximize your available thrust for a quick vector change. I know that some people think that being able to change your orientation much quicker than you can in an atmospheric flight sim makes the game easy but this is a space combat simulation NOT an atmospheric flight simulation and the ability to decouple your orientation from your velocity vector is absolutely something that would be used – and don’t forget a huge amount of the community demanded to be able to do the maneuvers you loved from Battle Star Galactica!
Gimbaled Weapons vs Fixed
In Arena Commander V1.0 (and Star Citizen as a whole) there will be both fixed weapons and gimbaled/turreted weapons. The fixed weapons will have a slow auto convergence of perhaps -/+ five degrees to allow them to focus at a point that is user definable (defaults to half maximum range) or will adjust to the distance of the current target. We didn’t have time to finish this feature so for v0.8 we just made all fixed weapons gimbaled in order to not give the Hornet a huge advantage over the Aurora and 300i. This is not the long term plan.
Fixed weapons will have a lead indicator (just like in a real combat aircraft). We are also considering altering how the gimbaled guns look reticle operates. Right now you just have to place it over your target and the targeting computer gimbals the guns to achieve that firing solution, when the dotted lines collapse inside the reticle it means that all guns have achieved the solution. We are thinking about making it so you have to place the look reticle over the lead indicator in order to achieve the firing solution.
This will allow a pilot who is not using the full power of his gimbaled guns (it’s not always easy to aim and fly into two different directions or if you’re in a combined look and fly mode like the 「Freelancer」 mouse mode) to fly in a more optimal manner for leading the target (you want to heading at where the target is heading not where it is now)
As for people thinking that gimbaled weapons spoil the 「skill」 in the game, gimbaled / turreted weapons are a mainstay of current military equipment and will likely be even more so in the future. That doesn’t mean a hit is automatic. The weapon still has to come to bear on the target and you have to be pointing your ship’s nose in such a way as the firing solution can be met. And that’s assuming the target doesn’t start changing course or speed erratically!
— Chris Roberts
INTELLIGENT FLIGHT CONTROL SYSTEM OVERVIEW
In Star Citizen, IFCS is a flight control system that is designed to assist the pilot in operating a spacecraft. It translates a pilots control inputs into thruster operations to accomplish a designated command, even under a sub-optimal or failing propulsion system. It is an adaptive system that uses a combination of sensors and feedback control to drive the error between the goal state and the actual spacecraft state to zero. It is fault tolerant, in that it can adaptively utilize any combination of thrusters and its backup Control Moment Gyro to compensate for the failure or loss of one or more thrusters and keep the craft stabilized and, if possible, under pilot control. Even with a single thruster remaining, a pilot can, with some difficulty, actively control his or her spacecraft.
IFCS Subsystems
IFCS is comprised of many subsystems that work together to provide a pilot with spacecraft stability and control. These include:
- Propulsion and Attitude Control (PAC) – PAC includes, typically, the full set of thrusters, which provide both translational and rotational action, and a backup Control Moment Gyro (CMG) unit which provides supplemental attitude control. It also includes the circuitry and control software that drive these units.
- Primary Control System (PCS) – The PCS provides an interface between the pilot and IFCS. It translates a pilot’s commands into control actions that are applied to a virtual control frame which represents the ideal goal action of the pilot. The virtual control frame consists of a goal velocity along any combination of axes, goal rotation rates about any combination of axes, as well as a reference attitude. This virtual frame represents the ideal state of the craft under perfect control, and all pilot input is applied relative to this virtual frame, thereby limiting the effect of external error on pilot control.
- Reaction Control System (RCS) – The physical state of the PCS virtual frame is controlled by the predicted thruster and CMG output in response to pilot control. Under ideal conditions, the PCS frame attitude will be perfectly synchronized with the actual attitude of the spacecraft. However, factors such as sub-optimal thruster response or failure, external forces such as weapons fire, missile explosions, etc., can cause the real attitude of the craft to deviate from the virtual attitude. When this happens, it is the job of the Reaction Control System to drive the error between the two attitudes to zero. It attempts to do so using both thrusters and the Control Moment Gyros. If it fails to synchronize the attitude of the real and virtual frames within a reasonable time, it may reset the virtual frame attitude to that of the real spacecraft in order to avoid pilot disorientation.
- Anti-gravity System (AGS) – The AGS detects and compensates for gravity, and, in general, any other continuous external force, allowing the spacecraft to maintain its position relative to the field’s source.
- Turn Control System (TCS) – TCS assists the pilot in achieving stable turns. At high speed, a spacecraft’s thrusters may not provide enough force to hold a stable turn, causing the ship to slide, often resulting in a collision. A pilot will normally decrease his or her speed when turning, but TCS can manage the throttle for you by automatically setting the forward velocity to match the desired turn rate given the level of turning thrust currently available. The system takes into account the optimal banking thrust in calculating the sustainable turning velocity.
- G-force Control Mode (GCM) – GCM is a safety mode that attempts to limit a pilot’s exposure to potentially dangerous levels of g-force. The primary danger for a fully constrained pilot is prolonged exposure to vertical g-forces which can cause blackout, greyout, redout, disorientation, loss of consciousness, and, if not corrected, even death. Horizontal g-forces of an extreme nature are also avoided, as they can cause both physical harm to a pilot and structural damage to the spacecraft.
In addition to these standard subsystems, other functionality may be implemented for more advanced systems.
IFCS Operation
IFCS takes as input a pilot’s commands, which may include a variety of operations, but are ultimately translated into 3 degrees of translation and 3 degrees of rotation. Additionally, other pilot inputs may be used as parameters in various phases of the IFCS control system.
Once the input values are modified by IFCS modes such as Turn Control and G-force Control, speed limits are imposed, etc., the modified inputs are passed into the Primary Control System, which includes both a linear and angular velocity PID controller. These control functions calculate the optimal force and torque which, if applied at the ship’s center of mass, will provide the motion requested by the pilot.
Simultaneously, attitude readings are passed into the Reaction Control System where a positional PID controller is used to drive the ship’s real attitude toward a goal reference attitude provided by the PCS. The control function outputs a torque that will optimally decrease the attitude error over the next time step.
Finally, a reading of persistent force fields, typically gravity, is passed into the Anti-gravity System which calculates the necessary counter-force.
Once the desired forces and torques have been calculated, propulsion resources are allocated to them in order from highest to lowest priority. AGS force is allocated first, as failure to generate sufficient counter-propulsion could be catastrophic. Next, RCS torque is allocated, drawn from primary propulsion first, then falling back on CMG torque if insufficient propulsion is available. Next, PCS rotation control is allocated, again drawing upon primary propulsion first, CMG torque next. And finally, at the lowest priority, translational control is allocated.
After a short time, once the propulsion system has acted on the IFCS commands, sensors read the ship’s actual state, which may vary from the expected state because of propulsion malfunctions, uncompensated external forces, etc., then feeds the results back in to the IFCS control loop and the process repeats.
Velocity and Attitude Control
Because IFCS cannot rely on the propulsion system to deliver the requested control, it uses a PID feedback controller to minimize the error between the desired state and the measured state. Such controllers are used by the Primary Control System to calculate the optimal force and torque to carry out the pilot’s control commands, as well as the Reaction Control System to maintain attitude stability.
PID controllers can be tuned to provide a range of response characteristics. Using velocity control as an example, an overdamped controller will accelerate quickly toward the reference velocity, overshoot, then oscillate as it settles into the final velocity. An underdamped controller will accelerate more slowly, settling into the reference velocity without any overshoot. A critically damped controller will accelerate at the optimal rate to settle in minimum time without any overshoot. The Primary Control System controllers that provide linear and angular velocity control are dynamically tuned. Based on pilot input magnitude, they can range from a subtle to aggressive acceleration response. In addition, individual pilots may prefer a more or less stiff acceleration response.
The actual response time of IFCS controllers is dependent not only on the tuning parameters, but also on the response time of its propulsion system components.
Propulsion System
Thrusters
The primary component of propulsion on most ships will be the thruster. The Star Citizen flight model provides a 100% accurate thruster model that takes into account the location of each thruster relative to the ship’s true center of mass, and the maximum thrust capacity and response time of each thruster. Under ideal conditions, the thrusters will generally be balanced about the ship’s intended center of mass. This allows the ship optimal thruster control. In this sample image, the top rear thrusters are balanced about the center of mass and will generate a zero sum torque about the z axis.
After suffering damage, the center of mass may shift, destabilizing the thruster system. In the following image, the thrusters are no longer balanced about the center of mass. When firing the thrusters, the ship is subjected to non-zero torque, resulting in an unintended yaw. IFCS will attempt to compensate for this torque error by using other thruster pairs to generate counter torque, and if unable to do so, will attempt to limit the error by decreasing the amount of thrust generated by the thrusters.
Damage and other conditions can also change the available thrust capacity, response time and even accuracy of each thruster, or a thruster may become completely non-functional or be lost altogether. Any of these changes will have an effect on the thruster balance and therefore how the ship behaves under pilot control.
Control Moment Gyro
Each ship has a small amount of backup torque available to it even if every thruster has been lost. This torque is provided by a set of internal Control Moment Gyros. As long as the CMGs are functional, the pilot will always have minimal torque available on each axis of rotation. This torque is sufficient to stabilize the ship’s attitude, and can be used to slowly spin up or down under direct pilot control.
Final Notes
This document is not an in-fiction description of the Star Citizen IFCS, it is an accurate description of the true flight control model implemented for the game. This level of realism was necessary in order to deliver a flight control system that could be fully integrated with and influenced by the environment, damage states, changing mass distribution, power allocation, thruster placement, etc. IFCS is an emergent system, and therefore may be imperfect at times. But this mimics reality.
And finally, great effort has been made to limit spacecraft control to only the command pathways provided by IFCS. No player, AI or even IFCS itself will ever modify the position, velocity, rotation or rotational velocity of a ship directly, with the exception of initialization and network correction. This guarantees that all spacecraft control is consistent and the game will never have an unfair advantage over a player.
I look forward to your feedback as we work to refine and polish this system. After all, this is only the beginning. We’re just getting started!
John Pritchett
Physics Programmer at CIG