What is the difference between state machines and flow machines.

Bryan Ogden 4 years ago updated by Lazlo Bonin (Lead Developer) 4 years ago 2

Can somebody explain the difference between state machines and flow machines?

I'm trying to make two existing unity c# text processing scripts "talk" to each other - Im ok at c# and have a fair amount of time invested in Playmaker. but I thought Id give it a go in Bolt - 

Do you recommend I use a state or flow machine? How do we access the variables of one script and route them to the other? 

Are intermediate "Bolt" variables as containers recommended to make this process easier? 

Any body have a simple example Bolt graph  that illustrates this integration of two existing scripts? I usually pick up on these things quickly but for some reason I need a kick start on "getting this".

Bolt Version:
Unity Version:
Scripting Backend:
.NET Version (API Compatibility Level):

Flow machines are the closest conceptually to C# code.   They describe "what" to do, given some form of event of trigger.  

State machines describe "when" to use flow machines.  State machines can't really do anything on their own without "flow states" (which are effectively flow machines) that describe what to do, but they can transition from state to state, turning flow states on and off.  State machines are much closer to the FSM concept of Playmaker.

If you use a Flow machine, your speaking in terms of triggers and events that you want to react with.  With a State machine, you have access to turning Flows on and off, transition around based on your logic.  The Flows are still causing things to happen in your game world, but your State Machine is dictating when Flows can be active.  In terms of practical effects, you could have a State machine with a single starting Flow state and that would behave just like a Flow Machine.

To make objects "talk" you have a couple of mechanisms.  You could use the Custom Event system with some parameters, which is kinda like a C# event (the C# language one).  Any number of entities can subscribe to it, and react to it.

Alternatively, you could store the variables at the scene level (or, if they are in separate scenes, at the application level).  Are they on the same object?  Then you can store them at the object level, and both scripts can access them just fine.  There is a graph level of variables, but that's for the things you DON'T want to communicate with outside objects.

As for whether to use a state machine or flow machines, that would probably depend on the structure of the scripts.  You can use state machine with multiple independent trees with their own starting nodes to incorporate multiple "classes" of behavior.  My advice would probably be to make it a macro (meaning it exists in the assets, rather than the gameobject in the scene), and then you can access it however you want from Flow states or Flow machines.


My best attempt at explaining it is in the manual on that page here:


Let me know if you have further questions!