Feedback On the road to the next major version of Unity Visual Scripting, Lessons from Bolt 2

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.

Spoiler: 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.

Spoiler: 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.

Spoiler: 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.

Spoiler: 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:

Spoiler: 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:

Spoiler: 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.

Spoiler: 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.

Spoiler: 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.

Spoiler: 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.

Spoiler: In UVS 1.7x the subgraph has to be created manually by hand every single time which takes about 1-3 minutes per instance

Spoiler: In Bolt 2 it takes about 7 seconds with collapse selection to subgraph functionality

Spoiler: 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.

Spoiler: Comment boxes

Practical string literals:

Spoiler: UVS 1.7x string literal

Spoiler: Bolt 2 string literal

Spoiler: 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.

 

Wow thank you for taking time, to bring that up. I was never able to make Bolt 2 to work to see all those improvements to the workflows. I like to see that the graphs will be faster in the future.

I can understand that Bolt 1 was stress tested on full projects and that Bolt2 would be taking more time to bring to users and give values. But seriously, that would be like Christmas if those features could come in the current version until the new fast interpreter come.

I would just say that those two points feel like not enough.

Search in Bolt graph

• Seem to only search in current graph, but feel entry level feature.

Assemblies and Types
Look good for progs I guess, but is not enough if you don't know API.

• Should be able to clearly see Everything you need to bring from a package perspective at some level.
• Should be able to quickly get missing stuff in our graphs.
  • If I import graphs with URP nodes, I should not search in 3 sections to try to find what I need to add.
  • If I want to work with a component that have nothing imported in. Should be able to still get access to it. Like in IDE.

 

Search in Bolt 2 was two tiered as it had a dedicated Graph Explorer window that listed all Bolt Classes in a project that by extension also contained all graphs, variables and custom events in a project.

So Bolt 2 had Graph Explorer search and local per-graph search with some overlaps such as the Find References functionality.

Spoiler: Graph Explorer Search

Since Unity Visual Scripting doesn't have such a window that lists all graphs in the project with extra functionality, I didn't showcase this. And your work on the Node Finder for UVS is definitely a much better fit for the current version of Unity Visual Scripting. It's also more user friendly is some ways.

All good points. I'd also argue for the opposite to be possible - I want to sandbox the whole thing and only expose curated nodes to the designer. For many use cases having 25-30k API nodes creates a lot of noise and possible confusion when the designer in question could do with a few basic event nodes and flow control nodes + my custom written nodes for the game in question.

 

Yeah, be able to search in all different contexts, directly on top in the good context is a true gift when working on big projects.

Yup this is super valid. At some point in your production, you may also want to make custom list of nodes per graphs/per user roles. Depending how big your team is.

 

Being someone that deals with student artists all the time, class systems would still solve tons of issues when using UVS. I don't feel having this functionality will bottleneck artists at all.

For the love of all that is holy, just make private and public variables PER GRAPH. Make it so artists can communicate between graph variables if they need to...similar to GetComponent<>.publicVar. I can guarantee that EVERY artist will understand the concept of communicating between graphs and changing variables based on what graph it is. It also teaches artists the basic functionality of OOP.

I know you guys have been working hard on this and I hope a variable management overhaul is being done. The way it is right now is functional but brutally tedious to fix issues.

Unity has a huge problem with worrying about "changing too much" in fear of backlash...or fear of some things not being compatible from previous versions. I personally do not care if I have to re-do all graphs as long as they are cleaner, scalable, and make more sense logically.

 

I agree. Having some kind of data structure like a Bolt 2 class is far better than no structure of the current version, in my view.

But Unity seemingly disagree. They're aiming the tool at designers - level designers, quest designers and other similar use cases for large teams in AAA space. So by that metric, the tool has to be as simple to use as possible and it's basically a vehicle for arranging custom high level nodes in bespoke combinations.

A high level node does not necessarily benefit from UVS having a class structure, so I understand why they might see it as unnecessary.

Same here, backwards compatibility is not a concern of mine. Especially now that there is a two year wait for 2023LTS which hopefully will have the new version of UVS with all the GTF and high performance interpreter goodies.

 

I would add the possibility of having vertical graphs.
I know it's a controversial subject but personally I find it cleaner, mainly because the flow and the data don't go in the same direction which makes the graphs more compact and readable.

 

Is it better to use Unity Visual Scripting or GraphView to make a dialogue and quest system?

 

Thank you for this detailed writeup! I just learned how to make subgraphs from your animated gif... much obliged!!

 

UVS is a no go in its current incarnation. GraphView could be considered, but it has some kind of weird reference only license whatever that means. It's also not beign developed anymore so if you come across an issue you're on your own.

 

Thanks. What do you suggest to make a custom node-based dialogue and quest system? I heard about Graph Tools Foundation, but I'm worried that would be abandoned as Unity's other experimental packages

 

Graphs Tools Foundation package is abandoned as of last summer, but that's because they're integrating it into the core of the engine. All Unity's graph based tools will eventually use it. It's just not available yet.

The safest bet would be to do it the traditional way with IMGUI. GameDev.tv folks have courses on implementing a custom Dialogue and Quest systems with IMGUI. Unity Visual Scripting is also still IMGUI based for its UI front end.

 

Thanks a lot!

 

I'd recommend to use UVS because it gives you scripting for free, something that you would have to make from scratch if you were to write your own GraphView.

 

The guy wants to make a Dialogue and Quest systems, he does not need free form scripting for that.

Also UVS is not free. It significantly increases domain reload time, enter Play mode time, it adds to both build size and loading times on platform - especially noticeable on webgl and mobile. It also has questionable AOT platform support as of the two latest minor versions, the build is unlikely to run on IL2CPP platforms. It also impacts editor performance and build performance since the runtime is based on reflection.

And any custom tech built on top of UVS will soon become useless since they're migrating both the runtime and UI frontend to different technologies with different APIs.

 

Thanks, I won't use GraphView because it's abandoned. I've been trying XNode and it seems flexible for a dialogue/ quest system