PC [BUG?] Knockback's behavior code analysis

Angela Ranna

Greenhorn
I think I've got why knockback feels so weird (and so bad for daggers) pinned down in the code. In Utility.cs::getAwayFramPlayerTrajectory, the monster's new trajectory base (that gets multiplied by other stuff later on) is started by taking a difference between the monster's vs the player's X and Y coordinates, using those as part of the numerator for each axis. However, because this game has contiguous movement, the monster can occupy the same tile as the player for a not-insignificant distance depending on where exactly you happen to be standing. A hit in this scenario makes the monster's velocity 0, but then they can just keep trying to accelerate towards you over multiple hits until they're stuck on you or have moved past your weapon's hitbox.

On the one hand, it makes a kind of sense for knockback to not work inside a certain range (monster got too close, you're hitting it with the hilt of your weapon), but this tends to feel really bad when playing with daggers. It still can feel bad with swords and hammers too, especially vs fast enemies, as missing catching them on the end of your weapon can make it seem like the monster ignored your knockback or ghosted through the hit.

Some ideas on how to improve this:
-Make a minimum knockback value - if num1 or num2 are 0, set them to 1.
-Inverse the knockback - inspired by GW2's Point Blank Shot. You have to be a little careful with diving by 0, but swapping the numerator and denominator in the return value makes it more rewarding to let the enemies get closer, rather than more punishing. This would definitely make combat much easier though, which may not be desirable.

Of course, this analysis is moot if this function doesn't measure by tiles, but something like pixels. But this analysis matches the behavior, I think, and is consistent with daggers having the "enemy ghosted through my attack" problem so much more often, so it feels like it's worth investigating.
 
Last edited:
Top