So I’ve got this fancy swept pill tracing system, right? It’s a whole thing. Spent probably months refining that whole process. Recently I added on an extremely fancy fake-cone tracing system that works on a similar principle!
Which I don’t recommend using, at all! Because while it works great (sort of it has some bugs but whatever), this much simpler system works better.
And it really is simple. Most of that code could be removed, since I’m caching a lot of values that only end up being used once. I left them alone since they were already there, since I modified this from the more complex version, and it’s possible I’ll eventually want them for the score penalty checks. It’s just a dumb cylinder. That’s it. One cylinder and some scoring logic. And we’re out.
Scoring Logic
By the way, if you ever find yourself doing a, This? A cone trace? Usually because you want the “best” target somewhere in front of you to shoot with a pistol or whatever cus you’re doing soft aim assist? If you’re struggling with a conditional that finds the “best” target, but that isn’t influenced by order of processing of possible choices?
Yeah use a scoring system. By which I mean don’t try to pick the best option by some messy compound “if angle less than current best angle AND if distance less than best current distance minus 150” logic. Instead, do something like curScore = (curDistance / 1500) + curAngleDot, and just compare curScore with bestScore. Figuring out scoring logic that prioritizes the features you want is then its own challenge, but no matter how weird it gets, you WON’T create logical gaps that create order-of-processing dependencies on results.
That’s the big goof I made originally building this. Don’t build a conditional that does the IfBetterThanCurrentBest sort of swap-in approach, just write scoring logic, and choose the highest score. Scoring logic won’t have the gaps that crop up in nested conditionals.
Anyways! Getting back to the point,
Simplicity
Cast your mind back to the complex tracing post I linked at the top. Recently I was talking to my designer friend. Essentially the guy who I learned everything I know about combat from. Smart guy! Anyways, he too had built a radically complicated swept-volume tracing system for his combat. Then it got more and more complicated as he tried to fill gaps it.
Then, on a whim, he tried removing it all and replacing it with a stupid, single box. Just a box floating in front of the attacker. If box hit something, do damage. Didn’t even move the box for different attacks.
You know what happened? Playtests instantly started going better, with players complimenting the combat hitboxes. You know who noticed how “off” the hits were in literal terms? Nobody (except him sitting in the back going “surely they can see, wait no? they don’t see that? what?”).
It’s even what Godhand did. A fact I find eternally embarrassing, because Godhand was a primary inspiration! I just, ASSUMED they were doing weapon or fist traces like other games. The most innovation they’re doing beyond “just put a box in front of the attacker” is “sometimes they switch which box they use, like putting a sphere above you for an up-attack”.
I was just, so mad when I saw that. When I thought about the time I wasted. But SUCH IS GAME DEVELOPMENT, haaaa.
Honestly though, it’s possible this won’t apply to your work. Maybe you do want the traces, because you’re making a literal hardcore Souls game and really do want the strikes to be prone to missing or ducked under (though even Souls plays fast and loose with the style of hitboxes they use from attack to attack). Maybe you’re making a true fighting game. No idea!
But seriously. Consider starting with a big dumb box, and only replacing the big dumb box once PLAYTESTING says it isn’t good enough. Always easier to start dumb and get fancier.