Machine scope for variables

Lazlo Bonin (Lead Developer) 3 years ago updated 2 months ago 5

In some design patterns, it might make sense to have a machine-level scope for variables.

These variables would be shared across graphs in the same machine (e.g. super units, super states, etc.), but not across machines on the same game object.

Machine variables would therefore be "wider" in scope than graph variables, but "narrower" than object variables.

My current stance on this idea is that despite its apparent usefulness, 

  1. Most (all?) designs can be rethought to avoid the need for machine variables
  2. Adding a new scope would add to the already complex scope system
  3. It requires significant implementation and documentation time

Example use cases:

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

All I wanted was to be able to make a state macro that would carry out its code after being put onto any object ( Reusable) I do that now with set directly to scene variables, so the macro creates its own variables. Would be nice if a state machine was really just one graph and then other states could use those vars in the macro. Meaning saving a macro would mean incapsulating just those vars for the whole graph in that macro (very reusable)

How can I reuse the same machine multiple times on same object?
For example lets say I have a machine that adds a variable to localPosition.x and logs it.
I can ad the machine twice but i cannot pass in two different variables...

this is just basic functionality that you can do with all 'objects' no?
so i can pass input into flow but not state?
so i can pass input to gameObject but not monoBehaviour?

i guess we each just need to develop our own weird variable sharing and naming and loading technology


or i guess i am just doing it wrong...  thanks

Hi Rakka Rage,

At the moment, there is no way to do this. This is something we hope to support in the future with OOP-like encapsulation.


(Sorry for the bump/necro, I'm doing some roadmap grooming following the Unity acquisition!)

This is now supported in Bolt 2 via classes. Class variables have an instance (e.g. component) scope.