Since the Unity Visual Scripting team had Graph Tools Foundation training not that long ago followed by UVS 1.8 preview being pulled from public access, I speculate the UVS team is now refocusing on the next major version of the tool for Unity 2023 . So this seems like the right time to look back at what made Bolt 2 so great to use and what the community would want from a new and improved version of UVS.
All screenshots/GIFs/Videos have been taken from Alpha 11 of Bolt 2 that was released under Ludiq ownership.
1. Variable Management
Current UVS variables are both loosely typed and loosely referenced, which introduces multiple problems.
1.1 Variables can’t be safely renamed.
This requires that each instance of the variable has to be found manually in all graphs by visual confirmation and renamed by hand. Needless to say that this does not scale past small projects, especially because errors due to variable name mismatch are not reported at design time.
Renaming variable in UVS 1.7
Bolt 2 solved this with GUID based variables, which enabled both safe variable renaming for all instances of the variable in all graphs and safe variable retyping. Both name and type error mismatches are printed to console at edit time.
Renaming variable in Bolt 2
1.2 Loose variable typing
This creates performance implications since variables are held in massive <string, object> Dictionaries and it also creates a lot of room for user error.
UVS 1.7x Type mismatches do not throw errors at design time and visual communication of variables leaves a lot to be desired since no matter what the type of the variable is, it always has the same generic grey “object” icon in the graph.
Variables in UVS 1.7x
Having the variable’s type visible in the graph makes it much more readable.
And having the variable be strongly typed significantly cuts down the room for user error since Bolt 2 does report type mismatch errors to console at design time unlike UVS 1.7x.
Variables in Bolt 2
Notice also how the Bolt 2 variables are compact and use the space available more effectively.
1.3 Object Variables design
Object scope variable blackboard currently is a completely separate component in UVS 1.7x:
Variables component is separate from the Graph in UVS 1.7x
Which means that if you build a reusable graph that relies on a set of Object scope variables, you have to recreate these variables by hand on each new object the graph is applied on.
One would expect that dropping a graph on a GameObject would also populate the necessary variables just like with a C# script. But that’s not the case with UVS 1.7x.
Bolt 2 solved this by having a data structure in the form of a class that grouped together graphs with variables that had per instance overrides.
Dropping the graph on a fresh GameObject also brought with it all the necessary variables which is also consistent with how C# scripts work in Unity:
Variables are grouped together with the graph in Bolt 2
Now, I’m not advocating bringing back the class structure since Unity have said Bolt 2 was too programmer centric. But surely Object scope variables could be defined on the graph’s level so they don’t have to be recreated by hand every single time a graph is reused. This would also enable them to be GUID based which is not possible with separate Object Variables component.
2. Custom Event management
UVS Custom Events system is the main way of communicating between separate graphs for designers. And it’s largely plagued by the same problems as the variables system. Namely loose referencing and loose typing.
Custom events can’t be managed in any meaningful way in UVS 1.7x since they’re basically loose strings buried somewhere in the graphs. There’s no way to know how many custom events are defined in a project, what their names are or what even their argument count is or argument types are. Nor can you see what triggers or receives the event.
Custom Events in UVS 1.7x
Bolt 2 solved this with GUID based Custom Events that are strongly referenced and strongly typed. You could see exactly how many events exist in a project, you could see their argument count and types. And when you dragged the event from the inspector into the graph, the argument count/types were predefined, none of the manual fiddling of 1.7 events.
Needless to say that this enabled the custom events to scale past small Unity projects and made them viable for production.
Custom Events in Bolt 2
3. Graph Search
UVS currently doesn’t have a graph search functionality built in. One could somewhat work around the loose variable and custom event referencing if graph search enabled to find all instances of a variable or custom event. But it does not exist. Bolt 2 had advanced graph search that could locate anything in the graph in addition to Graph Explorer window that listed all graphs, variables and custom events in the project which was also searchable.
Graph Search in Bolt 2
Also, take a look at myanko’s Graph Search implementation for Unity Visual Scripting. The tool absolutely needs something like this natively.
4. Subgraph Workflows
If you spend any meaningful amount of time with Visual Scripting, you’ll come across the need to use Subgraphs either for reusable pieces of logic (akin to a C# method) or to make the graphs more readable and manageable in general.
In UVS 1.7x the subgraph has to be created manually by hand every single time which takes about 1-3 minutes per instance
In Bolt 2 it takes about 7 seconds with collapse selection to subgraph functionality
And even if I’m creating one manually from the start, I can still drag and drop both value and flow connection ports on Input/Output nodes to automatically define them
Both the collapse selection to subgraph and automatic value/flow definition are massive timesavers.
5. Misc workflow improvements
In no particular order.
Comment boxes
Practical string literals:
UVS 1.7x string literal
Bolt 2 string literal
In addition to Assemblies and Types it could also add nodes by namespaces
In Summary
Please improve variable and custom event management. As well as improve subgraph creation workflows and add graph search. That’s all the tool needs for it to scale past small Unity projects workflow wise. I know you have the high performance interpreter in the works which is why I haven’t listed performance related issues with reflection. I’m looking forward to that. But performance alone won’t fix the issues the tool has inherited from Bolt 1. Those same issues were largely addressed in Bolt 2 which might offer some inspiration for the next major version of Unity Visual Scripting.
