Today we are going to continue evolving our props, this time by introducing physical components.
Physical components allow us to create things like punching bags, springs, various pivot points as well as hanging our player from the ceiling in various sadistic ways. How fun !
In addition to that we are going to throw in some addition attack modifiers so we can easily switch between light, medium and strong attacks.
This week we continue on with fundamentals, this time going over how to override UAnimInstance in order to have more control and tighter C++ integration with our other classes.
We looked at UAnimInstance before, have you gone senile !
Last time we looked at UAnimInstance was in the context of using it to access montage controls to give us finer control over our animation playback. This time we are going to move the Event Graph definition from a blue print driven anim instance and migrate all that functionality into our own C++ class.
Why bother rolling our own ? Blueprints are easy !
We can certainly use blueprints for all this work but having low level c++ access gives us a lot of control over our animation settings.
For example if you want to extend your animation system to support Inverse Kinematics, it becomes much simpler to compress that logic via convenient c++ method definitions rather than having to draw out a spaghetti bowl full of blue print nodes that make it hard to debug and troubleshoot.
Let’s take a look at some of the methods involved in this process.
As you can see from our code, there is really not much to it.
Outside of overriding the methods you want to take control of the rest comes down how much or how little animation data you want to expose to the blueprint.
The only real major point of complication is to ensure that the pawn attached to this animation instance is correctly cast before you get at it’s details.
With your own anim instance you can now start compartmentalizing your complicated logic, handle various player types against different blend space behaviors and generally modify your animation to suit your game.
Today we are finally back with the Player Character series , picking up where we left off, as well as incorporating all the previous tutorials into this lesson.
This time we are going to do a review lesson, where we go back over all the topics we covered earlier, and use them to implement a new set of attacks in the form of kicks.
Today we are going to continue exploring Unreal Engine C++ Fundamentals before we get back to our Player Character series by taking a look at Anim Notify and Anim Notify States.
An Anim Notification or a UAnimNotifyis a way of assigning events to parts of our animation that will be triggered at specific times of the animation playback. UAnimNotifiesreally only have one notification event. It either fires or it doesn’t.
Why do I care ?
Well most games have various animations and each animation may trigger different effects depending on it’s life cycle.
For example if we want to play back a noise that a weapon makes as our character slices it through the air we may want to use an UAnimNotifyto trigger this event and then we can tie that event to the playback of our wooooshing sound.
We can also use notification events to trigger special effects, events in the game, UI updates, whatever you can imagine you can tie into this execution.
Ok smart guy what about Anim Notify States ?
Anim Notify States or UAnimNotifyStateare almost identical to our Anim Notifies except for one difference and that is that Anim Notify States come with three events:
NotifyBegin
This even is fired once when the notification is first triggered.
NotifyTick
This event fires continuously every tick, during the execution of an UAnimNotifyState.
NotifyEnd
This even fires once at the end of the UAnimNotifyStateexecution.
Alright so we have these magical events, how do we code them ?
First let’s take a look at a UAnimNotify
// HEADER
UCLASS()
class UE4FUNDAMENTALS03_API UPunchThrowAnimNotify : public UAnimNotify
{
GENERATED_BODY()
public:
virtual void Notify(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation) override;
};
// SOURCE CPP
void UPunchThrowAnimNotify::Notify(USkeletalMeshComponent* MeshComp, UAnimSequenceBase* Animation)
{
// print method name to screen
GEngine->AddOnScreenDebugMessage(-1, 4.5f, FColor::Purple, __FUNCTION__);
}
So, as you can see, by inheriting from UAnimNotifywe are able to overwrite the “Notify” method and then print some stuff to the screen.
Pretty easy.
Cool ! Now show me how to tie those events into my game.
Well the majority of that is covered in the video but if you are curious this is what the events look like when you add them to the animations.
The way we added these notifications was by going to the bottom part of the animation montage labeled “Notifications”.
Then by Right Clicking we were able to pick our notifications.
This was all done from the Melee animation montage.
POINT OF NOTE:
UAnimNotifyand UAnimNotifyStatescan be added to single animations as well as animation montages. Which gives you a lot of freedom as to where and how you want these events to be triggered.
So there we go guys, with just a few lines of code and a bit of clicking we have notifications coming out of our animations and into our game.
If you would like to learn a little bit more about these various topics, check out the following links:
Today we are going to pick up where we left off last time with our Player Character and we are going to introduce collisions.
Now to get our collisions working we are going to jump into a few topics like:
Mesh Sockets – 1:45 – these sockets will allow us to attach our Box Components to parts of our fists during the firing of our animations
Box Components – 6:25 – these small collision boxes will allow us to apply specific collision profiles at run-time in order to trigger the interaction with our target
Animation Notify States – 31:15 – these are notifications that will fire during the course of our animation playback and trigger specific events on our player character. In our case we are simply going to enable the collisions on our collision boxes.
As usual we have our starter project on GitHub as well as the final version for you to try out. Additionally here are a few links to do some further reading on the items we discussed.