GC FSM - Event-driven, hierarchical finite state machines in blueprint

Hi Everyone,

I am working on this plugin for a while and I am now ready to show it to the community: GC FSM provide you with all blueprint node to write finite state machine directly in blueprints. These are the salient points:

  • Right there in the blueprint editor: the definition of a state machine is done entirely in the blueprint editor and can coexist and mix with “normal” blueprint logic. GC FSM does not use the animation editor as done by other plugins, which was not designed for editing “code” state machines.
  • State classes for reduced complexity and re-use: you can create state classes to package building blocks of behaviour that can be re-used several times in multiple FSMs.
  • Event-driven for decoupling: transitions between states are triggered by events, allowing you to de-couple the logic and complexity of the state machine from the higher-level game logic.
  • Not just actors: any object can run state machines, not just actors. You don’t need to jump through hoops to create a state machine in non-actors, such as components.
  • Unlimited machines, unlimited nesting: an object can run multiple state machines at the same time and state objects can run state machines too, allowing for natural hierarchical structure.
  • Timeouts and deferred events: states that are meant to be transient can have a timeout so they are exited automatically. A state can keep track of events it doesn’t handle and pass them to the next state, thus ensuring that important events are eventually handled in the right context.
  • Integrated debugging: you can debug state machines within the blueprint editor itself or monitor the flow of events in the Unreal Visual Logger.

The plugin is ready, I am just working on the petty details, like the website, the tutorials and ironing the documentation. It will be published very soon! If you can’t wait, here’s a glimpse of how state machine could be implemented in GC FSM:

What do you think?

Is there any reason you aren’t using Behaviour Trees?

Behaviour trees are a wonderful tool, but they are not a silver bullet. There are still things that are more easily done in blueprints. But the main reason is that behaviour trees can only be run by AIControllers, therefore they can only be used for enemies with a pawn. But in a game you often have the need to design complex logic that is not strictly “behaviour” and that is not attached to an “enemy”. For example, you can use FSMs for menus, for puzzles or even to handle certain aspects of the main character or the player controller. Different tasks, different tools. That’s it.