Download

Are AnimNotifies reliable? (Combat System)

Hey all, I am considering basing part of my game’s attack system off AnimNotifies. I do not wish for the player’s sword to deal damage the entire time, so I am thinking about having an AnimNotify that turns on damage detection, and another one that turns it off. That way you can set specific points in the attack animation for the sword to deal damage. Is this a bad approach? Are AnimNotifies not that reliable, and better left to cosmetic aspects of the game, such as sound and particle effects? Or would this work fine?

Also, somewhat of a side-question, but if you can answer it that would be great. What is the difference between Branching Point and Queue notifies? I can’t really find this info, and the engine’s description seems kind of vague. Which one would be better for the system described above? I’m considering just reading the source code for each to understand the difference, but if it’s not that difficult an explanation would be great :slight_smile:

Thank you!

Branching Point is more reliable than Queue.

Thanks for the reply! I tested both out and noticed no visible discrepancy; with Queue is there a chance it won’t fire or something along those lines?

Not knowing the overall attack system design using an animnotify seems more like a hack work around. A possible better solution would to add a collision component to the sword that can be turned on and evaluated “on overlap”. Since it only becomes active on overlap it’s by design that it’s not on all the time. Add a physics material to the mix you could even determin how much damage an object receives… like a shield

Thanks for the response, I’m still a bit confused, however. The way I have it done is I made my own frame-independent collision the same way Chivalry did theirs; I have two sockets, base and tip, on the sword mesh, and I get the position of the current frame vs the last frame along those sockets 5 times, leading to something like this:

https://forums.unrealengine.com/filedata/fetch?filedataid=115117&type=thumb

That being the sword’s trajectory after the animation. What I am currently doing is turning that on when the first notify is fired, and turning it off when the second notify is fired. The reason why I am using notifies isn’t for the sake of not having it on all the time, it’s because I don’t want the player to run into an enemy without slashing and if the running animation accidentally moves the sword enough to hit the enemy, it would actually deal damage. I only want damage to be dealt when an attack animation is playing. I agree it seems a bit hacky, that’s the reason I’m posting this :wink:

Well the issues we have with using notifies is they are bound to a given animation asset so if you change the base animations you would also have to add the notifies to the new or any additional animations that are part of the set. In the long run it’s workable but is an X factor is in will it always work when it needs to work? The other side is to make objects that are game critical what is called object aware as in they contain the information necessary to function and behave the way it should upon possession that you can easily apply a level of importance that it must fire each and every time.

Sorry if it’s still confusing but in our case we will have dozens of different weapons, each with their own behaviors, so in our case it’s the weapon that drives the animation and game play and not the character model that might posses the weapon.

So once again not knowing the full design a notify will get the job done but if the player has accesses to a lot more weapons then the migration pathway should come from a weapon BP.

Yeah, having the game logic bound to an asset is obviously an issue. Regardless though, it makes sense to me, since varying animations will have different periods in which they deal damage and do not, so it’s not that big of an issue (in my case). I understand what you mean by object aware, but in this case I’m not sure what alternatives I have other than making the sword deal damage essentially the entire time. I know of some workarounds, but none that will give me as much control over during which part of the animation the weapon deals damage.

Would you mind elaborating a little more on the system you are utilizing? Does the weapon always deal damage on collision? And is it a first person game?

The player does have access to many weapons, but it’s really only melee weapons that use this system. Regardless of whether the melee weapon is a shortsword, longsword, axe, or hammer, the same anim notifies would apply, the only difference would be the animation being played.

Thanks again for the help!

The game I’m working on, with others, is a FPS along the lines of Unreal Tournament but as a Hollywood tactical shooter so if players running walls or on roofs like in the Matrix is fair game as far as design goes.

I did a overview of our weapon design BP in the past.
https://youtube.com/watch?v=K7aoUwIyn5E
Keep in mind it’s in behind the scenes format so it’s a total overview of our design…at the time.

In short form the main animation BP that is applied to all of the players for locomotion is applied as a single animation blueprint to all player models. That’s to say that anything involving the hips down comes from one place for all instances relating to movement. We consider this as being the Locomotion State

The Action State comes from a blueprint, a weapon BP in most cases, which contains the information that is unique as to what the player is current in possession of as per object awareness and what animation actions it needs to preform is passed by this BP as a montage as to use to the 1[SUP]st[/SUP] and 3[SUP]rd[/SUP] person player models as a layer from the spine up.

We have a 3[SUP]rd[/SUP] layer set up to handle lip sync and expressions but that’s a different subject.

You can have a look at the Shooter example which we based our original framework on as to weapons that can be easily added to the inventory but we have expanded the original to included any object as a possible weapon, including a sword, and assign a damage value as a by product of “firing” the weapon.

Doing melee is yet to be implemented but it can be done in full with in the given BP or added as a animation BP which is passed to the player upon position and applies damage if and when it’s needed.
Overall it’s probably a poor name to call it a weapon BP instead of an object awareness BP :wink:

**@paragonx9 **

I initially implemented a similar approach to yours, sweeping the tip and the base on a per frame basis. It worked relatively well, although the sweep shape is framerate dependant.
(Not every frame plays during animation so really fast swings are not optimally swept)

I recently switched over to Ramas melee plugin for sweeping the collision: https://www.unrealengine.com/marketp…-weapon-plugin and am very happy with it.
He does a similar approach, but instead tracing a physics collision body.

I have been using it coupled with the BranchingPoint AnimationNotifies.

As you said, the notifies are needed since you often dont want the weapon tracing always active.

As far as the rationale behind BranchingPoint and Queue - I believe Queue is less costly and more useful for non-critical notifications. BranchingPoint was originally created to select which Montage track would play.

Incidentally, one more really useful thing I encountered was using custom animation notifies.
This enables you to pass parameters to your notify.
So for example, you need a DamageOn notify - but depending on the the animation, you wanted to pass HeavyDamage, or Attack Orientation (Left,Right,Front Back), or whatever.

You dont need seperate DamageOnHeavy and DamageOnLight notifies.

If you use a custom notify, you can add a HeavyDamage? boolean that show up in the properties of the notify while editing the animation.

Thanks for the reply! You are correct, the sweep shape itself is not frame-rate independent, but I’m satisfied with the results even at 5fps, so it’s not really an issue for me. Thanks for the suggestion to use Rama’s plugin though!