Specifically I am working on a combo-system. The package I am using had a system built in a state machine that worked GREAT, basically typing the step/position in the string and a given input to move from node to node. Very simple, would work great for a fighting game, or where each player/character would have the entirety of their combo-system laid out as a big state machine.
HOWEVER, my project is more rpg-ish where combo-trees would be tied to a weapon. From what I can determine, it’s not possible to hot-load a state-machine, is it? Is there another way to programmatically define/swap/etc poses or a state-machine so that I could effectively swap out weapons and their associated animation-sets?
For now, I’ve got it working really well actually inside the player-BP so I wouldn’t be put out, but it would reduce complexity and eliminate the need to create an editor widget to edit trees (doable, but ugh) if I could do this in the animation BP.
Don’t even bother with state machines or you’ll hit all sorts of roadblocks.
start with, and stick to montages.
First, create a class for the weapon.
within the BP create events for the different combos. Actually before doing that, create a blueprintninterface and define the attack types within it, so that you can have a “standard” going.
Hook up the BPI and implement its functions as custom events.
Within the custom. Events, drag in montages and set them up to play as you need.
tie effects and windows for counters directly to game time - not notifies, as they aren’t accurate enough for combos.
Parametrier the montages by dragging the montage pin out, and creating a variable.
parametrize the mesh as well and setup a swap on the construction script for it, and whatever else may be relevant (collision, attachment points etc.)
Expose all those values so you can create different instances of different weapons and fine tune them with minimal work.
And/or create different instances with different values.
Thats basically it.
By convention, the montages can be shared across all the character’s with the same skeleton.
When a new character grabs the weapon and his skeleton is different than what the montage calls for, you should create a process to replace/inject the appropriate montage for the skeleton.
Its fairly simple to do, and you can probably leverage the same function you use to do weapon attachment.
All the stuff you described has been implemented. Even better than I was actually expecting as one can totally vary inputs and jank-ify a combo-string. I got it working to my liking, so the question was for sake of knowledge. I’m able to make a custom equip bp that you can specify the skeletal mesh (per your advice once upon a time), as well as related stats and associated montages. These all travel with the weapon so as a person equips different things, I’d be able to tie custom combo-trees per item.
State-machine-wise I was hoping you could define them separately somehow and dynamically attach then to the tree at runtime, but that doesn’t seem possible.
I’ll try and get a (first) video up.
As noted, the way the state machine was implemented would be ideal for a tekken/soul-calibre/fighter-type dealy, with each character having something very specific as far as animations and input-pairings. So if I ever made one (fighter), I don’t see the downside?
It’s not that it’s hard or anything, it’s just more prone to errors.
You can directly swap out the whole ABP to one that only includes the combat states for the weapon - when the attack begins.
that way it’s simple to isolate issues.
The problems you get, come from having to go back to the original ABP to handle getting hit or going back to “normal” states.
Well, if it’s a question of swapping out the BP’s and that is performant enough, that might work, I can explore.
Ideally, I’d just substitute the ‘attack-state-tree’ node I have in the master-state-tree; to confirm, there’s no way to swap out a specific (sub) state machine?
They did come up with a sub anim graph thing though for post process animation blueprints.
It’s mostly not documented stuff (as per almost usual in the past 2 years), but it could maybe be potentially be leveraged to do what you want…
Swapping the ABP is more performant than I expected really. Only found out about it recently, and usually I still prefer montages unless its a very specific situation.
The issue is always the fact that in a normal “dynamic” character you loose all the base line “dynamic” stuff you built for ages and just kinda expect to be present when you swap.
Oh you want to receive damage? WELL I DONT KNOW WHAT THAT MEANS IM NOT THAT ANIMATION BLUEPRINT!
Well ok, it’a not even close to all caps.
it isn’t an error thrown, it’s just that absolutely nothing happens. And that’s kinda my issue with it.
you forget and you scratch your head about why stuff isn’t happening for a bit.
I can take the sub-state-machine for ‘attacks’ which is pretty-well self-contained (I’ve already been able to seamlessly splice in my custom combo system by removing JUST that sub-state-machine) and then at runtime basically splice that same sub-state-machine back in for the duration of the combo?
From the way this is all written, it’d be very easy to do so. And getting hit, for this setup would be easy enough to transition back to the other BP for the getting hit, etc. As soon as the character-blueprint picks up on getting hit, I can have it control swapping the anim-bp back to the original which controls everything BUT attacks, and already has getting hit, falling, etc worked out.
FWIW I am using the Amplify Animation Pack. I originally purchased it just for the animations as they had the entire set of ‘dude walking, climbing, swimming, etc around a 3d-space’ fleshed out; all the stuff for getting onto, climbing up and off a ladder, opening a door, pushing something, etc, etc. HOWEVER, they also have the trace-work and the like set up in a very lean manner, and it’s very objectified in the sense modifying a part is easy to do. I’ve been able to extend it quite well to my own needs and it’s only this combo-problem that has been holding me back (currently).
It SOUNDS like I might be able to revert back to a sub-state-machine per-weapon. I’ll update this thread if I get it to work.
However, another question: there is no way to programmatically define/build a state-machine at runtime, is there? If I wanted to edit the progression of a given combo in the game I can do that with my current implementation, but with the state-machine I’m 99.9% sure this is NOT possible?
Yeah it’s something I want more flexibility from vs convenience to edit.
I see where I could make a specific state-machine for each weapon (or weapon-type) but since I cannot edit at runtime, I’d be in a bit of a corner not having the flexibility I want. Coming from a StreetFighter/VirtuaFighter/Tekken type background so I do want my combat to be somewhat deep and definable.
For what I have right now, I can define combo-strings, multi-button-presses, charge-attacks, and anything else I had as a requirement. Looking at an attack-fake/pump-fake, and best of all, I cannot seem to break it… Gonna keep what I have even thought it’s a bit kludgy.
I have not really touched a real fighting game since 2001. However.
sounds like you have the right idea.
buffer the buttons, figure out what move to play.
que it up however you think best.
If it was me doing it today, I’d make a reusable component that expands the play montage system.
feed in your own values to it to control a multitude of things while the montage is playing.
Can you get hit? how much will you get pushed back if you got hit in this move? What animation will you play? What if the counter was pressed? Etc.etc.etc.
can you combo? What’s coming next so far so we can blend?? Was the move canceled (which is what you are trying to do?) Etc… again
Having a “default” like that will prevent character from not having similar behavior which basically makes fighting games a little more fare for players.
This in turn also enables the AI to super cheat and bash the player’s head in with almost 0 effort coding it on our part…
Check the player variables.
Is the timer here set to be between a range? good. Strike the player. Chain up a perfect 10 move combo.
done.
What I was maybe not explaining right is that you register custom events to be active and allow for things.
So my current implementation is actually simpler than I thought to use.
The animation pack does a good job of objectifying things so anything in the attack-related state has a state of ‘attack’ (go figure…lol). I just trimmed that entire tree and left a dead node to sit there and soak up state-related input and implemented a montage system for the combo-setup. Everything ‘else’ still works, even was able to get dodge/rolling to work early out of a completing attack montage (end of a string) such that the anim-bp takes over like the roll is part of the combo; if you do nothing the attack animation takes longer to reset, but a roll-as-a-combo lets you roll out a little quick (ala dark-souls).
It mostly uses animation notifies to open/close various windows on input(s) on the attack animations and plays a buffered attack. Much like you described.
Is there a way to blend between state machine like Unreal does between montages?
I took a copy of my base Anim_BP, swapped out a couple of the idle poses for same w/weapon. Swaps out fine in code at runtime, instantly like you suggested (performant). However, it seems to reset each time I step into a new instance so either snaps into the new pose instantly or if i am moving, kind of ‘reset’ so even though it’s the same movement animations, it skips back to frame 0 and animates from there.
Yes you can by placing your state machine in a tree structure switched on int for example. You can then change the weight as to how the blend should occur.
Can you dynamically change the animation BP?
Yes you can you can but you will need to reset the local vars. This is usually set with the “Event Blueprint Begin Play” which is preformed once when the animation BP is first ran as to requirements for that BP that does not need to cycle through.
To reset each time you switch the animation BP you need to preform a “Event Blueprint Initialize Animation” so that the “Set” vars are set up.
If you plan on dynamically switching animation though it’s best to do your state change requirements with in the controller rather 6han with in the animation BP as to what BP is required.
It’s important to know that state machines are literally just animation graphs linked together by transition rules. From the documentation, it says:
State Machines provide a graphical way to break the animation of a Skeletal Mesh into a series of States. These states are then governed by Transition Rules that control how to blend from one state to another. As a tool, they greatly simplify the design process for Skeletal Mesh animation, in that you can create a graph that easily controls how your characters can flow between types of animation without having to create a complex Blueprint network.
To switch/blend between state machines, you would just put a state machine into another state machine (i.e. nest them); this is the easiest and most logical way to do it. Here’s an example:
Think of this example as a state machine for a character in a first person shooter, where the character has separate state machines for each stance and a main state machine that transitions between them based the stance variable.
Another benefit of using state machines over just blending is that you can use animations between transitions as well, so instead of just blending between animations, you would use an animation to transition between them, which makes the transition look more natural. So for the above example, rather than transitioning directly from standing to crouch, you would go from standing to standing-to-crouch to crouch:
I can verify this is how Epic would do it because they do the same thing in their Setting Up Character Movement example. Here’s the final graph from that example:
In the context of a combo system, swapping ABPs at runtime is quite probably too much.
Yes it can work, yes it can be performant.
Yes you can possibly code “new” combos to acquire this way that can literally always be added when you feel like it.
But then you are extremely limited as to how you actually have to code the transitions.
Whereas, a system that purely works on montages is completely extebsible without any limitation - and it forces the developers to stick to the same standard.
For OP, i would just suggest to write a couple lines in c++ to save the animation time to a variable and re-stsrt the animation at that time - if that’s what works for him. Simple to do, and can be re-used through multiple systems for animation fine turning.
Without actually knwing what he’s doing in the end, it’s near impossible to give a precise answer.
Sync groups could be just what he needs too…
So I get that I could push everything into a single graph with multiple sub-state-machines; it’s currently broken apart/modularization that way already.
Performance-wise, I am not sure how much it would cost to go the ‘mush it all together’ route so I was asking-from/attemptingito be (more) performant and organized with a distinct graph for each thing. In practice I don’t actually have too many distinct locomotion animations; only some duplicates around locomotion’s for different weapon-types, and that space is fairly limited.
For locomotion, since I am working across multiple sets of animations, weapons, and the like from multiple sources (yeah I know, joy…) it’s certainly doable to have like a master-blend-pile to get crouch-walking working for my greatsword since that set doesn’t actually come with one. However, I was unsure of the actual overhead involved. I saw in a different thread Mr LA noted ‘1000’s of animations’, so I would assume/conclude that having a dozen or so of the following kinds of blend-mashups wouldn’t be too expensive?
The combo system is montage-based, works fine, and endlessly extensible as I wanted. It sounds like I can live with a decent-sized, single, general-graph and be weapon-specific on the combo’s etc? Thoughts?
I’m of the opinion that if anything, developing performant-habits in code is one the best things to do out of the gate, so I might have been trying to be too clever here? The swapping of the anim-bp functionally is allowable, ‘works’ but it doesn’t work well, or at least I couldn’t see a path to making the swap not stutter if one is in motion.
Sure, except you may end up loosing fast path doing this.
… not really, you probably just don’t know what fast path is or why it matters.
Well, you can’t blend from A to B when you do that - yet.
I suppose you could try with a pose snapshot, to mitigate it somewhat - but realistically the swap has to take place in a frame or less for you not to notice a hitch.
I don’t think that’s applicable - currently at least.
Without coding C++ which may perform faster than BP on it - and even then… it’s a worthy try if you have a few hours to waste.
I think you have the correct idea the way you are handling it.
Just make sure that you don’t do math or other operations that prevent optimization.
It may be better if you split the crouch/stand behavior into different trees that are completely isolated - so as not to have the boolean check at all…
Oh, and the 10000 or even billions of animations was referring to the weight of the animations in terms of actual files - not how many are concurrently in use.
Regardless, even with 1 per bone you’d have a hard time getting the engine to lag because of animations…
Thanks for the input/insight. I’ll look into Fastpath.
EDIT: so it looks like I was 1/2 too clever… I had some math/logic on the anim-bp that I pushed to the char-bp as when I was mucking around with swapping out the anim-bp at runtime, I realized if I had ref’s to one it kinda broke on switch. So I had the anim BP’s PULL from the char-bp.
For fastpath, however, it seems vars need to be local. But I can make the char-bp PUSH to the anim-bp (mirror var states) and then just reference them locally from within the anim-bp itself, so it ought to work.
Thanks for the insight, being able to claw anything back would be great and I believe I can turn the entire anim-bp into fast-paths as all my logic is bools or enums.
I reread your first post and thought that switching animation blueprints might actually be a good idea. The only problem is the Set Anim Instance Class “clears and re-initializes the anim instance” whenever you set it, so switching animation blueprints on each weapon switch will be slower than just having them in one animation blueprint.
With animation storage in memory, the characters are going to be constantly switching weapons, so all animations need to be in memory in order to avoid stutters from loading animations.
I think using montages for attacks is a good idea.
Yes, but you want to make sure to actually make the final result before optimizing it so that you have a something to work from. You can’t measure the performance of something that isn’t even built. So I would suggest to try all ideas, measure the performance, and choose the best one.
