The Humble Dot Product

I get asked "so how much math do game developers REALLY need?" a lot, and usually I just shrug and say "linear algebra." But that doesn't help, because a lot of folks don't actually know what that is. As it happens, I hit on a perfect example.

Look at the image (or here - https://pastebin.com/dMbqUqq8 - since Patreon's UI kinda sucks and doesn't allow expanding images). Technically that's just trig, but, linear algebra is, realistically, just an extension of that trig class you took in primary school and probably immediately forgot. A lot of folks bounce off it. Unfortunately, that ends up being the math most important for gamedev. Linear algebra takes that, and glues on some other stuff - like matrices - and reminds you of all those trig identities that you forgot, but surprise, turn out to be super important.

So, let's run down why this works, and what I'm doing here. The end goal is to make it only accept punches done from the front of the target, by something at least somewhat facing them.

First chunk, comparing forward vectors. I want something that's facing me. I get a lot of folks thinking "but it falls through if the dot is negative, don't you WANT the dot product to be positive? That's when the lines are closest to eachother!" and, sure. But think about what I want. I want the case where the two are facing eachother. So I actually want the dotproduct to be negative, since it goes negative when the vectors have an angle greater than 90 degrees between them.

Second chunk, now I'm comparing position. Here, I want to make sure that the thing punching me is in front of me. That's why I'm taking the vector from the thing punching me, to my own position, and dotting that against my OWN forward vector. That's going to filter down to the 180 degree cone in front of me.

I also get folks asking "but this only works in 2D, right?" - I assume because trig doesn't touch 3D. Actually, no, this works fine in 3D too. Dot products work the same regardless of dimensions in use. All I'm doing is filtering to "angles off of the forward vector", I don't care if it's 2D or 3D for that.

Finally, you might then ask "but what if I want a tighter hit-cone, so things can't hit from the side either". You might think you need to do complex angle math for that, but, no, all you really need to do is add a 0.0 to 1.0 scalar and say "the Mathf.Abs() of headingDot must also be less/higher than this", depending on which half you're doing. You CAN derive that number from an angle if you like, and you should if you want to do an artist-friendly UI that shows the precise hitcone necessary, but there's technically no need. Just remember that the values returned from Dot() are actually cos(angle), and that they do NOT vary linearly with angle from 0.0 to 1.0. Which is to say, if you don't do the angle conversion, you'll find your 0.0 to 1.0 scalar value bends a bit toward favoring wide or narrow angles VS what you're probably expecting. Irrelevant if treated as a tweak value, but a big issue if you're trying to draw the specific cone.

... and, finally, you'll see "Twiddle", because what this is actually doing is twiddling a Switch state. Which is what my $3+ patrons got a post about, this month - Switch systems! If that's you, spin around and look at the other post now, and we'll dive into what the heck I'm doing there, and why it's awesome.