Post by probaddie on Jan 22, 2013 22:30:54 GMT -5
Kicks and Speeds: Recoil In-Depth
Table of Contents
1. Introduction
2. Preliminaries
3. The Mechanics of Recoil
4. Mathematical and Qualitative Analysis of Recoil
5. The Limits of Understanding
6. Conclusion
7. Acknowledgements
Appendix: Proof of Equation 4.3
1. Introduction
It likely goes without saying that recoil is the most technically complex and misunderstood mechanic in the Call of Duty series. Though the basic foundations of its method are fundamentally unchanged since the series' inception, a full understanding of these foundations remained elusive for some time.
Uncovering the mystery behind its inner workings by the series' fans has been piecemeal and gradual – a collective work of minute epiphanies by various individuals over the last nine years. Within these fora – spread across multiple threads – you will find these epiphanies; together they form a near-complete understanding of recoil.
But such piecemeal discoveries have led to this information being buried in countless posts. No one place exists where the mechanics of recoil, in all its technical detail, are elucidated.
This is what this thread seeks to remedy. Here, all the known aspects of recoil in the Call of Duty series will be explained and clarified inasmuch as they possibly can. Not all of this work is my own: I will attempt to give credit to those who originally made these discoveries in a separate section and apologize in advance to those I may accidentally exclude.
2. Preliminaries
First, a word about the scope of this post.
There are four mechanics in Call of Duty that will perturb a player's point of aim without player input: bob, the movement of the player's ironsights, crosshairs or aiming reticule while moving with the sights raised; idle sway (referred to as simply “idle”), which always manifests when the player is aiming down the sights (ADS) and regardless or whether they are moving or not; flinch, a perturbation of the player's view – herein we shall call this the “viewport” – which arises whenever the player sustains damage; and recoil, a perturbation of the player’s view (and possibly the aiming reticule itself) which arises when the player fires their weapon.
There is also a mechanic which will randomly distribute the shots a player fires called spread. Both hip spread and ADS spread exist – though in nearly every title since Call of Duty 4: Modern Warfare, ADS spread for nearly all weapons (except shotguns) has been zero (i.e., the rounds land exactly wherever the aiming reticule is placed).
These five mechanics are governed each by five separate mechanics. We will not cover the effects of the first four listed, and we will consider recoil to be only the perturbation in aim which arises from the weapon being fired and nothing else.
Second, a summary of atomic terms used throughout this post:
As mentioned, “viewport” refers to the window through which the player views the world.
As mentioned, aiming down the sights (ADS) refers to the player looking through the aiming reticule of their weapon.
For simplicity, “point of aim” will refer to the point of aim indicated by whatever sight the player is using, whether that is a reflex sight, scope, a set of ironsights, or simply the center of the screen (in the case of hip firing).
A player's “original point of aim” will refer to the direction the player is aiming without any perturbation by recoil.
“Yaw”, “pitch” and “roll” refer to Euler angles, the coordinate system used in Call of Duty to represent orientation. Yaw rotations represent “horizontal” movement, pitch rotations represent “vertical” rotations, and roll rotations represent a corkscrewing rotation. (Think of a plane doing a barrel “roll” and how that looks from a pilot’s perspective.)
Finally, a word about frame rates and delays. Every version of the engine on which Call of Duty titles run is known to exhibit what is called frame coupling. In essence, this means that nothing happens on the client in-between each rendered frame.
The consequence of this to recoil is that a player's weapon cannot be fired between two frames. Thus, the actual time between shots can vary depending on the framerate of the client at any given time, even if the weapon has a set fireTime. On top of this, it is known (thanks to Marvel4) that, on any shot, the trajectory of that shot will not begin until a set number of frames have been rendered: this is known as "frame delay". The number of frames that must be rendered before the weapon begins its trajectory varies from game to game.
Unfortunately, these effects are almost impossible to account for consistently, as their effect varies with the framerate of the client. Throughout this post, we will ignore the complications caused by frame coupling.
With these preliminaries out of the way, the main exposition begins.
3. The Mechanics of Recoil
3.1 Visual Recoil
“Visual recoil” may seem like a misleading term. After all, we should always be able to see the perturbation that recoil causes. However, “visual” in this case is meant to imply that this effect is purely visual, and that it has no effect on the perturbation of the player's point of aim. What, then, is meant exactly by “visual recoil?”
Every weapon is represented in-game by a model, a three-dimensional rendering of the object that the character holds when shooting. Whenever the weapon is fired, an animation is played that will “jolt” the model, giving the impression that the weapon the player is holding has recoiled.
This animation, however, has no effect on the perturbation of the player's aim – hence the phrase “visual recoil”. This animation is simply in place for visceral effect.
Below is a video illustrating the effect. The AK-47 in Call of Duty 4: Modern Warfare is notorious for its firing animation, which misleads the player into believing that their point of aim is being perturbed. In this video – with credit to mmacola – the AK47 is modified to have no recoil other than the firing animation. As can be seen, every shot fired has landed in exactly the same location in spite of the apparent perturbation of the sights:
Video 3.1. Example of visual recoil. Note that every shot has landed in the same spot. Full credit to mmacola for the video.
This effect is similar in appearance to Gunkick; however, Gunkick will result in a perturbation of the player's shots. This will be explained later.
3.2 Viewkick
Viewkick is the perturbation in the orientation of the player's viewport with respect to the original point of aim resulting from the player firing their weapon.
Figure 3.1. Diagram illustrating the effect of Viewkick on the player's view. Full credit to Den for the image.
Video 3.1. Basic in-game example of ViewKick.
With the first shot fired, the viewpoint will yaw and pitch away from the player's original point of aim. While the viewport diverges, an acceleration is applied that “pulls” the viewpoint back towards the original point of aim. The overall effect is that your character appears to have their view “jerked around” while firing their weapon.
The perturbation caused by Viewkick is determined by a velocity/acceleration model, applied separately to the yaw, pitch and (possibly) roll rotations. This model is governed by ten variables unique to every weapon:
As might be expected, the “ads” variables are applied when the player is ADS, and the “hip” variables while the player is hip firing. Other than the different parameters being used in each mode, the Viewkick mechanic is identical in each one.
For simplicity, we will discuss Viewkick as it applies to ADS only. Furthermore, it turns out that the mechanic that governs the yaw rotation of the viewport is identical to – but operates independently from – that which governs the pitch rotation. Therefore, to simplify discussion, we will now discuss yaw (horizontal) rotations in ADS only, with the understanding that whatever applies to yaw also applies to pitch (with a minor difference) and whatever applies to ADS also applies to hip fire.
We begin to describe the process of Viewkick with a diagram:
Figure 3.2.The first step of every iteration of the Viewkick process (yaw dimension only).
The red point represents the location of the viewport. It can move only left or right, as we are considering only yaw rotations. The further left the red point, the further the viewport has yawed to the left, and vice versa. Note that, despite usual convention, the left direction represents positive yaw, and the right direction negative yaw.
The viewport begins at the original point of aim, indicated by the vertical mark on the horizontal axis. When the first shot is fired, the viewport will begin to move with a random velocity. Though velocity is chosen at random, it is guaranteed to be between adsViewKickYawMin and adsViewKickYawMax (measured in degrees per second). If the chosen velocity is positive, the viewport moves to the left; if negative, the viewport moves to the right.
As the viewport moves, an acceleration is applied to it that pulls it back towards the original point of aim. In essence, this acceleration acts as a kind of "gravity" that draws the viewport back towards the original point of aim. The magnitude of this acceleration depends on the value of adsViewKickCenterSpeed and on the direction the viewport is moving.
When the viewport is moving away from the original point of aim, the acceleration is equal to the value of adsViewKickCenterSpeed (measured in degrees per second per second). When the viewport is moving towards the original point of aim, the acceleration is only one-sixteenth the value of adsViewKickCenterSpeed; it's as though the “gravity” bringing the viewport back to the original point of aim is toggled between two values, depending on which direction the viewport is moving. The net effect of this switching is that the gun will peak (i.e., stop moving) very quickly, but then will coast relatively more slowly when recovering.
Figure 3.3. The acceleration toggling that occurs as a part of Viewkick re-centering.
Video 3.2. Example of acceleration toggling. Note the different accelerations applied during deflection and re-centering.
If the viewport returns to the original point of aim before the next shot is fired, the movement of the viewport will simply stop in its tracks, regardless of how fast it is moving or how strong the acceleration is pulling it towards that point. The viewport will rest on the original point of aim until another shot is fired.
Figure 3.4. The viewport returns to the original point of aim before the next shot if fired.
Video 3.3. Example of the player's viewport returning to original point of aim.
The mechanics governing subsequent shots may differ, depending on whether the viewport has recovered (i.e., returned to the original point of aim) from the previous one. If the viewport has recovered from the previous shot and is sitting on the original point of aim, then the exact process described before is repeated. If the viewport is not fully recovered before the next shot, then the following ruleset applies in determining the initial velocity of the next shot:
Figure 3.5. The rules of how off-center velocities are chosen.
Note that, in either case, the velocity from the previous shot is erased: Viewkick has no memory of the previous shot.
This is the core of the Viewkick mechanic. This exact process is applied to pitch rotations as well, the only difference being that adsViewKickPitchMin and adsViewKickPitchMax determine the range of velocities possible in the pitch direction. (In the pitch dimension, positive pitch is upward and negative pitch is downward, as expected). Taken together, the yaw and pitch perturbations caused by Viewkick are accounted for. However, it is worth noting a couple of complications and phenomena that arise when applying this mechanic to both dimensions simultaneously.
First, the terms “away from” and “towards” the original point of aim need to be interpreted with respect to each dimension and not as a whole when considering yaw and pitch rotation simultaneously. For example, the viewport may be moving “away from” the original point of aim by moving left in the yaw dimension, but might be moving “towards” the original point of aim in the pitch dimension at the same time. To resolve this, the game will apply two separate and independent accelerations applied in each dimension. In this case, both the yaw and the pitch acceleration are one-sixteenth the adsViewKickCenterSpeed value. At any given time, it may be the case that one acceleration is reduced and the other is not, or that both are equal to the full CenterSpeed value, depending on what direction the viewport is moving at that moment with respect to each dimension.
Another oddity arises when the viewport has recovered in one dimension and not the other. For example, it is possible for the viewport to recover fully in the yaw direction while the
viewport is still recovering in the pitch direction:
Figure 3.6. The boundary caused by handling the yaw and pitch dimensions independently.
Strictly speaking, the viewport has not “recovered to the original point of aim,” as the viewport is lying somewhere above that point. However, because the viewport cannot recover any more in the yaw direction, the viewport is considered to have fully recovered in that dimension for the purposes of determining the perturbation of the viewport's yaw on the next shot. Also, because the viewpoint will not move left or right until the next shot, the viewport will appear to slide down an invisible wall as the viewport recovers in the pitch dimension. All of this is possible with the dimensions reversed as well.
There are also safeguards in place to prevent weapons with high recoil from perturbing your viewport to extreme levels. The game will prevent the viewport from deflecting more than ten degrees in any direction in both the yaw and pitch dimensions – this is the same for all weapons. These restrictions form an imaginary boundary beyond which Viewkick cannot move your viewport.
Figure 3.7. The boundaries that prevent excessive deviation
If the viewport reaches this boundary in the pitch direction, the velocity of the viewport is immediately set to zero and the weapon will begin to recover as per the CenterSpeed mechanic.
But there is a strange mechanic that applies only to yaw rotations. On every shot, for every two degrees per second of velocity that the viewport is given, the viewport is also given one degree per second of roll. Positive (left) yaw will result in counter-clockwise roll, and negative (right) yaw will result in clockwise roll. Even when the viewport reaches either of the ten-degree boundaries in the yaw dimension, the viewport can continue to roll, until it also rolls a maximum of ten degrees.
The viewport will recover its roll at exactly the same rate it recovers its yaw:
Video 3.2. In-game example of yaw and roll. Note that, though the viewport took twice as long to roll ten degrees as it did to yaw the same amount, the yaw and roll both recover at the same time -- and therefore at the same rate.
Finally – as mentioned before – everything just explained applies equally to hip fire Viewkick as well, though it is not necessarily the case that, for a given weapon, the hip Viewkick and ADS Viewkick variables will be equal to one another. Thus, a given weapon may exhibit different Viewkick behavior depending on whether the player is hip firing or ADS.
3.3 Gunkick
Gunkick is the perturbation of the location of the player's aiming reticule with respect to the center of the viewport resulting from firing the weapon. Gunkick achieves this perturbation by rotating the player's gun model (or scope overlay in certain cases), with the location of the player's viewport in the environment serving as the center of the rotation.
Video 3.3. In-game example of Gunkick at work. Note that the perturbation of the player's ironsights has affected the placement of their shots. This differentiates ADS Gunkick from visual recoil.
Outside that key difference, Gunkick is actually fairly similar to Viewkick. The core idea is the same, but applied to different entities: on every shot, a velocity is applied to the aiming reticule and an acceleration is applied to bring it back to the center of the viewport. However, there are new forces in play with Gunkick that will be explained shortly. We begin with the twenty-two variables that govern Gunkick:
(A quick note: for Gunkick, left and downward rotations are represented as positive yaw and pitch, respectively, and the right and upwards rotations by negative yaw and pitch, respectively. This violates the usual convention in both dimensions, whereas Viewkick maintained the usual “up is positive, down is negative” convention.)
Although the Gunkick variables do indeed exist for hip fire, they are not relevant. As it turns out, hip fire Gunkick has no effect whatsoever on the player's aim, as there is no aiming reticule or scope overlay to perturb:
Video 3.4. In-game example of hip fire Gunkick. The weapon is set to have no hip fire Viewkick and zero spread. In spite of the wild movement of the weapon model, every shot lands exactly on the point of aim.
The only purpose hip fire Gunkick serves is to further enhance the visual effect of the gun recoiling while firing from the hip: while hip firing, Gunkick is indistinguishable from visual recoil.
The “ads” variables, however, cannot be discarded (along with the two "gun" variables). Indeed, visual recoil is often confused with Gunkick and vice versa because they both manifest as a perturbation of the gun model with respect to the center of the viewport while ADS. It is possible to have a gun in which both the firing animation of the weapon and Gunkick are conspiring to perturb the aiming reticule. Nonetheless, it is only the contribution of Gunkick to this perturbation that has any actual effect on the player's aim.
For our discussion of Gunkick, we will again consider only yaw rotations while ADS. The same conventions from before apply to the diagram below, except that the vertical mark represents the center of the viewport and the red dot the player's aiming reticule. Similar to Viewkick, the process begins when a randomly chosen velocity is applied to the aiming reticule on the first shot.
Figure 3.8. The beginning of the Gunkick mechanic: choosing a velocity.
As before, a random velocity (in degrees per second) is chosen between two numbers; here, they are adsGunKickYawMin and adsGunKickYawMax. If adsGunKickReducedBullets is positive (not zero), the chosen velocity of the aiming reticule on the first shot will be reduced by a percentage determined by adsGunKickReducedKickPercent (which is anything from 0 to 100). This reduction applies to all subsequent shots until the number of shots fired in a single trigger pull exceeds adsGunKickReducedKickBullets.
Figure 3.9. The ReducedKick mechanic. On the left, the chosen velocity is reduced by the appropriate amount; on the right, it is left unchanged.
After that number of shots is exceeded on the same trigger pull, the chosen velocity for that shot is applied straightforward (without a reduction). If the trigger is released and then pulled again, Gunkick will consider the gun to be firing from shot one for the purposes of implementing ReducedKick. It should be noted, though, that, in practice, nearly every weapon has both of these variables set to zero.
Update: This ReducedKick mechanic applies equally to Viewkick as well. That is, whenever the number of shots fired in a single trigger pull is less than adsGunKickReducedKickBullets, the chosen Viewkick velocity for that shot is reduced by a factor given by
Gunkick is also slightly different in how it handles residual velocities. With Viewkick, residual velocities were simply discarded and replaced with new ones for the purposes of determining the evolution of the viewport. However, Gunkick will take whatever new velocity is chosen at random and add it to the previous one! For example, if the aiming reticule is moving at 40 degrees per second to the left and the velocity of the next shot is chosen to be 20 degrees to the left, the velocity of the next shot will be 60 degrees per second to the left! Velocities can also cancel each other out, if the old velocity and the new one are of opposite sign (direction).
Figure 3.10. Example showing the residual velocity of the previous trajectory being added together with the new velocity of the next shot.[/center]
adsGunKickAccel determines the magnitude of the acceleration that pulls the aiming reticule towards the center of the viewport. When the aiming reticule is moving away from the center of the viewport, the full acceleration given by adsGunKickAccel is used to "pull" the aiming reticule back. When the aiming reticule is moving towards the center of the viewport, Accel will "pull" on the aiming reticule at a reduced amount determined by adsGunKickStaticDecay. (We will discuss this shortly.)
Gunkick is also simpler in that it does not (usually) demand that the reticule “freeze” on the center of the viewport in the same way Viewkick forces the viewport to freeze on the original point of aim. If, between shots, the velocity and acceleration of the aiming reticule will allow it to pass over the center of the viewport, then it will! The only thing that changes when the aiming reticule passes the center is that the direction of acceleration is reversed, to ensure that it still works to bring the weapon back to the center of the viewport.
Video 3.5. In-game example of the lack of "locking" or "freezing" at the center of the viewport. (Note the exception to this in Figure 3.14.)
Figure 3.12. The preservation of velocity once the aiming reticule reaches the center of the viewport allows it to continue its trajectory. This is contrary to what happens to the viewport with Viewkick.
However, there is an exception to this. GunKick employs what can we call a "deadzone" to prevent the aiming reticule from oscillating very rapidly and very closely to the center of the viewport. If the aiming reticule comes within one-quarter of a degree of the center of the viewport and is moving at a velocity less than one degree per second, the aiming reticule will immediately snap onto the center of the viewport. (At the very end of the aiming reticule's trajectory in Video 3.5 you can see its effect.)
[/center]
Figure 3.13. Example of the GunKick deadzone killing the movement of the aiming reticule.
SpeedMax is yet another aspect of Gunkick which differs from Viewkick, though it is very simple. If a shot would otherwise cause the total velocity of the aiming reticule to exceed adsGunKickSpeedMax, the velocity is immediately reduced to this value. The other mechanics of Gunkick then take over as usual.
The SpeedDecay variable, in essence, determines the strength of a drag force which works to slow down the aiming reticule. For reference, a common drag force experienced in everyday life is air resistance. Like air resistance, this Decay force works harder to push back the aiming reticule the faster it tries to move. In the case of Gunkick, this drag force is linear, meaning it grows at a rate proportional to the speed of the aiming reticule. For example, if we know how much drag force the aiming reticule experiences at a given speed, then doubling the speed doubles the drag force, tripling the speed triples the drag force, etc. In general, the acceleration due to the drag force is given by the product of the velocity of the aiming reticule with the SpeedDecay number. Note that this is a fundamentally different force compared to Accel; whereas Accel is like gravity, a constant force directed only towards the center of the viewport, the SpeedDecay force is a variable force always directed against the motion of the aiming reticule whether it is moving away from or towards the center of the viewport. The two forces in tandem determine the overall force -- the "resultant force," to borrow a physics term -- that acts on the reticule.
The StaticDecay variable determines the reduction of the Accel on the aiming reticule once it finishes deflecting (moving away from) the center of the viewport. When the aiming reticule is deflecting, the full Accel value determines the strength of the "gravity" that pulls on the aiming reticule to slow it down. Once it stops deflecting, the StaticDecay value is subtracted from the Accel variable to determine the strength of that force. Below is a diagram that explains this and all the other variables at play in determining the overall effect of GunKick:
Figure 3.14. An example of all the forces acting on the aiming reticule in a typical trajectory.
Finally, the “gun” variables determine the boundaries in which the aiming reticule can move. These variables are measured in degrees and determine how far in each direction the aiming reticule – indeed, the entire weapon model – can rotate. With Viewkick, these boundaries were set to ten degrees in each direction for every weapon, but Gunkick determines this boundary for each weapon individually. Unlike Viewkick, Gunkick will not induce any roll rotation on the aiming reticule if it reaches any Gunkick boundary.
4. Mathematical and Qualitative Analysis of Recoil
4.1 Viewkick
Our goal in this section is give a mathematical description of the evolution of the viewport under the mechanics of Viewkick. We again restrict ourselves to the yaw dimension only. Furthermore, we restrict ourselves to movement in the left-hand (positive) side of the yaw dimension for simplicity. We will also ignore the complications that arise when the viewport reaches a boundary.
We note that, except when the viewport changes direction or comes to rest at the original point of aim, the viewport is under a constant acceleration. The motion of a particle undergoing constant acceleration is a well understood problem with a simple solution.
Let d be the displacement (in degrees) of the viewport, let a be the full adsViewKickCenterSpeed acceleration (in degrees per second per second), let v be the (randomly chosen) initial velocity of the viewport at the beginning of the shot (in degrees per second), and let t be the time elapsed between shots (in seconds). (The time t will be the weapon's fireTime during automatic fire, or the sum of its rechamberTime and its fireTime for manual weapons, whenever the player fires the next shot at the earliest possibility. However, it may be longer if the player deliberately chooses to allow the weapon more time to recover. Also note that the acceleration a will in this case be negative (right) because it must always be directed towards the original point of aim.)
We then already have two equations that describe the movement of the viewport. If the viewport only deflects (i.e., moves away) from the original point of aim over the elapsed time, the required equation is
})
If the viewport only re-centers (i.e., moves toward the original point of aim) over the elapsed time, then the required equation is
})
Note that the only difference is the introduction of a factor of 1/16 to the term containing the acceleration a, to represent the toggled acceleration. The only piece of the puzzle that remains is solving the case where the viewport changes direction in the same trajectory – in other words, when it “peaks.” With a bit of mathematical computation – contained in an appendix – the equation that gives this trajectory as a function of time is
})
In practice, the second and third equations are the most applicable, as they represent the situations which occur most often. This is because it is very unlikely, given the parameters typical of weapons in any Call of Duty title, for a shot to be fired and have the viewport fail to begin its re-centering before the next shot is fired – only guns with very low fireTimes (i.e., those with a high rate of fire) and low adsViewKickCenterSpeed values exhibit this behavior.
It is worth making a comment regarding the relationship between the variables at play in equations (4.1) through (4.3). The most important thing to note is that there is no simple, linear relationship between the deflection of the viewport d and the acceleration a or velocity v, even in the two simpler cases. Given a weapon with a certain set of parameters, it is not exactly clear what effect modifying the acceleration (read: CenterSpeed) of the weapon will have on its behavior. Of course, increasing the magnitude of the acceleration should dampen the weapon's recoil, and decreasing the range of possible velocities should do the same; however, there is no guarantee that improving a weapon's CenterSpeed by a factor of, say, twenty percent, will result in an improvement of the weapon's accuracy by that same amount.
We move on now to discuss some misconceptions concerning negative minimum pitch values (adsViewKickYawMin). The first thing we do to that end is to derive an expression that will give us what will be called the Viewkick critical velocity for a given weapon. By this, we mean the lowest velocity that the viewport, when resting at the original point of aim, must be given such that it fails to re-center before the next shot.
To do this, we simply need to solve equation (4.3) with respect to v. We set d to equal to zero – the viewport is returning to the original point of aim – and use the Quadratic Formula to obtain
})
Or, using rate of fire r in place of fireTime, we can write this as
})
With this, we can determine the probability with which the first shot fired will re-center for a given weapon. It suffices to determine the probability with which the chosen velocity on the first shot will be less than (4.4) in absolute value. Recall that, on each shot, the Viewkick velocity in the yaw direction is chosen randomly within a range bounded by adsViewKickYawMin and adsViewKickYawMax. (Henceforth, we will abbreviate these to vviewYawMin and vviewYawMax in any equations.) This is a uniform distribution: every velocity within the allowed range is equally likely. Therefore, the probability that the first shot re-centers is
-\max(v_{viewYawMin},-v_{critical})}{v_{viewYawMax}-v_{viewYawMin}}\;\;\;\;(4.6)})
Because the determination of the pitch rotation is independent of the yaw rotation, we can immediately write the probability of the first shot re-centering in the pitch dimension as
-max(v_{viewPitchMin},-v_{critical})}{v_{viewPitchMax}-v_{viewPitchMin}}\;\;\;\;(4.7)})
Finally, because the two probabilities given above are independent of each other, the overall probability of the first shot completely re-centering (i.e., of it re-centering in both dimensions simultaneously) is
})
Using equations (4.6), (4.7), and (4.8), we can move on to a more interesting problem involving minimum pitch values. Several weapons in the Call of Duty series have been endowed with a minimum pitch value. For example, the M4A1 in Modern Warfare 3 has a fireTime of 0.077 and the following Viewkick parameters:
Upon first inspection, one might expect this weapon to have some of its shots – we ignore whatever Gunkick the weapon may have – fall below the yaw axis, or, in other words, have negative pitch. However, this is not the case. A simulation of its fire pattern confirms this:
Figure 4.1. Recoil plot of an unmodified M4A1 from Modern Warfare 3. Unless otherwise stated, this and every other plot in this post represent the firing of 100 twelve-round groups, where the first three shots of each group are in blue, shots four through six are in green, shots seven through nine are in yellow, and the last three are in red. Note the lack of shots below the yaw axis in spite of the negative adsViewKickPitchMin value.
Why should this be? If we calculate the critical Viewkick velocity using equation (4.5), we arrive at a value of v = 12 * 1350 * 0.077 = 20.79. Because the actual minimum pitch velocity can never exceed this critical velocity in absolute value, the viewport, even if it receives a downward pitch velocity while resting on the original point of aim, will always recover back to that original point. Hence, we see no shots fall below the yaw axis. Note that the fact that we considered downward pitch here had no bearing on the result: if a given weapon has a minimum or maximum velocity value in either the pitch or yaw dimensions that does not exceed the critical velocity, then the viewport will always recover any “kick” it receives in that direction before the next shot is fired.
But this raises another interesting question. Let us suppose that our M4A1 has instead a minimum pitch value of 0 rather than -20. Clearly, this version of our M4A1 will never pitch below the yaw axis at all, let alone fail to recover a kick in that direction like our actual weapon. Will this change in the minimum value affect the weapon's behavior at all? A simulation of this weapon compared to the real M4A1 clearly shows that it will:
Figure 4.2. Recoil plot of the M4A1 with a modified adsVewKickPitch value of 0. The modification of this value has caused the weapon to exhibit more upward vertical recoil.
It should be clear upon visual inspection that the modified M4A1 tends to exhibit more vertical recoil compared to its parent. How does a change in a variable governing downward motion affect upward motion of the viewport? Remember that the velocity of the viewport on each shot is a randomly chosen number from a range determined by the minimum and maximum velocities in each dimension. On each shot, the original M4A1 has its pitch velocity chosen from within the range [-20, 50], whereas the modified M4A1 has its pitch velocities chosen from within the range [0, 50].
In the case of the actual M4A1, an upward velocity will therefore be chosen only 5/7ths (or 71.4%, approximately) of the time. Because the M4A1 will never fail to re-center on a downward kick from the original point of aim, this means that, whenever a kick velocity in the range [-20, 20.79] is chosen (which happens 58% of the time), the viewport to be closer to the original point of aim (in the pitch dimension) than it was before the kick began.
With the modified M4A1, an upward velocity is effectively chosen 100% of the time – we again ignore the extremely unlikely possibility of the gun receiving a velocity of exactly zero. Also, whenever a kick velocity is chosen in the range [20.79, 50] – which also happens 58% of the time – the viewport will be farther from the original point of aim (in the pitch dimension) then it was before the kick began. So, even though the minimum pitch of the M4A1 does not result in the weapon firing below the yaw axis, it does significantly affect the behavior of the weapon as a whole. This is only one example of how even small values of the minimum and maximum yaw and pitch variables can have a significant effect on a weapon's behavior.
There are many more interesting features of the Viewkick model that are worth investigating, but will not be explored here – they are each complex enough for their own posts.
4.2 Gunkick
In spite of the apparent relaxation of certain rules on Gunkick compared to Viewkick – the allowance of moving past the center of the viewport on a single kick, the constant acceleration applied to the aiming reticule, etc. – Gunkick, in fact, requires a more complex mathematical description than Viewkick. The source of this complication is the combination of the Accel, StaticDecay and SpeedDecay variables mentioned in the previous section.
But first, we describe a phenomenon unique to Gunkick that requires very little mathematical computation. The lack of “freezing” on the center of the viewpoint allows Gunkick to exhibit a counter-intuitive kind of behavior. As mentioned previously, when a new shot is fired, the newly chosen random velocity is simply added to whatever velocity the aiming reticule has at that moment, without erasing the current velocity. Let us consider a weapon whose yaw velocities are chosen in the range [30, 0]. (Remember that, with Gunkick, left and down are positive, right and up are negative. In this case, every velocity chosen is directed to the left, unless it is exactly zero). Suppose, then, that, on the first shot, the aiming reticule yaws up to a point and then begins to return to the center of the viewport with enough speed to move past the center. But, just before it reaches the center of the viewport, it receives a near-zero kick velocity:
Figure 4.3. An example of how -- with Gunkick -- weapons with only leftward velocity parameters can still have the aiming reticule move right of the center of the viewport.
Because the current, rightward velocity of the aiming reticule is simply added to the newly drawn zero velocity, the velocity of the aiming reticule remains essentially unchanged. Therefore, the aiming reticule will move beyond the center of the viewport and possibly fire the next shot there as well, the deadzone notwithstanding. So, in spite of us restricting our weapon to having only left (positive) yaw velocities, it is still possible in general to have the aiming reticule attain a right (negative) yaw. The reticule attaining yaw and pitch deflections opposite in direction to its velocity variables is possible in any direction and in either dimension.
To begin our mathematical analysis of recoil, we state an established result describing the motion of a particle under both gravitational and drag forces. Let d be the distance moved by the aiming reticule in the given dimension (with respect to the center of the viewport); let g be the acceleration of the aiming reticule, given by adsGunKickAccel; let b be the drag constant given by adsGunKickSpeedDecay; let c be the value of adsGunKickStaticDecay; let v be the initial velocity, given by the sum of the randomly chosen velocity with the residual velocity of the previous shot and with the possible reduced kick accounted for; andlet t be the elapsed time since the previous shot. The equation that gives the displacement of the aiming reticule during deflection is given by
e^{-bt}-g+bgt+bv}{b^2}\;\;\;\;(4.9)})
and the equation that gives the amount of re-centering after deflection (before the reticule reaches the center of the viewport) is
e^{-bt}-g+c+b(g-c)t+bv}{b^2}\;\;\;\;(4.10)})
Unfortunately, it is more or less impossible to derive an equation that accounts for the toggling of variables within a single trajectory, like the way we did with Viewkick to account for the acceleration toggling between two values. Part of the reason for this is the fact that, theoretically -- and without the deadzone -- the aiming reticule can oscillate an arbitrary number of times around the center of the viewport.
This ends our mathematical analysis of Gunkick. There are many different ways to approach analysis at this point but it would involve mathematics that are too complex for this setting. We continue by giving examples of how modifying the different variables affects the behavior of the aiming reticule, referring back to equations (4.9) and (4.10) whenever it is useful to do so.
The PPSh-41 from Call of Duty (in full auto mode) is a good example of a weapon that exhibits considerable Gunkick. The multiplayer version has a fireTime of 0.067 (895 RPM) and its Gunkick and Viewkick variables are:
Note that there are no ReducedKick parameters; this mechanic did not yet exist in Call of Duty. We will also ignore the effect that its 1.05 degree ADS spread has on its accuracy. Using these parameters, we can produce a simulation of the PPSh-41's Gunkick and Viewkick. Each graph below represents a simulated firing of the PPSh-41. First, the weapon as a whole:
Figure 4.4. The PPSh-41 with both Viewkick and Gunkick (first graph), with Viewkick only (second graph) and with Gunkick only (third graph).
In the graph for Gunkick (third graph in previous image), we can see that the aiming reticule climbs steadily with respect to the center of the viewport. How much of this behavior will be preserved when we change the minimum pitch velocity (adsGunKickPitchMin) to zero?
Figure 4.5. The PPSh-41 unmodified (first graph) and with adsGunKickPitch = 0 (second graph).
The aiming reticule has a much lower vertical perturbation; however, a considerable portion of our shots have landed below the yaw axis, in spite of the minimum pitch velocity being zero. This simulation agrees with the theoretical result we derived earlier concerning velocities and Gunkick: having a non-positive (upward) range of possible pitch velocities can still result in positive (downward) pitch.
It is instructive to demonstrate what effect the Decay variables have on the evolution of the aiming reticule. In the second graph below, the adsGunKickSpeedDecay variable has been raised to 45, and in the third it has been lowered to 15. The unmodified PPSh-41 is also shown for comparison:
Figure 4.6. PPSh-41 plots with modified SpeedDecay variables.
As we might expect, the higher SpeedDecay value helps to dampen the movement of the aiming reticule, whereas the lower one allows the reticule to deviate farther from the origin. The exact opposite effect occurs when we modify the StaticDecay variable: lower values allow the aiming reticule to return to the origin more quickly, whereas higher values hinder it. In the first image, the StaticDecay variable is set to zero and in the second it is increased to 30. The unmodified PPSh-41 is again shown for comparison.
Figure 4.7. The PPSh-41 with modified StaticDecay variables.
How might we be able to compare Accel values with its Viewkick analogue, CenterSpeed? To that end, we modify the PPSh-41 to have an adsGunKickAccel value of 1400, matching its CenterSpeed value, and run our simulation again.
Figure 4.8. The PPSh-41 with its adsGunKickAccel value equal to its adsViewKickCEnterSpeed value (1400).
What is striking about this result is that the Gunkick Kick variables are actually greater in magnitude than their Viewkick counterparts, yet we see a smaller perturbation with Gunkick. But is this due to the presence of the Decay mechanic? We set both decay variables to zero and simulate:
Figure 4.9 Modified PPSh-41 with altered adsGunKickAccel, adsGunKickSpeedDecay and adsGunKickStaticDecay values. Note that the "squarish" shape of the plot on the right is due to the GunKick boundaries (+/- 5 degrees for both yaw and pitch).
But now we might think this behavior to be a result of the higher Kick values. Finally, we modify the Gunkick velocities to match their Viewkick counterparts. In the graph on the right, each Gunkick variable has been set equal to its Viewkick counterpart (or set to zero in the case of the Decay variables):
Figure 4.10. Modified PPSh-41 with the same modified values as the previous test, but with min/max yaw/pitch values to match their Viewkick counterparts.
This serves to warn about comparing the Accel variable to CenterSpeed as though they were two sides of the same coin. Even when these two values are equal, the behavior of the weapon can still vary drastically depending on the presence of Decay and the other differences that exist in the Gunkick model. Even when all the analogous variables are set equal to one another, the difference in behavior between Gunkick and Viewkick is night and day.
Table of Contents
1. Introduction
2. Preliminaries
3. The Mechanics of Recoil
- 3.1 Visual Recoil
- 3.2 Viewkick
- 3.3 Gunkick
4. Mathematical and Qualitative Analysis of Recoil
- 4.1 Viewkick
- 4.2 Gunkick
5. The Limits of Understanding
- 5.1 The G36C in Call of Duty: Modern Warfare 3
- 5.2 Minimum Kick in Call of Duty: Black Ops II
6. Conclusion
7. Acknowledgements
Appendix: Proof of Equation 4.3
1. Introduction
It likely goes without saying that recoil is the most technically complex and misunderstood mechanic in the Call of Duty series. Though the basic foundations of its method are fundamentally unchanged since the series' inception, a full understanding of these foundations remained elusive for some time.
Uncovering the mystery behind its inner workings by the series' fans has been piecemeal and gradual – a collective work of minute epiphanies by various individuals over the last nine years. Within these fora – spread across multiple threads – you will find these epiphanies; together they form a near-complete understanding of recoil.
But such piecemeal discoveries have led to this information being buried in countless posts. No one place exists where the mechanics of recoil, in all its technical detail, are elucidated.
This is what this thread seeks to remedy. Here, all the known aspects of recoil in the Call of Duty series will be explained and clarified inasmuch as they possibly can. Not all of this work is my own: I will attempt to give credit to those who originally made these discoveries in a separate section and apologize in advance to those I may accidentally exclude.
2. Preliminaries
First, a word about the scope of this post.
There are four mechanics in Call of Duty that will perturb a player's point of aim without player input: bob, the movement of the player's ironsights, crosshairs or aiming reticule while moving with the sights raised; idle sway (referred to as simply “idle”), which always manifests when the player is aiming down the sights (ADS) and regardless or whether they are moving or not; flinch, a perturbation of the player's view – herein we shall call this the “viewport” – which arises whenever the player sustains damage; and recoil, a perturbation of the player’s view (and possibly the aiming reticule itself) which arises when the player fires their weapon.
There is also a mechanic which will randomly distribute the shots a player fires called spread. Both hip spread and ADS spread exist – though in nearly every title since Call of Duty 4: Modern Warfare, ADS spread for nearly all weapons (except shotguns) has been zero (i.e., the rounds land exactly wherever the aiming reticule is placed).
These five mechanics are governed each by five separate mechanics. We will not cover the effects of the first four listed, and we will consider recoil to be only the perturbation in aim which arises from the weapon being fired and nothing else.
Second, a summary of atomic terms used throughout this post:
As mentioned, “viewport” refers to the window through which the player views the world.
As mentioned, aiming down the sights (ADS) refers to the player looking through the aiming reticule of their weapon.
For simplicity, “point of aim” will refer to the point of aim indicated by whatever sight the player is using, whether that is a reflex sight, scope, a set of ironsights, or simply the center of the screen (in the case of hip firing).
A player's “original point of aim” will refer to the direction the player is aiming without any perturbation by recoil.
“Yaw”, “pitch” and “roll” refer to Euler angles, the coordinate system used in Call of Duty to represent orientation. Yaw rotations represent “horizontal” movement, pitch rotations represent “vertical” rotations, and roll rotations represent a corkscrewing rotation. (Think of a plane doing a barrel “roll” and how that looks from a pilot’s perspective.)
Finally, a word about frame rates and delays. Every version of the engine on which Call of Duty titles run is known to exhibit what is called frame coupling. In essence, this means that nothing happens on the client in-between each rendered frame.
The consequence of this to recoil is that a player's weapon cannot be fired between two frames. Thus, the actual time between shots can vary depending on the framerate of the client at any given time, even if the weapon has a set fireTime. On top of this, it is known (thanks to Marvel4) that, on any shot, the trajectory of that shot will not begin until a set number of frames have been rendered: this is known as "frame delay". The number of frames that must be rendered before the weapon begins its trajectory varies from game to game.
Unfortunately, these effects are almost impossible to account for consistently, as their effect varies with the framerate of the client. Throughout this post, we will ignore the complications caused by frame coupling.
With these preliminaries out of the way, the main exposition begins.
3. The Mechanics of Recoil
3.1 Visual Recoil
“Visual recoil” may seem like a misleading term. After all, we should always be able to see the perturbation that recoil causes. However, “visual” in this case is meant to imply that this effect is purely visual, and that it has no effect on the perturbation of the player's point of aim. What, then, is meant exactly by “visual recoil?”
Every weapon is represented in-game by a model, a three-dimensional rendering of the object that the character holds when shooting. Whenever the weapon is fired, an animation is played that will “jolt” the model, giving the impression that the weapon the player is holding has recoiled.
This animation, however, has no effect on the perturbation of the player's aim – hence the phrase “visual recoil”. This animation is simply in place for visceral effect.
Below is a video illustrating the effect. The AK-47 in Call of Duty 4: Modern Warfare is notorious for its firing animation, which misleads the player into believing that their point of aim is being perturbed. In this video – with credit to mmacola – the AK47 is modified to have no recoil other than the firing animation. As can be seen, every shot fired has landed in exactly the same location in spite of the apparent perturbation of the sights:
Video 3.1. Example of visual recoil. Note that every shot has landed in the same spot. Full credit to mmacola for the video.
This effect is similar in appearance to Gunkick; however, Gunkick will result in a perturbation of the player's shots. This will be explained later.
3.2 Viewkick
Viewkick is the perturbation in the orientation of the player's viewport with respect to the original point of aim resulting from the player firing their weapon.
Figure 3.1. Diagram illustrating the effect of Viewkick on the player's view. Full credit to Den for the image.
Video 3.1. Basic in-game example of ViewKick.
With the first shot fired, the viewpoint will yaw and pitch away from the player's original point of aim. While the viewport diverges, an acceleration is applied that “pulls” the viewpoint back towards the original point of aim. The overall effect is that your character appears to have their view “jerked around” while firing their weapon.
The perturbation caused by Viewkick is determined by a velocity/acceleration model, applied separately to the yaw, pitch and (possibly) roll rotations. This model is governed by ten variables unique to every weapon:
- adsViewKickPitchMin
- adsViewKickPitchMax
- adsViewKickYawMin
- adsViewKickYawMax
- adsViewKickCenterSpeed
- hipViewKickPitchMin
- hipViewKickPitchMax
- hipViewKickYawMin
- hipViewKickYawMax
- hipViewKickCenterSpeed
As might be expected, the “ads” variables are applied when the player is ADS, and the “hip” variables while the player is hip firing. Other than the different parameters being used in each mode, the Viewkick mechanic is identical in each one.
For simplicity, we will discuss Viewkick as it applies to ADS only. Furthermore, it turns out that the mechanic that governs the yaw rotation of the viewport is identical to – but operates independently from – that which governs the pitch rotation. Therefore, to simplify discussion, we will now discuss yaw (horizontal) rotations in ADS only, with the understanding that whatever applies to yaw also applies to pitch (with a minor difference) and whatever applies to ADS also applies to hip fire.
We begin to describe the process of Viewkick with a diagram:
Figure 3.2.The first step of every iteration of the Viewkick process (yaw dimension only).
The red point represents the location of the viewport. It can move only left or right, as we are considering only yaw rotations. The further left the red point, the further the viewport has yawed to the left, and vice versa. Note that, despite usual convention, the left direction represents positive yaw, and the right direction negative yaw.
The viewport begins at the original point of aim, indicated by the vertical mark on the horizontal axis. When the first shot is fired, the viewport will begin to move with a random velocity. Though velocity is chosen at random, it is guaranteed to be between adsViewKickYawMin and adsViewKickYawMax (measured in degrees per second). If the chosen velocity is positive, the viewport moves to the left; if negative, the viewport moves to the right.
As the viewport moves, an acceleration is applied to it that pulls it back towards the original point of aim. In essence, this acceleration acts as a kind of "gravity" that draws the viewport back towards the original point of aim. The magnitude of this acceleration depends on the value of adsViewKickCenterSpeed and on the direction the viewport is moving.
When the viewport is moving away from the original point of aim, the acceleration is equal to the value of adsViewKickCenterSpeed (measured in degrees per second per second). When the viewport is moving towards the original point of aim, the acceleration is only one-sixteenth the value of adsViewKickCenterSpeed; it's as though the “gravity” bringing the viewport back to the original point of aim is toggled between two values, depending on which direction the viewport is moving. The net effect of this switching is that the gun will peak (i.e., stop moving) very quickly, but then will coast relatively more slowly when recovering.
Figure 3.3. The acceleration toggling that occurs as a part of Viewkick re-centering.
Video 3.2. Example of acceleration toggling. Note the different accelerations applied during deflection and re-centering.
If the viewport returns to the original point of aim before the next shot is fired, the movement of the viewport will simply stop in its tracks, regardless of how fast it is moving or how strong the acceleration is pulling it towards that point. The viewport will rest on the original point of aim until another shot is fired.
Figure 3.4. The viewport returns to the original point of aim before the next shot if fired.
Video 3.3. Example of the player's viewport returning to original point of aim.
The mechanics governing subsequent shots may differ, depending on whether the viewport has recovered (i.e., returned to the original point of aim) from the previous one. If the viewport has recovered from the previous shot and is sitting on the original point of aim, then the exact process described before is repeated. If the viewport is not fully recovered before the next shot, then the following ruleset applies in determining the initial velocity of the next shot:
- If the new velocity (randomly chosen between adsViewKickYawMin and adsViewKickYawMax) is directed towards the original point of aim (e.g., when the viewport is left of the original point of aim and the new velocity is directed to the right), then the velocity of the viewport is reduced to one-sixteenth that value.
- If the new velocity is directed away from the original point of aim (e.g. the viewport is left of the original point of aim and the new velocity is directed to the left) the viewport begins to move with that velocity.
Figure 3.5. The rules of how off-center velocities are chosen.
Note that, in either case, the velocity from the previous shot is erased: Viewkick has no memory of the previous shot.
This is the core of the Viewkick mechanic. This exact process is applied to pitch rotations as well, the only difference being that adsViewKickPitchMin and adsViewKickPitchMax determine the range of velocities possible in the pitch direction. (In the pitch dimension, positive pitch is upward and negative pitch is downward, as expected). Taken together, the yaw and pitch perturbations caused by Viewkick are accounted for. However, it is worth noting a couple of complications and phenomena that arise when applying this mechanic to both dimensions simultaneously.
First, the terms “away from” and “towards” the original point of aim need to be interpreted with respect to each dimension and not as a whole when considering yaw and pitch rotation simultaneously. For example, the viewport may be moving “away from” the original point of aim by moving left in the yaw dimension, but might be moving “towards” the original point of aim in the pitch dimension at the same time. To resolve this, the game will apply two separate and independent accelerations applied in each dimension. In this case, both the yaw and the pitch acceleration are one-sixteenth the adsViewKickCenterSpeed value. At any given time, it may be the case that one acceleration is reduced and the other is not, or that both are equal to the full CenterSpeed value, depending on what direction the viewport is moving at that moment with respect to each dimension.
Another oddity arises when the viewport has recovered in one dimension and not the other. For example, it is possible for the viewport to recover fully in the yaw direction while the
viewport is still recovering in the pitch direction:
Figure 3.6. The boundary caused by handling the yaw and pitch dimensions independently.
Strictly speaking, the viewport has not “recovered to the original point of aim,” as the viewport is lying somewhere above that point. However, because the viewport cannot recover any more in the yaw direction, the viewport is considered to have fully recovered in that dimension for the purposes of determining the perturbation of the viewport's yaw on the next shot. Also, because the viewpoint will not move left or right until the next shot, the viewport will appear to slide down an invisible wall as the viewport recovers in the pitch dimension. All of this is possible with the dimensions reversed as well.
There are also safeguards in place to prevent weapons with high recoil from perturbing your viewport to extreme levels. The game will prevent the viewport from deflecting more than ten degrees in any direction in both the yaw and pitch dimensions – this is the same for all weapons. These restrictions form an imaginary boundary beyond which Viewkick cannot move your viewport.
Figure 3.7. The boundaries that prevent excessive deviation
If the viewport reaches this boundary in the pitch direction, the velocity of the viewport is immediately set to zero and the weapon will begin to recover as per the CenterSpeed mechanic.
But there is a strange mechanic that applies only to yaw rotations. On every shot, for every two degrees per second of velocity that the viewport is given, the viewport is also given one degree per second of roll. Positive (left) yaw will result in counter-clockwise roll, and negative (right) yaw will result in clockwise roll. Even when the viewport reaches either of the ten-degree boundaries in the yaw dimension, the viewport can continue to roll, until it also rolls a maximum of ten degrees.
The viewport will recover its roll at exactly the same rate it recovers its yaw:
Video 3.2. In-game example of yaw and roll. Note that, though the viewport took twice as long to roll ten degrees as it did to yaw the same amount, the yaw and roll both recover at the same time -- and therefore at the same rate.
Finally – as mentioned before – everything just explained applies equally to hip fire Viewkick as well, though it is not necessarily the case that, for a given weapon, the hip Viewkick and ADS Viewkick variables will be equal to one another. Thus, a given weapon may exhibit different Viewkick behavior depending on whether the player is hip firing or ADS.
3.3 Gunkick
Gunkick is the perturbation of the location of the player's aiming reticule with respect to the center of the viewport resulting from firing the weapon. Gunkick achieves this perturbation by rotating the player's gun model (or scope overlay in certain cases), with the location of the player's viewport in the environment serving as the center of the rotation.
Video 3.3. In-game example of Gunkick at work. Note that the perturbation of the player's ironsights has affected the placement of their shots. This differentiates ADS Gunkick from visual recoil.
Outside that key difference, Gunkick is actually fairly similar to Viewkick. The core idea is the same, but applied to different entities: on every shot, a velocity is applied to the aiming reticule and an acceleration is applied to bring it back to the center of the viewport. However, there are new forces in play with Gunkick that will be explained shortly. We begin with the twenty-two variables that govern Gunkick:
- hipGunKickReducedKickBullets
- hipGunKickReducedKickPercent
- hipGunKickPitchMin
- hipGunKickPitchMax
- hipGunKickYawMin
- hipGunKickYawMax
- hipGunKickAccel
- hipGunKickSpeedMax
- hipGunKickSpeedDecay
- hipGunKickStaticDecay
- adsGunKickReducedKickBullets
- adsGunKickReducedKickPercent
- adsGunKickPitchMin
- adsGunKickPitchMax
- adsGunKickYawMin
- adsGunKickYawMax
- adsGunKickAccel
- adsGunKickSpeedMax
- adsGunKickSpeedDecay
- adsGunKickStaticDecay
- gunMaxYaw
- gunMaxPitch
(A quick note: for Gunkick, left and downward rotations are represented as positive yaw and pitch, respectively, and the right and upwards rotations by negative yaw and pitch, respectively. This violates the usual convention in both dimensions, whereas Viewkick maintained the usual “up is positive, down is negative” convention.)
Although the Gunkick variables do indeed exist for hip fire, they are not relevant. As it turns out, hip fire Gunkick has no effect whatsoever on the player's aim, as there is no aiming reticule or scope overlay to perturb:
Video 3.4. In-game example of hip fire Gunkick. The weapon is set to have no hip fire Viewkick and zero spread. In spite of the wild movement of the weapon model, every shot lands exactly on the point of aim.
The only purpose hip fire Gunkick serves is to further enhance the visual effect of the gun recoiling while firing from the hip: while hip firing, Gunkick is indistinguishable from visual recoil.
The “ads” variables, however, cannot be discarded (along with the two "gun" variables). Indeed, visual recoil is often confused with Gunkick and vice versa because they both manifest as a perturbation of the gun model with respect to the center of the viewport while ADS. It is possible to have a gun in which both the firing animation of the weapon and Gunkick are conspiring to perturb the aiming reticule. Nonetheless, it is only the contribution of Gunkick to this perturbation that has any actual effect on the player's aim.
For our discussion of Gunkick, we will again consider only yaw rotations while ADS. The same conventions from before apply to the diagram below, except that the vertical mark represents the center of the viewport and the red dot the player's aiming reticule. Similar to Viewkick, the process begins when a randomly chosen velocity is applied to the aiming reticule on the first shot.
Figure 3.8. The beginning of the Gunkick mechanic: choosing a velocity.
As before, a random velocity (in degrees per second) is chosen between two numbers; here, they are adsGunKickYawMin and adsGunKickYawMax. If adsGunKickReducedBullets is positive (not zero), the chosen velocity of the aiming reticule on the first shot will be reduced by a percentage determined by adsGunKickReducedKickPercent (which is anything from 0 to 100). This reduction applies to all subsequent shots until the number of shots fired in a single trigger pull exceeds adsGunKickReducedKickBullets.
Figure 3.9. The ReducedKick mechanic. On the left, the chosen velocity is reduced by the appropriate amount; on the right, it is left unchanged.
After that number of shots is exceeded on the same trigger pull, the chosen velocity for that shot is applied straightforward (without a reduction). If the trigger is released and then pulled again, Gunkick will consider the gun to be firing from shot one for the purposes of implementing ReducedKick. It should be noted, though, that, in practice, nearly every weapon has both of these variables set to zero.
Update: This ReducedKick mechanic applies equally to Viewkick as well. That is, whenever the number of shots fired in a single trigger pull is less than adsGunKickReducedKickBullets, the chosen Viewkick velocity for that shot is reduced by a factor given by
Gunkick is also slightly different in how it handles residual velocities. With Viewkick, residual velocities were simply discarded and replaced with new ones for the purposes of determining the evolution of the viewport. However, Gunkick will take whatever new velocity is chosen at random and add it to the previous one! For example, if the aiming reticule is moving at 40 degrees per second to the left and the velocity of the next shot is chosen to be 20 degrees to the left, the velocity of the next shot will be 60 degrees per second to the left! Velocities can also cancel each other out, if the old velocity and the new one are of opposite sign (direction).
Figure 3.10. Example showing the residual velocity of the previous trajectory being added together with the new velocity of the next shot.[/center]
adsGunKickAccel determines the magnitude of the acceleration that pulls the aiming reticule towards the center of the viewport. When the aiming reticule is moving away from the center of the viewport, the full acceleration given by adsGunKickAccel is used to "pull" the aiming reticule back. When the aiming reticule is moving towards the center of the viewport, Accel will "pull" on the aiming reticule at a reduced amount determined by adsGunKickStaticDecay. (We will discuss this shortly.)
Gunkick is also simpler in that it does not (usually) demand that the reticule “freeze” on the center of the viewport in the same way Viewkick forces the viewport to freeze on the original point of aim. If, between shots, the velocity and acceleration of the aiming reticule will allow it to pass over the center of the viewport, then it will! The only thing that changes when the aiming reticule passes the center is that the direction of acceleration is reversed, to ensure that it still works to bring the weapon back to the center of the viewport.
Video 3.5. In-game example of the lack of "locking" or "freezing" at the center of the viewport. (Note the exception to this in Figure 3.14.)
Figure 3.12. The preservation of velocity once the aiming reticule reaches the center of the viewport allows it to continue its trajectory. This is contrary to what happens to the viewport with Viewkick.
However, there is an exception to this. GunKick employs what can we call a "deadzone" to prevent the aiming reticule from oscillating very rapidly and very closely to the center of the viewport. If the aiming reticule comes within one-quarter of a degree of the center of the viewport and is moving at a velocity less than one degree per second, the aiming reticule will immediately snap onto the center of the viewport. (At the very end of the aiming reticule's trajectory in Video 3.5 you can see its effect.)
[/center]Figure 3.13. Example of the GunKick deadzone killing the movement of the aiming reticule.
SpeedMax is yet another aspect of Gunkick which differs from Viewkick, though it is very simple. If a shot would otherwise cause the total velocity of the aiming reticule to exceed adsGunKickSpeedMax, the velocity is immediately reduced to this value. The other mechanics of Gunkick then take over as usual.
The SpeedDecay variable, in essence, determines the strength of a drag force which works to slow down the aiming reticule. For reference, a common drag force experienced in everyday life is air resistance. Like air resistance, this Decay force works harder to push back the aiming reticule the faster it tries to move. In the case of Gunkick, this drag force is linear, meaning it grows at a rate proportional to the speed of the aiming reticule. For example, if we know how much drag force the aiming reticule experiences at a given speed, then doubling the speed doubles the drag force, tripling the speed triples the drag force, etc. In general, the acceleration due to the drag force is given by the product of the velocity of the aiming reticule with the SpeedDecay number. Note that this is a fundamentally different force compared to Accel; whereas Accel is like gravity, a constant force directed only towards the center of the viewport, the SpeedDecay force is a variable force always directed against the motion of the aiming reticule whether it is moving away from or towards the center of the viewport. The two forces in tandem determine the overall force -- the "resultant force," to borrow a physics term -- that acts on the reticule.
The StaticDecay variable determines the reduction of the Accel on the aiming reticule once it finishes deflecting (moving away from) the center of the viewport. When the aiming reticule is deflecting, the full Accel value determines the strength of the "gravity" that pulls on the aiming reticule to slow it down. Once it stops deflecting, the StaticDecay value is subtracted from the Accel variable to determine the strength of that force. Below is a diagram that explains this and all the other variables at play in determining the overall effect of GunKick:
Figure 3.14. An example of all the forces acting on the aiming reticule in a typical trajectory.
Finally, the “gun” variables determine the boundaries in which the aiming reticule can move. These variables are measured in degrees and determine how far in each direction the aiming reticule – indeed, the entire weapon model – can rotate. With Viewkick, these boundaries were set to ten degrees in each direction for every weapon, but Gunkick determines this boundary for each weapon individually. Unlike Viewkick, Gunkick will not induce any roll rotation on the aiming reticule if it reaches any Gunkick boundary.
4. Mathematical and Qualitative Analysis of Recoil
4.1 Viewkick
Our goal in this section is give a mathematical description of the evolution of the viewport under the mechanics of Viewkick. We again restrict ourselves to the yaw dimension only. Furthermore, we restrict ourselves to movement in the left-hand (positive) side of the yaw dimension for simplicity. We will also ignore the complications that arise when the viewport reaches a boundary.
We note that, except when the viewport changes direction or comes to rest at the original point of aim, the viewport is under a constant acceleration. The motion of a particle undergoing constant acceleration is a well understood problem with a simple solution.
Let d be the displacement (in degrees) of the viewport, let a be the full adsViewKickCenterSpeed acceleration (in degrees per second per second), let v be the (randomly chosen) initial velocity of the viewport at the beginning of the shot (in degrees per second), and let t be the time elapsed between shots (in seconds). (The time t will be the weapon's fireTime during automatic fire, or the sum of its rechamberTime and its fireTime for manual weapons, whenever the player fires the next shot at the earliest possibility. However, it may be longer if the player deliberately chooses to allow the weapon more time to recover. Also note that the acceleration a will in this case be negative (right) because it must always be directed towards the original point of aim.)
We then already have two equations that describe the movement of the viewport. If the viewport only deflects (i.e., moves away) from the original point of aim over the elapsed time, the required equation is
If the viewport only re-centers (i.e., moves toward the original point of aim) over the elapsed time, then the required equation is
Note that the only difference is the introduction of a factor of 1/16 to the term containing the acceleration a, to represent the toggled acceleration. The only piece of the puzzle that remains is solving the case where the viewport changes direction in the same trajectory – in other words, when it “peaks.” With a bit of mathematical computation – contained in an appendix – the equation that gives this trajectory as a function of time is
In practice, the second and third equations are the most applicable, as they represent the situations which occur most often. This is because it is very unlikely, given the parameters typical of weapons in any Call of Duty title, for a shot to be fired and have the viewport fail to begin its re-centering before the next shot is fired – only guns with very low fireTimes (i.e., those with a high rate of fire) and low adsViewKickCenterSpeed values exhibit this behavior.
It is worth making a comment regarding the relationship between the variables at play in equations (4.1) through (4.3). The most important thing to note is that there is no simple, linear relationship between the deflection of the viewport d and the acceleration a or velocity v, even in the two simpler cases. Given a weapon with a certain set of parameters, it is not exactly clear what effect modifying the acceleration (read: CenterSpeed) of the weapon will have on its behavior. Of course, increasing the magnitude of the acceleration should dampen the weapon's recoil, and decreasing the range of possible velocities should do the same; however, there is no guarantee that improving a weapon's CenterSpeed by a factor of, say, twenty percent, will result in an improvement of the weapon's accuracy by that same amount.
We move on now to discuss some misconceptions concerning negative minimum pitch values (adsViewKickYawMin). The first thing we do to that end is to derive an expression that will give us what will be called the Viewkick critical velocity for a given weapon. By this, we mean the lowest velocity that the viewport, when resting at the original point of aim, must be given such that it fails to re-center before the next shot.
To do this, we simply need to solve equation (4.3) with respect to v. We set d to equal to zero – the viewport is returning to the original point of aim – and use the Quadratic Formula to obtain
Or, using rate of fire r in place of fireTime, we can write this as
With this, we can determine the probability with which the first shot fired will re-center for a given weapon. It suffices to determine the probability with which the chosen velocity on the first shot will be less than (4.4) in absolute value. Recall that, on each shot, the Viewkick velocity in the yaw direction is chosen randomly within a range bounded by adsViewKickYawMin and adsViewKickYawMax. (Henceforth, we will abbreviate these to vviewYawMin and vviewYawMax in any equations.) This is a uniform distribution: every velocity within the allowed range is equally likely. Therefore, the probability that the first shot re-centers is
Because the determination of the pitch rotation is independent of the yaw rotation, we can immediately write the probability of the first shot re-centering in the pitch dimension as
Finally, because the two probabilities given above are independent of each other, the overall probability of the first shot completely re-centering (i.e., of it re-centering in both dimensions simultaneously) is
Using equations (4.6), (4.7), and (4.8), we can move on to a more interesting problem involving minimum pitch values. Several weapons in the Call of Duty series have been endowed with a minimum pitch value. For example, the M4A1 in Modern Warfare 3 has a fireTime of 0.077 and the following Viewkick parameters:
- adsViewKickPitchMin = -20
- adsViewKickPitchMax = 50
- adsViewKickYawMin = 40
- adsViewKickYawMax = -40
- adsViewKickCenterSpeed = 1350
Upon first inspection, one might expect this weapon to have some of its shots – we ignore whatever Gunkick the weapon may have – fall below the yaw axis, or, in other words, have negative pitch. However, this is not the case. A simulation of its fire pattern confirms this:
Figure 4.1. Recoil plot of an unmodified M4A1 from Modern Warfare 3. Unless otherwise stated, this and every other plot in this post represent the firing of 100 twelve-round groups, where the first three shots of each group are in blue, shots four through six are in green, shots seven through nine are in yellow, and the last three are in red. Note the lack of shots below the yaw axis in spite of the negative adsViewKickPitchMin value.
Why should this be? If we calculate the critical Viewkick velocity using equation (4.5), we arrive at a value of v = 12 * 1350 * 0.077 = 20.79. Because the actual minimum pitch velocity can never exceed this critical velocity in absolute value, the viewport, even if it receives a downward pitch velocity while resting on the original point of aim, will always recover back to that original point. Hence, we see no shots fall below the yaw axis. Note that the fact that we considered downward pitch here had no bearing on the result: if a given weapon has a minimum or maximum velocity value in either the pitch or yaw dimensions that does not exceed the critical velocity, then the viewport will always recover any “kick” it receives in that direction before the next shot is fired.
But this raises another interesting question. Let us suppose that our M4A1 has instead a minimum pitch value of 0 rather than -20. Clearly, this version of our M4A1 will never pitch below the yaw axis at all, let alone fail to recover a kick in that direction like our actual weapon. Will this change in the minimum value affect the weapon's behavior at all? A simulation of this weapon compared to the real M4A1 clearly shows that it will:
Figure 4.2. Recoil plot of the M4A1 with a modified adsVewKickPitch value of 0. The modification of this value has caused the weapon to exhibit more upward vertical recoil.
It should be clear upon visual inspection that the modified M4A1 tends to exhibit more vertical recoil compared to its parent. How does a change in a variable governing downward motion affect upward motion of the viewport? Remember that the velocity of the viewport on each shot is a randomly chosen number from a range determined by the minimum and maximum velocities in each dimension. On each shot, the original M4A1 has its pitch velocity chosen from within the range [-20, 50], whereas the modified M4A1 has its pitch velocities chosen from within the range [0, 50].
In the case of the actual M4A1, an upward velocity will therefore be chosen only 5/7ths (or 71.4%, approximately) of the time. Because the M4A1 will never fail to re-center on a downward kick from the original point of aim, this means that, whenever a kick velocity in the range [-20, 20.79] is chosen (which happens 58% of the time), the viewport to be closer to the original point of aim (in the pitch dimension) than it was before the kick began.
With the modified M4A1, an upward velocity is effectively chosen 100% of the time – we again ignore the extremely unlikely possibility of the gun receiving a velocity of exactly zero. Also, whenever a kick velocity is chosen in the range [20.79, 50] – which also happens 58% of the time – the viewport will be farther from the original point of aim (in the pitch dimension) then it was before the kick began. So, even though the minimum pitch of the M4A1 does not result in the weapon firing below the yaw axis, it does significantly affect the behavior of the weapon as a whole. This is only one example of how even small values of the minimum and maximum yaw and pitch variables can have a significant effect on a weapon's behavior.
There are many more interesting features of the Viewkick model that are worth investigating, but will not be explored here – they are each complex enough for their own posts.
4.2 Gunkick
In spite of the apparent relaxation of certain rules on Gunkick compared to Viewkick – the allowance of moving past the center of the viewport on a single kick, the constant acceleration applied to the aiming reticule, etc. – Gunkick, in fact, requires a more complex mathematical description than Viewkick. The source of this complication is the combination of the Accel, StaticDecay and SpeedDecay variables mentioned in the previous section.
But first, we describe a phenomenon unique to Gunkick that requires very little mathematical computation. The lack of “freezing” on the center of the viewpoint allows Gunkick to exhibit a counter-intuitive kind of behavior. As mentioned previously, when a new shot is fired, the newly chosen random velocity is simply added to whatever velocity the aiming reticule has at that moment, without erasing the current velocity. Let us consider a weapon whose yaw velocities are chosen in the range [30, 0]. (Remember that, with Gunkick, left and down are positive, right and up are negative. In this case, every velocity chosen is directed to the left, unless it is exactly zero). Suppose, then, that, on the first shot, the aiming reticule yaws up to a point and then begins to return to the center of the viewport with enough speed to move past the center. But, just before it reaches the center of the viewport, it receives a near-zero kick velocity:
Figure 4.3. An example of how -- with Gunkick -- weapons with only leftward velocity parameters can still have the aiming reticule move right of the center of the viewport.
Because the current, rightward velocity of the aiming reticule is simply added to the newly drawn zero velocity, the velocity of the aiming reticule remains essentially unchanged. Therefore, the aiming reticule will move beyond the center of the viewport and possibly fire the next shot there as well, the deadzone notwithstanding. So, in spite of us restricting our weapon to having only left (positive) yaw velocities, it is still possible in general to have the aiming reticule attain a right (negative) yaw. The reticule attaining yaw and pitch deflections opposite in direction to its velocity variables is possible in any direction and in either dimension.
To begin our mathematical analysis of recoil, we state an established result describing the motion of a particle under both gravitational and drag forces. Let d be the distance moved by the aiming reticule in the given dimension (with respect to the center of the viewport); let g be the acceleration of the aiming reticule, given by adsGunKickAccel; let b be the drag constant given by adsGunKickSpeedDecay; let c be the value of adsGunKickStaticDecay; let v be the initial velocity, given by the sum of the randomly chosen velocity with the residual velocity of the previous shot and with the possible reduced kick accounted for; andlet t be the elapsed time since the previous shot. The equation that gives the displacement of the aiming reticule during deflection is given by
and the equation that gives the amount of re-centering after deflection (before the reticule reaches the center of the viewport) is
Unfortunately, it is more or less impossible to derive an equation that accounts for the toggling of variables within a single trajectory, like the way we did with Viewkick to account for the acceleration toggling between two values. Part of the reason for this is the fact that, theoretically -- and without the deadzone -- the aiming reticule can oscillate an arbitrary number of times around the center of the viewport.
This ends our mathematical analysis of Gunkick. There are many different ways to approach analysis at this point but it would involve mathematics that are too complex for this setting. We continue by giving examples of how modifying the different variables affects the behavior of the aiming reticule, referring back to equations (4.9) and (4.10) whenever it is useful to do so.
The PPSh-41 from Call of Duty (in full auto mode) is a good example of a weapon that exhibits considerable Gunkick. The multiplayer version has a fireTime of 0.067 (895 RPM) and its Gunkick and Viewkick variables are:
- adsGunKickPitchMin = -40
- adsGunKickPitchMax = -45
- adsGunKickYawMin = 60
- adsGunKickYawMax = -40
- adsGunKickAccel = 500
- adsGunKickSpeedMax = 2000
- adsGunKickSpeedDecay = 30
- adsGunKickStaticDecay = 10
- gunMaxPitch = 5
- gunMaxYaw = 5
- adsViewKickPitchMin = 35
- adsViewKickPitchMax = 50
- adsViewKickYawMin = 20
- adsViewKickYawMax = -20
- adsViewKickCenterSpeed = 1400
Note that there are no ReducedKick parameters; this mechanic did not yet exist in Call of Duty. We will also ignore the effect that its 1.05 degree ADS spread has on its accuracy. Using these parameters, we can produce a simulation of the PPSh-41's Gunkick and Viewkick. Each graph below represents a simulated firing of the PPSh-41. First, the weapon as a whole:
Figure 4.4. The PPSh-41 with both Viewkick and Gunkick (first graph), with Viewkick only (second graph) and with Gunkick only (third graph).
In the graph for Gunkick (third graph in previous image), we can see that the aiming reticule climbs steadily with respect to the center of the viewport. How much of this behavior will be preserved when we change the minimum pitch velocity (adsGunKickPitchMin) to zero?
Figure 4.5. The PPSh-41 unmodified (first graph) and with adsGunKickPitch = 0 (second graph).
The aiming reticule has a much lower vertical perturbation; however, a considerable portion of our shots have landed below the yaw axis, in spite of the minimum pitch velocity being zero. This simulation agrees with the theoretical result we derived earlier concerning velocities and Gunkick: having a non-positive (upward) range of possible pitch velocities can still result in positive (downward) pitch.
It is instructive to demonstrate what effect the Decay variables have on the evolution of the aiming reticule. In the second graph below, the adsGunKickSpeedDecay variable has been raised to 45, and in the third it has been lowered to 15. The unmodified PPSh-41 is also shown for comparison:
Figure 4.6. PPSh-41 plots with modified SpeedDecay variables.
As we might expect, the higher SpeedDecay value helps to dampen the movement of the aiming reticule, whereas the lower one allows the reticule to deviate farther from the origin. The exact opposite effect occurs when we modify the StaticDecay variable: lower values allow the aiming reticule to return to the origin more quickly, whereas higher values hinder it. In the first image, the StaticDecay variable is set to zero and in the second it is increased to 30. The unmodified PPSh-41 is again shown for comparison.
Figure 4.7. The PPSh-41 with modified StaticDecay variables.
How might we be able to compare Accel values with its Viewkick analogue, CenterSpeed? To that end, we modify the PPSh-41 to have an adsGunKickAccel value of 1400, matching its CenterSpeed value, and run our simulation again.
Figure 4.8. The PPSh-41 with its adsGunKickAccel value equal to its adsViewKickCEnterSpeed value (1400).
What is striking about this result is that the Gunkick Kick variables are actually greater in magnitude than their Viewkick counterparts, yet we see a smaller perturbation with Gunkick. But is this due to the presence of the Decay mechanic? We set both decay variables to zero and simulate:
Figure 4.9 Modified PPSh-41 with altered adsGunKickAccel, adsGunKickSpeedDecay and adsGunKickStaticDecay values. Note that the "squarish" shape of the plot on the right is due to the GunKick boundaries (+/- 5 degrees for both yaw and pitch).
But now we might think this behavior to be a result of the higher Kick values. Finally, we modify the Gunkick velocities to match their Viewkick counterparts. In the graph on the right, each Gunkick variable has been set equal to its Viewkick counterpart (or set to zero in the case of the Decay variables):
Figure 4.10. Modified PPSh-41 with the same modified values as the previous test, but with min/max yaw/pitch values to match their Viewkick counterparts.
This serves to warn about comparing the Accel variable to CenterSpeed as though they were two sides of the same coin. Even when these two values are equal, the behavior of the weapon can still vary drastically depending on the presence of Decay and the other differences that exist in the Gunkick model. Even when all the analogous variables are set equal to one another, the difference in behavior between Gunkick and Viewkick is night and day.
[/center]
)
.
