Hi.
Is there a best practice for implementing a FSM in UE Blueprints?
I come from C++/DirectX. There, I used to implement everithing in a big Switch statement.
At the moment I’m doing the same exact thing in BPs, but I’m not sure this is the best way.
your images are too small to figure out what you are doing there but if you want my humble opinion you should try doing it in code if you know how to code.
this because I’ve tried to implement state machines in blueprint and I’ve discovered that blueprints executions is not guaranteed by unreal in certain cases. so they may abort running a chain of nodes till the end. or it will be finished after you think is finished.
is a very delicate balance and you need deep knowledge of blueprint execution steps, which nodes do what, when they do it, if they can fail.
my cautionary tale is that I’ve tried to use blueprints because learn to code was supposedly too complicated. Then I’ve ended up with various “bugs” which took ages to figure out just because I didn’t knew how this system work. It would had been way better to learn to code and do complex stuff in code and use the blueprints for simple stuff, as the system was intended to be used
Hi @OrfWare, making a FSM using big Swtich statements are very common. Regarding whether or not if it’s the “best way” to do it is very debatable.
In my project, I created a actor component that handles the player’s states. This actor component does not use switch statements or an ENum. I use gameplay tags and the way I limit the actions the player can do is by checking if my current state is equal to something and that determines if I can perform the action.
Again, whether or not the way you set up your FSM is is the best way or not is very debatable, but personally I think there are a lot better ways of approaching it and it will take time to learn and discover for yourself since there are only so many tutorial videos available to the publics.
Hope the helps! 
I’ve done them both with switch statements and gameplay tags like this, and with states encapsualted as objects.
I’d prefer the Uobjects if working on a team or if behavior in states is very complicated, but otherwise stick with switch statements.
If you break things up into very succinct events the graph can stay very easy to read with the switch statements way.
For uobjects, its more boilerplate and some hijinks with getting data in and out of the objects, however it is properly compartmentalized which is necessity if multiple people are working on similar things.
There are some plugins for blueprint graph state machines and a free version to test out. Personally, it seemed like learning somebody elses complicated system wasn’t preferable to doing my own simpler thing, even if its not as elegant or robust. But you can’t beat a free demo! I think logic pro was the name.
Thank you guys 
