Black Ops Recoil Plots + MW3, COD4 links

[jesterv01]

Ok - revised code, suggested guns. I think it's centering properly now. Still not happy with how the model is dealing with ROF. Compare the fudge / no fudge graphs. What's people's gut feel for RF - does it increase the recoil of guns? I think it does. If it does how does that square with the ingame recoil of the M60 being so much larger than the simulations suggest?
Code
dl.dropbox.com/u/710852/New2/guntest.m

Viewkick ROF fudge


Viewkick without fudge

[jesterv01]

Interestingly the COD wiki site callofduty.wikia.com/wiki/Call_of_Duty_game_engine_mechanics says that a high ROF weapon will have less recoil that the same low ROF weapon. It then contradicts itself by saying the double tap will increase the recoil.... The only way I can really think to test this is either to a lot of tests with a Spectre RF/no RF or (even better) could somebody with the PC version of the game mod their copy (or COD4 - I bet the mechanics haven't changed) to create two identical guns, one really slow, the other really fast, and post the results.

[mannon]

I think the bit about high ROF weapon having less recoil is talking about comparing different weapons as they are in the game, not the same weapon with the ROF altered. For example comparing the MP5K to the Vector in MW2. The vector has less recoil even though it has a higher rate of fire because it has such low damage.

But I dunno... I can't be arsed to deal with the wiki, it's often wrong about things. ;p And damage being equal between weapons usually they balance them the other way, and the one with the higher ROF has more recoil. *shrug*

BTW how many shots in the burst are you simulating? It should actually make quite a bit of difference if you're simulating a million 5 shot bursts vs a million (or half million so same shots) 10 shot bursts.

Guess I could dig through the code, but since I can't run it I don't really want to learn matlab code. ;p I be lazy.

[jesterv01]

The simulation is doing 100K 10 round bursts (the kind of wild, uncontrolled burst I seem to find myself using..) so 1 million shots in total.

[jesterv01]

Nailed it (I think). On closer examination (Dragauov and M60 with ACOG) it's clear the gun is kicked in a particular direction with a particular angular velocity and then decelerates before stopping and accelerating back towards the aim point where it stops instantly. (Sorry if this was obvious to everyone else). This suggest that a suitable model for the x and y motion would be t*kick + k*cs*t*t. From Den's observations we know that k = 0.2.

I coded this up (see here: dl.dropbox.com/u/710852/new3/guntest.m ) and it works! See here:



The RF attachment makes the recoil a bit bigger and gives it significantly different shape - in line with my observations. The ACOG makes it a lot bigger and the M60 really does spatter bullets all over the shop - the 98% contour has at least three times the area of the regular Spectre. Intrigingly the RF and ACOG Spectre have significant hit zones off the initial aim point - I wonder if this is why I always seem to do well with an ACOGed Spectre even though on paper it should be rubbish?

Cool... any requests?

[phale]

So we can conclude that increasing rate of fire/decreasing centerspeed will cause a tighter spread with long bursts but more of a kick away from the center point... right?

Interesting... seems very counter-intuitive, as when you add Rapid Fire or ACOG you would think that shorter controlled bursts are necessary.

[jesterv01]

I think it's an interesting example of the limitations of the approximations only being visible after a huge number of trials (the simulation now fires 10M shots in 10 rnd bursts). It's the 'block' behaviour and the sharp horizontal and vertical lines that are interestesting to me - both properties of the approximate bits of the model (stopping dead on the center lines and treating the x and y axis seperately) The local maximas in the top right quadrent are kind of cool too. They do suggest why I do fairly well with the ACOG or IR sight with full auto fire providing I remember to correct down left after starting to shoot.

[mannon]

Increasing ROF could certainly have the effect of causing a tighter spread. I don't see how reducing centerspeed could do that, however. Reducing centerspeed could result in a larger, but more predictable spread, however.

BTW nice charting here. The off center vertical and horizontal features might seem a little surprising, but I think they make sense considering each axis is independent. That means that the 2 dimensional map is really just a result of the 1 dimensional X and Y axis probabilities multiplied by each other in a matrix. That means that any strong features in the 1 dimensional map of one axis will show up as a prominent feature perpendicular to the axis as it gets repeated over and over in each row or column.

I hadn't expected quite as much boxiness... But it actually makes a good deal of sense. At a guess the boxes are related to the size of the maximum second shot kick. Basically the boxes are the direct result of the phenomenon of the weapon recentering. Each time the weapon recenters the next shot (after the recentered one) has exactly the same probabilities as the second shot. So the mapping gives you a lot of random shots all over within the weapon's theoretical maximum kick (within a 10 round burst) but layered on top of that are also tons of 2nd shots.

Well, to be fair, we are somewhat self selecting for them because you're firing 100k 10 round bursts. That means that you can guarantee that at least 100,000 rounds landed dead center since they were the first shot (unless you're skipping those), and on top of that we also have 100,000 guaranteed "2nd shots" that represent recoil from the center. On top of that the gun will occasionally recenter anyway which produces the central cross feature, and after every single recenter is another "2nd shot" which just goes to reinforce the 2nd shot box.

What's nice to see represented in the graph is something I knew had to be true as long as centerspeed was not a flat velocity (which it isn't)... The probability within the 2nd shot box is not flat either. Due to the complexities of the deceleration and acceleration back to center and the interaction with ROF and the actual size of vkick it simply couldn't be flat, but it's a bit too complex to give a blanket statement of what the probability curve within the box would look like.

But now we can see it, at least for a few weapons and attachments. The Spectre in particular favors the top right corner of it's box while the M60 favors the top middle.

BTW you can also clearly see the shall we call them shadows of the box that continue vertically and horizontally beyond the borders of the box it-self. This too is pretty much what should be expected because the axes are independent. That means a recentering can happen in one axis but not the other, thus producing a box shadowing half 2nd shot.

There is one thing about this, though. The 2nd shot boxes and shadows are so prominent that they are considerably overshadowing most other features. I hadn't quite expected that, but in retrospect I probably should have. I am curious what the graph would look like for just the last 8 shots of the 10 round bursts, ignoring the 1st and 2nd shots. You would still get a recenter cross and 2nd shot box and shadows due to recentered shots and the shots following them, but it would be interesting to see without it being weighted so heavily by the guaranteed 1st and 2nd shots. Though I guess it would really only be relevant from a standpoint of examining the weapon under sustained fire or in the case that the first two shots missed. It could be educational, though

Speaking of educational it is clear from these charts that optimal recoil compensation can be learned as a purely input driven skill. What I mean by this is you don't need to react to each viewkick from the gun and try to constantly put it on target manually. If you know the recoil of your weapon it is clear that you can compensate by moving your aim a set number of degrees in each axis to put the highest probability part of the box features over your target. For the Spectre this appears to mean simply aiming down and too the left as you fire, but then holding your aim the set amount off target and allowing the kick to average out over your intended target.

Note: We do not know that all weapons will favor the corner or top of their box so prominently. Pretty close to all weapons should exhibit a box like feature, but some may actually favor the corner closest to center... maybe. I'm uncertain if this top and top right (left for left kicking weapons) is really a universal feature or not.

That's not to say one should always go for the corner. That's a bit harder to say. When firing a smaller burst it might be better to use the recenter L lines to achieve higher probabilities vs the corner, but this will vary with weapon and attachment choice, burst length, hits to kill, and distance to target, so it's a pretty complex analysis in its own right. For sustained fire I would think the corner or top middle of the box has the best odds, though. What I find interesting is that this corner for weapons that favor one side could actually be more reliable than the top middle of the box for weapons that kick up but evenly on the left and right.

I usually don't like weapons that kick more to one side than the other, preferring to only have to adjust for recoil in one axis. But a skilled player could definitely use this to their advantage.

Of course the real trick is once you start firing you have to sort of guess where your actual center point is since you won't be able to tell until you stop firing again. If you manage to get the sights to bounce around mostly on target then you're doing it right. My problem has always been that I have difficulty taking observing the average placement of shots during recoil instead of looking at them more individually. Because of that I am usually overcompensating as I'm trying to play catchup and react to each shot fired instead of dutifully putting the center point in the right place and only adjusting it when I go too far off and start bouncing around an average location not close to target. That could work with an extremely slow ROF, but genearlly ROF is way too fast for reaction time... heh

tl;dr I liek yur charts man, kool... 'n stuff.

[psijaka]

Mar 24, 2011 15:32:19 GMT -5 jesterv01 said:

Nailed it (I think). On closer examination (Dragauov and M60 with ACOG) it's clear the gun is kicked in a particular direction with a particular angular velocity and then decelerates before stopping and accelerating back towards the aim point where it stops instantly. (Sorry if this was obvious to everyone else). This suggest that a suitable model for the x and y motion would be t*kick + k*cs*t*t. From Den's observations we know that k = 0.2.

Spot on. jester; your latest charts look very convincing and are also very pretty!

The consensus seems to be that the Viewkick=velocity|Centerspeed=acceleration model you describe is correct, and I think that your modelling adds strength to this.

Have you read asasa's "How exactly does centerspeed work?" thread? There has been a lot of discussion on this subject there.

I am fascinated by the "blockiness" of your plots; something my simple scatter plots do not show up at all. I will have to a think about what is going on here; although I think I see.......

Look like I have a lot of work to do in re doing my 100 three and ten round burst plots, as these are currently based upon modelling viewkick as a displacement and centerspeed as a velocity. Will do this within the next few days.

[jesterv01]

Now the simulation is working right replotting the output is easy.
This the FAMAS data split into shots - shot 1 is dead on, so I've missed that one out.

- it's important to note that although the x motion and y motion are independant they are not uncorrelated - you can't just calculate a histogram for x motion, a histogram for y motion and then multiply them together to get the image.

I think I'll investigate three round bursts next

script : dl.dropbox.com/u/710852/new3/guntest2.m

[psijaka]

fascinating....

[mannon]

Mar 25, 2011 4:16:19 GMT -5 jesterv01 said:

- it's important to note that although the x motion and y motion are independant they are not uncorrelated - you can't just calculate a histogram for x motion, a histogram for y motion and then multiply them together to get the image.

Actually... um... why not? The view kicks right or left, recenters or doesn't, kicks again, recenters or not again, ect... all completely independently of what it's doing up and down. I don't really see any correlation other than when it comes down to putting a bullet in a 2D position on the map, which isn't really correlation. As near as I can tell there's no 2 dimensional math involved. Just 1 dimensional math done twice.

[jesterv01]

Heh, that's what I thought... way hey I thought I can speed up the sims no end... and then I noticed the results were different. So I thought a bit harder and then kicked myself ;D

Two things to think about.

Consider the two 2D arrays - imagine they're the kick images
1, 1, 1
1, 2, 1
1, 1, 1

0, 1, 2
1, 2, 1
2, 1, 0

The x-motion histogram is generated by adding up the columns. You get 3,4,3 in both cases. The y motion histogram comes from adding up the rows - also 3 4 3. So you can imagine multiple images that give you the same x and y histograms - hence the histograms aren't enough to uniquely generate an image - one x and one y histogram can give you many different images.

The x and y are correlated because the distributions for the x and y both depend on the shot number - the 10th shot is different to the second. If you treat the x and y seperately and then combine them you've lost that information, which is why the image is wrong. You are combining x movements for the 2nd shot with y movements from the 10th.

If you don't believe me - try it!

[mannon]

OH! Yeah okay that makes perfect sense. Yes you cannot mix the X histogram of one shot of the burst the the Y histogram of another shot in the burst, that would indeed be very bad.

Yeah I totally see your point there. I was still thinking in terms of any individual shot, but when you're aggregating a bunch of shots in a burst together then it certainly does make a difference.

But for any individual shot you should be able to simply calculate the X and Y histograms and multiply them.

Hmm... Since each next shot needs a starting point I don't think it would really be very effective to try to use histograms given this is a simulation. It would work great for doing purely a 2nd shot simulation, but gets more problematic after that. The only way you could really use histograms to speed this up would be if you could take a histogram as an input for the likelihood of starting positions, and then build the next shot off of that with the bias already built in. Though don't ask me how to do the math on that. heh Given the way your simulation is running I guess you could use the previous 2d map as a base. To preserve the bias from the previous shot you should either give the kick a random starting position and use the previous 2D map to weight the results or use the 2D map to generate your starting positions based on probabilities of starting from said positions.

Of course to do it that way you would have to build new histograms and a new 2D probability map for every shot in the burst and then use the new map as an input for the next shot in the burst in an iterative process. It might cut down the number of simulated shots fired, but still be slower. heh

[mannon]

Actually you wouldn't have to use a 2D map. You could keep everything 1 dimensional and only combine the histograms after the fact.

In other words build a simulation that only simulates 1 axis. It should be able to start from center or accept a histogram as input for starting position and then use one of the two methods I mentioned to generate the probable kick results of that shot. Save that histogram and use as input for the next shot, and so forth. When get to the last shot in the burst just have it start over with new perameters for the other axis and do it all again. After that you should have 18 histograms, 2 for each of the 9 shots after the first. You can then build the probability maps for shots 2 through 10 from the individual histograms and layer the 2D maps on top of each other for the final 10 shot burst pattern. (Don't forget to add the 100% probability centered first shot back in.) That all sounds like a pain in the arse to program compared to simply running a larger number of simulations. No real reason not to just use brute force I guess, especially considering rebuilding it in a more complex way might introduce bugs, though it would be possible.

Interestingly the final map it-self doesn't even quite tell the whole story. Consider for example that center spot. Well we know we have a 100% chance to land a single bullet on that spot. This should not result in that point maxing out the probability map for a 10 shot burst, however. Keep in mind we're firing 10 bullets so that means 10x. Yes we have a 100% chance of landing one shot exactly in the middle, but we also have decent odds of having other shots land there as well. In order to capture all possible probabilities we would have to allow the probability scale to range from 0 to 1,000% (if we're using %, really I'd just keep it 0 to 10).

Consider what we're doing here. We are measuring where certain bullets in a burst of gunfire go over many many many many times doing it. In other words we are taking that bullet hitscan that has no width and giving it width, but the wider we smear it the "thinner" its probability gets. A perfectly accurate weapon could stack all 10 bullets on exactly the same point. Of course none of them are, but that's beside the point.

I'm not commenting on the probability scale of these charts. I don't really know how that's worked out. I haven't looked into it.

The point is that an even reasonably accurate weapon actually will be able to stack several shots on exactly the same point or line, even within the very same 10 shot burst, though generally only recenterings will make it happen quite that often. So back to our center point. We started at 100% odds of getting one bullet there, but then each of the next nine shots has some chance of landing there as well. So we stack those on top of it again and again and what we end up with is an aggregate or rather the probability multiplied by the fraction of the burst that might land on that point.

In other words the value of any point on the final map can be increased by either a higher probability of one or a few shots of the burst landing there or by a larger fraction of the entire burst (more shots) having some probability of landing there. Hence why it doesn't quite tell the entire story. Though the distinction may be a subtle one.

BTW I'm curious about what point in a burst different weapons may actually exceed the center probability. For weapons with balanced kick in all directions the answer would be never, but a lot of weapons have very unbalanced kick and after a certain number of shots have almost no hope of making it back to center. I'm curious about both which is the first shot more likely to land away from center than on it, as well as how many shots it takes to overcome the original bias towards center. Of course this would vary with every weapon.

[jesterv01]

There are essentially two-ish ways to make the shot distribution array (the 2d array from which the plots are calculated). The first is the way I do it now - calculate a massive array of shot positions. For a ten round burst 10% of these will be exactly at (0,0). The other 90% will have some distribution. This array can then be binned into a 2D array for visualisation.

Alternatively you could regard this a 2D problem, equivalent to repeated blurring. Now all you need to do is work out the distribution in 2D of one random shot (which you can do from the 1D motion in x and y) and then just keep on convolving it with itself for every round in the burst. Basically like taking a bitmap with a simple black pixel in the middle and then repeatedly blurring it (through with an asymetric blur filter). The problem with this approach is that the centering won't allow the gun to overcorrect so the possible motion of the gun depends on where it was when it fired. This means the 'blur filter' changes depending on the location being blurred... so it's hard. I think I'll stick with the simple method.

DIdn't explain that well.. sorry tired.

Understanding the probablilty plots is simpler. If you look at the ones with contours on you'll see a line labled 98. That line is the boundry of the region that contains 98% of the hits. Likewise the 70% line and so on. 10% or more of the shots always end up in the (0,0) bin.

[mannon]

Yeah I had previously considered using a graphics editor and using something like a gaussian blur or dilate and erode filters, back before the centerspeed thread. But it felt like a bit too much of a kludge, and it would really only work with a displacement model. In the velocity model centerspeed is working against the kick as soon as it starts, not after it reaches the apex. You could still potentially do that, but you'd have to blur weighted towards center in the right way, and even then it feels like more of an approximation.

Just seems better to do it purely mathmatically. (Not that graphics filters aren't in and of themselves mathmatical...)

[asasa]

So.... have you decided whether or not recoil is a velocity and centerspeed is an acceleration?

From my testing displacement and velocity seem to make much more sense; esp in MW2 - unfortunately, without the full weapon stats, you can't be sure that nothing has changed besides firerate from RF.

If it were velocity and acceleration, wouldnt burst firing be relatively ineffective? Wouldnt RF weapons have less recoil than the non-RF counterparts? [Less time firing = less time for the recoil to deviate from the centerpoint = less per shot recoil, no?]

The Famas does seem to have more recoil than the Enfield, and the Spectre RF does seem to have more recoil than the Spectre.


I know somewhere above someone may have said it but that's all so confusing.

[jesterv01]

It's definately velocity and acceleration. Try a Draganouv - on firing it kicks fast in a direction, slows down and then accelerates back towards the centre, stopping as soon as it gets there. The model also gets the effect of RF right as well. The displacement in the x or y direction some time t (in seconds) after the shot is given by t*kick + k*cs*t*t where k =0.2

Haven't tested MW2, but I bet its the same, try some big ol' sniper rifle and see.

[psijaka]

Mar 29, 2011 9:09:05 GMT -5 jesterv01 said:

It's definately velocity and acceleration. Try a Draganouv - on firing it kicks fast in a direction, slows down and then accelerates back towards the centre, stopping as soon as it gets there. The model also gets the effect of RF right as well. The displacement in the x or y direction some time t (in seconds) after the shot is given by t*kick + k*cs*t*t where k =0.2

Haven't tested MW2, but I bet its the same, try some big ol' sniper rifle and see.

Agreed. It took me a long while to come to terms with this, but it can be no other way.

[psijaka]

Have updated the recoil chart and plots based upon calculations assuming that viewkick is velocity, and centerspeed acceleration applied to return the gun to it's aim point, and that crossing the axes cannot occur between rounds.

This last point has a major impact on guns with more random recoil (Aug, AK47 etc); the 3rd and 4th shots are much more likely to be on target than the 2nd shot. Guns with strongly biased recoil (Famas, Spectre etc) are largely unaffected.

[n1gh7]

3 things.
In your method description you say 10,000 3 burst shots instead of 4 burst shots.
Are the selected plots updated to the current viewkick model? (edit-- you said you did, nevermind.)
You have an extra color tag next to your "Method" header.

[psijaka]

May 11, 2011 21:49:17 GMT -5 n1gh7 said:

3 things.
In your method description you say 10,000 3 burst shots instead of 4 burst shots.
Are the selected plots updated to the current viewkick model? (edit-- you said you did, nevermind.)
You have an extra color tag next to your "Method" header.

Thanks for the feedback. In reply:

Even though I calculate the proportion of 4th shots that take place when the gun has fullt recovered from the 3rd shot (on target), I do not actually need to fire this 4th shot; only to know where the gun is when it would be fired. So 10000 three round bursts is correct.

In the same way, I only need to simulate 2 shots to know where the 3rd shot will go for an M16/G11 burst. Or for any gun when firing a 3 round burst, for that matter.

Have corrected the stray color tag.

[n1gh7]

Well, to the more common reader (<-- me) it "makes more sense." You are calculating where the last shot will be, which would be the fourth shot. On the plots can you put dots for the fourth shot as well?

[psijaka]

n1gh7

I will do a few 4 shot plots, and will post as a separate reply, but am not intending to change the OP plots, as I think a 3 round burst is more typical of what would be fired when accurate burst firing. And the M16 & G11 fire 3 shot bursts, of course.

Are there any particular guns you would like me to simulate with 4 shots?

[n1gh7]

Just the AUG and FAMAS please.

[psijaka]

May 13, 2011 21:25:22 GMT -5 n1gh7 said:

Just the AUG and FAMAS please.

Finally got around to simulating 100 four round bursts; here they are:


The same shape as the 3 round burst plots; only slightly more spread.

[n1gh7]

Thanks!

[asasa]

hey psijaka, would you mind posting one of the galil/enfield as well?

thanks.

[psijaka]

Jun 18, 2011 16:06:08 GMT -5 asasa said:

hey psijaka, would you mind posting one of the galil/enfield as well?

thanks.

Thats all the full auto ARs simulated with 4 round bursts.