Inspectable graph inputs

Lazlo Bonin (Lead Developer) 4 years ago updated 4 years ago 2

Flow machines and flow states should display inspector fields for every graph input port of their associated flow graph, if the port has a type with an inspector.

This would allow graph inputs to be used more like behaviour fields in Unity, as a quick configuration for the graph. 

In addition, for the sake of organization, a "Category" field should be added to the graph input definition configuration that would group those under headers in the inspector. This category field would have no visual impact when the graph is nested in a super unit.

There are a couple of tricky issues to flesh out to implement this (e.g. how the input literals get stored, if a port gets renamed or removed, what happens of the matching literal, etc.), but the benefit of the feature makes it worth it.

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

Declining this, not because I don't like the idea, but because I want to do it right.

The main problem with this approach is that only flow machines would benefit from inspectable inputs. There would be no way to send inspectable parameters to state machines, because state graphs don't have inputs. Moreover, if I decided to add input to state graphs, I would need to find a way to trickle that input down their child states, which would add a whole new layer of data flow.

Thinking about this more, I realize that the real underlying objective is OOP encapsulation: defining some kind of "class archetype", with properties (predefined inspectable variables) and functions (flow graphs with instance inputs and outputs), that can be configured on the component instance, just like in Unity. This is, of course, a major feature, that would probably mandate an entire major version (e.g. Bolt 2). However, it is infinitely more versatile and robust in the long run.

tl;dr: If I ever implement inspectable properties, it will be by adding OOP encapsulation to Bolt. At the moment, it is too early to start planning for this, but it is one of the most interesting long-term plans in my opinion (along with, for example, behaviour trees).