Strafe-jumping physics explained

Share this video on

What's Hot

What's New

Top Grossing

Top of the Chart


jale : thousands of hours of q3 and defrag and I now finally understand how SJ works. Now I just need to understand how it works in the context of "half-beat" strafe jumping.

50millANDaSuit : this is what strafe jumping physics should be and this is what should be taught in the first place....not a bunch of losers showing how to move the mouse , that 's freaking ridiculous.

Donpedro901 : I think this is the best demonstration I've seen of this phenomenon so far (the animation is especially nice). However, I believe you could explain some parts a bit more (not everyone is good at math). I know you wanted to keep the original variable names, but "penalty" would describe the role of "currentspeed" better imho. In order to gain the biggest amount of speed, it's desirable to keep "penalty" at the minimum. Since it's equal to the dot product of the current velocity vector and "wishdir", keeping it at the minimum could be done by doing one or more of the following things: - minimizing the length of "vel" <- since our main goal is to go faster in the first place, this would be nonsense - minimizing the length of "wishdir" <- it's a unit vector, so we can't do anything about it - manipulating the angle of the two vectors Tha last option is viable, we can manipulate "wishdir" by changing where our character is pointing and going (the arrow keys). The smallest dot product with this can be achieved if the angle is 180 degrees (at this angle the result will be the smallest and negative, so when it gets subtracted from "RUN_SPEED", it will actually be an addition). However, the direction of "wishdir" matters: this is the vector that will be scaled and added to "vel" at the end. So a degree of 180 is actually bad, even though we kept "penalty" to the lowest, we did so by pointing "wishdir" to the worst possible direction (backward, if you will). This presents a dilemma: to keep "penalty" low, the degree of the two vectors should be as close to 180 as possible (or as big as possible, up to 180 degrees, in other words). But since the direction of "wishdir" also matters (as this is what gets scaled and added to "vel" at the end), it is also desirable to keep "wishdir" pointing the same direction as "vel" as much as possible. But if you do that, the dot product and therefore "penalty" will be big (it's the biggest when the vectors are parallel). There is an optimum of these two factors (which you refer to as the sweet spot) but I don't *truly* understand this aspect, to be honest. Why this optimum depends on the current speed (length of "vel"), is also beyond my comprehension.

Rudolf Arseni Braun : I think you should slow down a little, it was a bit hard to follow *why* the calculations that were made were done in the first place. Why is the correlation between the current vel vector and the wishdir used as a penalty for example? Even some well placed pauses can be very helpful, see 3blue1brown's videos. But don't get me wrong, still enjoyed the video a lot! :)

Chillingworth : Excellent video man. I'm impressed.

chochmah : Thank you!

Aubrey Hesselgren : Excellent work. I did a big tweet thread about this a while back. you did some great visualisations of what's going on.

Nafrayu Miriyu : The 'heatmap' and the visualization that comes after are so awesome!!! Thanks so much for this!

Dancode : very good explanation, thanks!

Angel Alvizu : 19 years later and it's still worth seeing the scientific explanation.

Ruslan Akbashev : What about cpma-style strafejumping and ones from source engine, like CS:S? There you don't hold the +forward and style of moving mouse is different. As I understand, the code is almost same, so that means the difference is only in airacceleration and other variables?

Dag Oldenburg : In q3 or qlive you want to move the mouse as quickly as possible from left to right, but in the counter strike games you wanna have a smooth curve between each interaction with the ground. Do you know why that is? is it because the ability to change direction in the air is much greater in cs compared to quake?

Fabelaz Nyan : OK, now is there a circle strafe explanation? I need to know how to train it. Also, how would this work in quake champions?

Peer Svensson : Good video. One thing you don't mention though is how you accelerate slower along certain axes, because of velocity snapping (a rounding function). It plays quite a big role for harder lanes, like orange2bonus or w3spgaz_strafes blue. If you turn too much too soon by being slightly beyond the optimal angle you'll decrease your acceleration because of this snapping. Also, Quake 1 engine games like CS have slightly different strafe jumping physics, even though the principle is the same.

Electron Dust : Did you use any specific Python package when you put together that neat interactive mathematical representation with the vectors?

maxcgm : strafe jumping physics in a fictional quake universe not in a real world

Jack Valentine : wow, jusr wow. fantastic info there. Been playing Quake 3 since the Dreamcast days and this is one of the best mechanics based explanations I've come across!

Powder Hungry : I'm trying to port Q3A movement to Unreal Gold which was a Pre-Unreal Tournament game released by Epic Mega Games (Epic Games) back in 1998, and I am just wondering if that code alone would do it?

squealpig : First time I have seen this explained properly. ty

Rob Kara : I guess Quake Champions changes the last line to something like: if (vel + wishdir * addspeed) > CHAMPION_MAX_VELOCITY return CHAMPION_MAX_VELOCITY else return vel + wishdir * addspeed !DA

AppleFrogTomatoFace : omg!!!

WebNinja : it is not a bug it's a feature!

Dag Oldenburg : Very interesting, thanks!

Chillingworth : Why is it that in Source games you don't hold W (and have to turn less)?

Kunstkritik : I always wondered what was behind strafe jumping. Won't help me to get good at it but it is still interesting. Cool video!