Multiple State Units Workflow

Guy Rabiller 4 years ago updated 4 years ago 4


I wanted to share some of my findings after using Bolt for some time, and also ask Lazlo what is his opinion in terms of Bolt efficiency using that approach.

With Bolt you can create Flow Machines and State Machines. But what if your entity needs several State Machines ? Should I create multiple State Machines on the same entity ?

After experimenting for a while I found a much more efficient way, at least on the code organization/thinking logic side: Now, I only create one Flow Machine and then use multiple State Units.

Here is an example, this is called COM03, it represent the handling of various audio elements when the user switch a device in order to listen to "COM03" which represent and airport ambiance like, but on board a spaceship:

Stopping a State Unit require some careful handling because when you stop a State Unit is stopped you detect it only because of the Exit State Event, but you don't know if that even is triggered because of a Transition or because the State Unit has been stopped (perhaps there is a more direct elegant way to detect specifically that a State Unit has been stopped ?). That's why I set a flag.

Aside from that, you can see I use multiple State Units and I found it to be a wonderful approach because I can have a clearer view of what's going on, and this is completely modular, I can add "features" whenever I want without disturbing the other features while still having a clear vision of what's going on.

In this example I simply started by adding some ambiance loops, then I added random announces (Male and Thai), then I added announces that must be triggered on specific periods of time. For instance the Shuttle Departure, every 15 minutes, has an announce 10 minutes before take off, then 5 minutes before, 3 minutes and a last call 1 minute before. Then a final announce of the take off.

The way these State Units are laid out is very clear, and independently of the complexity of each feature you can add up more features easily.

I've found this way so comfortable to work with that I don't use State Machines anymore, but only Flow Machines with embedded State Units. I encourage you to give it a try.

Anyway, my question to Lazlo is then: do you see any issue working this way instead of using "regular" State Machines ?

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

This is exactly how I work.  I program up a behavior in a state macro, and then add that as a state unit to my flowgraphs, enabling and disabling the behavior whenever I need to.

In effect, this is the same as the component approach unity already uses.  Unity encourages you to use smaller reusable components that you can add to a gameobject to add functionality to a gameobject.  Using Bolt, I find the State Unit approach to be the equivalent, rather than adding a bunch of machines and enabling/disabling those.  In effect, this is "good software design" by segmenting out logic individual units that can be reused.

I absolutely recommend this approach, and have regularly professed the benefits of this on Discord, trying to convert anyone who will listen.  What you are doing is absolutely okay,  1 Flow machine, toggling behavior models as state units on and off.  Lazlo has never warned me of any downside to this approach either.

Thanks for writing it up!  

Thanks a lot for your input. That definitely comfort me I'm doing the right thing. Thanks!


That is a perfectly valid way of working with nested state graphs! :) 

I think your consideration about the exit state event being ambiguous is valid. If you want, you could submit an idea thread for an "Stop" event for state graphs.

Thanks Lazlo, will do.