UFSM: Finite State Machine

Hello! :slight_smile:

I’ve developed a Plugin module which adds to the UE4 environment a bunch of functionality regarding FSMs, so then I could stop trying to address a bazillion ‘If Then Elses’ everywhere.

I haven’t published this yet, but as always, I believe this may be useful for many other Unreal developers so I’m posting to share. Would anybody be interested in this, a FSM Component which allows you to use AnimGraph’s State Machines as visual editors?!
I like to use the AnimGraph because it feels like I’m using Unity PlayMaker inside Unreal :slight_smile:

Btw, it can be used not just within Animation Graphs, it’s very integrated with C++ API, Blueprint nodes, Behaviour Tree nodes, giving us many ‘ins and outs’ to access the same FSM Component.
Here a few features already implemented and working well:

  • Blueprintable Finite State Machine System.
  • Blueprint Actor Component Based.
  • Event-Based Tasks/Actions can be Broadcasted.
  • Supports Enumerators as State ID.
  • Supports Runtime State-Machine Creation/Deletion.
  • Supports Runtime State-Machine Event Bindings.
  • State Machines can Tick and Track Update Time.
  • FSM Properties can be Replicated.
  • Get/Set States from C++, Blueprints, Animation Graphs, Behavior Trees.

Here’s some screenies:

[Create a new FSM Component, right click Asset Browser]:


[We simply add to the Actor the FSM Component]:


[As of 1.3+ version: “Auto Activate” must be checked to activate FSM Component]

[Then we can edit the FSM’s States from an Animation Blueprint’s State Machine, like this simple one]:


[Or manipulate States from a Behavior Tree too]:


[Or we can Read/Write FSM States from Blueprint Graphs]:


[Or we can build a Finite State Machine in C++ Constructor, from scratch :smiley: ]:


[As of 1.3+ version: StateMachine->SetActive(true,false); is also required to activate FSM Component]


You can read some more details about it HERE( UE4: Finite State Machine (Programming) | Bruno Xavier )


DEMO PROJECT

1 Like

Yes - I would be interested in this :slight_smile:

I’d be interested to look at it.

Nice, seems pretty neat. I would be interested in this one

I’ve finished polishing this system and submitted to Epic; It’s available at Gumroad for the 4.12.5 Engine version :slight_smile:

This is probably a really stupid question… but how well does this work with replication?

The component is setup for replication by default;
All its UProperties will replicate just fine in an replicated Actor. Current State time, Active State ID, List of existing States, etc, are replicated.
Source is also open so a programmer can customize multiplayer behavior if project has specific needs.

Good job! My question is, can we change current active state in an existing animation blueprint by changing it’s parent to UStateMachineComponent or somehow, directly without manipulating transition conditions?

Aww, this is awesome!

In that case you can do it from any animation blueprint’s graph; doesn’t need to be a child of a specific Animation blueprint.
From the anim graph is possible to call a node: GetFSMComponent (Name) –> Set State (by ID or State Name).

Interesting. Does it come with Android flavor ? (pre-built)

Also it would be nice to see an example where stock functionality is shown and then replaced with FMS (currently I don’t quite get how it replaces stock workflow and why it could be used in lieu of stock workflow/functionality)

Cheers!

There’s a saying “FMS isn’t useful until you use it” or “You don’t need FSM until you do” :wink:

In Blueprints we can emulate FSMs with boolean checks, switch on bool, etc.
That works, but is hard to keep a “visual representation” of that pseudo-FSM and is kinda easy to get lost with so many bool checks.
I wanted to bring FSM functionality to my workflow because it will remove the need for me to be dependant on an ever growing amount of what I call “cluster of boolean glue”. I often see my graphs populated with many boolean checks and switch on checks, I wanted to get rid of all that or at least reduce its use because Blueprints are become unreadable and when a bool flag doesn’t work I expect, feels hard to track why and where…

Example:
If I simply set a FSM State to “Crouched” then automatically my controller will block actions for jumping and I no longer need to go in the input section and say “If not Crouched than Jump”.
I just say “Jump”, if the State is “Crouched” then my character already know, he can’t jump right now…

But at the end it’s just a matter of personal taste. I like the fact I don’t have to create “junk properties” anymore just to flag actions that should be possible or locked :slight_smile:

Btw, Android should be supported; depends on the build provided by Marketplace team.
And yes, I may give some examples of common Blueprint setups and their FSM variations; I just wait to see where users will focus usage for FSMs. AI, player states, input, character attributes, etc.

Nice one Bruno, I’ve been ******** about the lack of a simple FSM implementation that uses the existing editor for a few years now :slight_smile: but never had time to implement one. Will definitely get this as its really helpful for UI work.

Oh and while we’re at it, any chance of a HFSM? I mean simple state machines are useful by themselves, but having a hierarchy available always gives more power.

Yeah, I was thinking about it, but this one solved the issues I had so I decided to go only FSM for now, maybe expanding in the future.

Fantastic news. Will be purchasing then. I found it odd that UE4 didn’t have it by default, but thanks for the effort and the cost!

Yes, I believe they ditched out FSM because Behavior Trees were added (somewhat a HFSM) and for most cases FSMs are used for AI code thus Epic kinda of ‘replaced’ FSMs with Behavior Trees; but I wanted to convert Blueprint logic to FSM based and was hitting a lot of annoying issues so I’ve decided to give it a try and make my own.
Today I will take some time and begin experimentations with Hierarchical FSM for Blueprints, see if I go anywhere useful with it.

After some time playing around with workflows, I turned the simple FSM Component (which is the one published for now) into an spawnable Actor Component asset.
Just like the components created when you use Add New → “New Blueprint Script Component”, these will be possible to be stored as Blueprint Assets (and will be possible to edit blueprint graphs on them as well).
Tried a bit with concepts on HFMS… It works, but a limitation I came across is, FSMs created at runtime by the HFSM Component cannot execute any of their own Blueprint graph’s functions; they spawn dependant on the HFSM Blueprint graph instead. Other than that, FSM graphs works just fine when attached *directly *to the owning Actor, not spawned by any HFSM class.
The weird thing is that the underlying C++ routines still run for both cases, just Blueprint events are never fired when HFSM is the FSM owner.

Some screenies:

This is a somewhat comparison of the scenario I was talking, FSM vs HFSM functionality when the matter are Blueprint graphs. If HFSM is the owner, FSMs’ BeginPlay or Tick in their own Blueprint Graphs will never fire although all components are registered.
The HFSM’s Blueprint Graph takes ownership of blueprintable events and for FSMs under its domain executes only their C++ functions; I will see if there’s a way around this, although maybe is better this way for performance instead of allowing every single child FSM component have an active graph pulsing functions everywhere:

Well… This thing has honestly gone way beyond what I was expecting.
After implementing the final aspects of the HFSM class I realised how powerful it is now that I’ve rewrote a lot of details to make it work together with Blueprints and its quirks…

I’ve pushed update to Gumroad for the devs already using it, but still misses documentation.
Now there’s too many new things, too many possible cases; I will need some time to build a demo project and document well the use cases for this. This will make working on my original “real” project much much easier :eek:

{1.2.0} :

  • HFSM Component class have been carefully implemented.
  • Both FSM and HFSM Components can be stored as an Asset from Content Browser.
  • When creating a FSM Component asset, it will be located under the “Custom” tab within the ‘Add New’ component button.

Actual Limitations:

  • Do not add the same HFSM Component class twice to the same Actor. They overlap transient properties.
  • If a HFSM graph is needed more than once for the same Actor, duplicate the Blueprint to use it again as if it were a different Component.
  • Avoid using the same FSM class within HFSM Component owners as well. Duplicate FSM asset if the class is needed for the HFSM more than once.

/* Docs explaining stuff will come */