I’m trying to make an Enemy-Soldier-NPC.
And while i experimented around (i’m still quite new to unreal), it turns out, it’s not that easy to make a good, effective system.
My first few attemps were not… good. Even with layers and blendspaces, the results are offen hard-to-manage spiderwebs with a ton of variables you have to keep an eye on.
Unfortunally it’s really hard to find fully-fledged examples of an animation system. And tutorials are usually too simple.
So, does anyone know good ressources, of how to create a good, and easy-to-manage structures, even for more complex behavior?
1 Like
The best answer I can give you to this - after over a year of actually doing it - is don’t do it.
Don’t put any code at all in the animgraph.
All the animations, their triggering, etc. It all needs to be handled externally by the character BP.
state changes need to be called by simple variable changes. Booleans, int changes, etc. So that changing a value externally automatically affects the BP.
It’s not easy, but you definitely won’t have any spiderwebs of nodes anymore.
The state machines will get messy. Thats inevitable. Afterall many states need to lead into other states. (Transition rules should also have no code).
For instance, one could be tempted to toss every state in the statemachine into a “death” statemachine.
Dont do that either.
The best way to avoid all of that is to use montages instead.
Any time something has to override everything or almost everything, you can use a montage and get a seme if not better result.
As a general rule of thumb I now keep my graphs very minimal.
A few walk cycles for different weapons when they really, really need it and a montage won’t handle nice enough.
a solid jump/land system
turn in place.
crouch/prone stares.
and that’s about it.
Leg/body IK is really the only thing that may somewhat resemble coding which I pipe in at the end of the list before the output pose.
still, all the actual code of that is ran by the character BP, and only the variable of the effector is passed in at the end, straight from the character BP.
YES YES YES THIS
To add to the conversation an animation blueprint is not an extension of the code base that is needed to drive it it’s a means to trigger the desired state changes within “context” of what the “movement component” is doing in world space and to account for “any” type of state change the necessary data should come from the desired “controller”.
State machines in a next gen game engine are overrated and stuff left in as to 1990 legacy. To get into and out of a state change requires an argument as to entry from one into another and the more state changes you need/add the nosier the animation blueprint gets. Moving into and out of a state change should be determined in the controller before entering animation blueprint and the AnimBP should be “told” what the state needs to be.
Put the required state changes in the controller and tell the animBP what it needs to do. Do that and the animation BP can be used to control any player model you wish, be it an AI,an NPC, your main player models.
Need to make sense of it all avoid using state machines and instead use a tree to switch states. Works the same as a state machine in some way but triggers with out the need for enter/exit statements.
What to look at something check this out.
The selling point is it uses a component that you can add to any controller and converts action states to plain English array that only requires a single cast to the controller for that array.
I’m not sure what you mean by “use a tree to switch states”. Could you elaborate that further?
OK so the animation graph is made up of a migration path of how the state changes needs to occur based on the required context. Most time the start of a animation blueprint is getting the player to move in the desired direction at the correct speed and usually using a running blendspace, which is usually nothing more than a 2D array, and you have something that is very easy to manage and clear in ones mind of how an why it works. This starts to get more complex and harder to keep track of the more you add, as you found out, once you add additional requirements like walk, jump, swim, player cover requirements, melee, riding a horse, a motorcycle, swimming , and much much more, and try to shoe horn everything into a single state machine.
How to avoid the confusion is by using a tree in the migration path base on the “context” of the required state change. A tree is nothing more that a pathway switch, blend on int is a good one, where you switch the path based on what the controller tells the animation blueprint what is it’s current state. It’s based on a simple assumption that the player can only be in one state at any given time and the animation BP can “request” the state change from the controller with out having to keep asking 20 question as to the true and current state.
As a simple example the controller is constantly updating it’s current state, say to a var “current_locomotion” state, so in your tree, if a blend on int, you have a simple input into the trigger by calling the controller “current_locomotion” which can be in plain English or even a token value like 0 for idle, 1 for walk 2 for run 3 for crouching ect. and this will switch to the desired migration pathway.
You could even switch out the animation blueprint in real time so once again make your animation pathways context based as in the ladder example. The ladder project I pointed out is a good example as you can switch to it if the player enters the ladder trigger as you don’t need all the other junk. In theory an animation blueprint does not require an event graph and the requirements are best served by the controller being used to provided the necessary state change request.
Are you 100% positive that changing ABP at runtime doesn’t incur time sensitive limitations?
On entering / exiting a ladder you have a slac of time (approx more than a second) in which you usually have to play an animation to align the character to the ladder.
That time slac can be (and is probably why) used to load in just about anything.
What happens if you replace the abp between run and walk states?
Fairly certain you hit visible time snags - never tried it before.
Interesting concept but it also defeats the purpose of allowing everyone/everything to use the same abp.
And I’m not sure it serves the purpose if loading time is an issue. Even with fast path working, as it would be a lot easier to do on limited content.
It would probably be better to just run with Nested State Machines to keep down on the clutter.
Well yeah in most cases switching the migration path base on the context makes it easier to get into and out of a a fix state. As an example though our animations are weapon based so depending on the weapon in the players position it will use the action state montages contained with in the weapons BP. One of the weapons though happens to be no weapon so when when that is selected as an option as part of the weapon load out the animation BP is switched out to a free run version which is far to complex as to the required full body movement.
Yes the player pops when in the idle state but sync groups does a good job with the rest of the stuff as far as locomotion goes.
Thinking about it though the weapon BP could be used to pre-stage the switch by blending into the new idle state.