So far there are 2 methods to implement an attack hits:
1, check onOverlap between weapon mesh and enemy when attack. This has the potential issue of multiple hitscans in one attack since onOverlap is checked every frame, but it can be solved with some hardcode to allow only one hitscan per enemy per attack.
It has one more extra issue. It cannot detect a hitscan when an attack animation is not a ‘weapon swing’. For example, I slam a hammer to the ground and I want an AOE damage to the surroundings, or the damaged area is actually more related to a VFX instead of the weapon itself.
2, create a separate hitbox (more common implementation for a fighting game) for each attack and check its collision with the enemy. This will increase the workload a lot since you will need to create and adjust the hitbox for each attack.
Also, I found very limited resources regarding the implementation of this method, so I assume there are some severe drawbacks that stop people from using this method.
I am very stuck and look for any good suggestions about how to implement attack hitscan effeiciently and also versatile enough to deal with hitscan that is not binded to weapon mesh.
The way I’ve been doing it is to create 2 sockets on a sword for example, SocketA and socketB, at some point in the attack animation I trace from socket A to socket B. The trace can be a simple line trace or sphere/box trace depending on the size of the weapon.
The problem with tying mechanics like this to animations and other visual assets is that they are inherently non-deterministic, hard to test reliably and behave differently at different framerates. It also makes it difficult to change them later. Animations are evaluated on different threads, so it’s nearly impossible to do this with 100% consistency.
The vast majority of games do not use hitboxes or overlaps queries on the melee weapon to apply damage, instead you usually do carefully tuned collision queries at delayed/specific times, at the same time as playing the animation. For example, when you attack, you play the animation, then 0.2 seconds later you perform a collision query in front of the player and damage anything that overlaps that query. These queries are usually carefully designed but most importantly, they are consistent and controllable.
Animations for the most part should be treated at supplementary to the mechanics of the game, they are a visual element and inherently unreliable, especially as they get more and more complex.
Oh and remember, overlap queries are always faster than overlap events. Extremely so.
Very interesting insight, thanks for writing this. Any specific implementation video about what you meant on performing a collision query? Is it simply tracing with capsule from actor forward vector (with radius and height depends on the animation)?
This sounds like exactly what I am looking for. Do you mind explaining more on how to implement a ‘carefully tuned collision query’? What is the difference between this and a customized hitbox (which is commonly used in a fighting game)?
I would still use a montage notify where the attack should trigger and do some sort of sphere trace where the player is, based on the type of the attack, so by using the player world location instead of a socket.
It could be anything really, a whole set of traces or some overlap queries and traces etc. Whatever it takes to make the desired impact reliable.
My advice personally would just be to not tie it to any specific visual elements, just make it purely mathematical in nature. Just avoid doing things like adding collision boxes or capsules to the visual assets themselves.