Visual scripting roadmap update - September 2020

Hi everyone!

Before we get into the details of our updated roadmap, we’re happy to announce the release of Bolt 1.4.13 on the Asset Store, fixing a number of issues, in particular Mac support and Unity 2020.2 support.

We are pausing the releases of DOTS VS but are still developing and maintaining it, as Bolt is being accelerated to progressively merge with this architecture. More details as part of the roadmap below.

Visual scripting roadmap update
About a month ago, we presented our revised plan to accelerate delivering visual scripting in Unity for all of you. Thank you for your input from across the forum, discord, and in one on one meetings. We’ve used this to refine and adapt our plans to serve the needs of as many of you as possible. It is now time to provide more details about this plan, and address several concerns some of you have raised.

Our ultimate goal with visual scripting is to simplify designing interactive behaviors that are as powerful as a script, in order to:

  • Enable more creators, in particular non-programmers, to leverage Unity and achieve their goals.
  • Improve team collaboration by giving artists and designers more opportunities to work directly in the engine, closer to developers.
  • Maximize user’s productivity, by progressively unifying graph-based tools, regardless of the workflow and regardless of the engine architecture.

Here is our roadmap in a nutshell:

Details of our work in pre-release
Our work in pre-release is the integration of an improved version of Bolt 1.4 into Unity as the starting point for Unity visual scripting workflows. The exact list of features and improvements will be more precise as we begin to release early versions in the upcoming alpha and beta versions of Unity, but here are some highlights:

  • Unity visual scripting comes as a core package, meaning no particular download or setup steps would be required to start scripting visually, making it very accessible to everyone.
  • The team will have fixed dozens of existing issues, as well as improved speed and reliability of several authoring features.
  • Visual scripting will support graphs designed with Bolt from the Asset Store, confirming our intention to support the very fast growing community of users into the next steps.
  • The documentation is being consolidated, filling some existing gaps such as custom nodes creation.
  • More learning content material is also being produced.

Details about our development work
We have already started reviewing the following topics, and in some cases started their implementation. We cannot commit to the timing yet. This list of improvements might not be released in this order.

  • High level nodes for non-programmers:

  • Making visual scripting even more accessible by providing nodes that are simpler to use. High level nodes are also not dependent on the underlying API, reducing migration challenges when upgrading Unity versions, or using different project architectures.

  • High performance interpreter:

  • We are preparing an interpreted runtime that would significantly improve graph execution performance, cut down on memory allocation, stabilize platform support, and enable DLC graphs.

  • Unified UX and workflows:

  • We are preparing the convergence with Graph Tools Foundation, an independent UX layer coming from DOTS VS that we will leverage to align most of our graph-based tools workflows.

  • Leveraging various elements of Bolt 2, we are bringing large performance improvements in the Graph View and Fuzzy Finder.

  • We’re preparing improvements to variable management, addressing referencing through magic strings, strong typing, in order to consolidate and better align with the Graph Tools Foundation data model.

  • Event support will be improved, making it easier to design event-based logic, and allowing you to leverage other modules or packages across Unity such as the new input system.

  • Serialization replacement for improved graph forward compatibility support and performance.

  • Monobehaviour and DOTS

  • Our new runtime interpreter brings us closer to DOTS compatible runtime. Coupled with high level nodes and generic front-end powered by Graph Tools Foundation, we are preparing a unified workflow working across Unity architectures.

How can we provide feedback about this roadmap?
We are inviting you as usual to engage with us in this forum thread, or on the official Discord server. We are also preparing a platform for you to vote and share comments about each aspect of the visual scripting roadmap. More information about this soon.

Why isn’t Bolt 2 or DOTS VS being used as the starting point for visual scripting?
Since the acquisition announcement back in May, the number of Bolt users has dramatically increased, and a huge number of graphs are being designed in it as we speak. We consider our duty to support all users in the evolution of the visual scripting workflow and are taking steps to provide a progressive path forward, regardless of the technologies used under the hood. This means we want to avoid releasing a major breaking feature, but instead incrementally improve visual scripting workflows to a level of production readiness that matches the expectations for all projects’ scale.

For the next steps, we have evaluated using the Bolt 2 alpha technology and the DOTS VS experimental package. Both data models and architectures are very similar in providing significant improvements required to evolve visual scripting, including the needs of performance, better scale management (variables, events…), and more global UX improvements.

Both Bolt 2 and DOTS VS technologies will be used in our next steps. Our architectural mix being developed provides the necessary foundation to support workflows for both monobehaviours and DOTS; it will support Graph Tools Foundation, an independent UX layer that we will leverage to align most of our graph-based tools. This is how we can both help all of you navigate the evolution of visual scripting, while delivering the increasing benefits you are looking for.

When would we get code generation for visual scripting?
As part of our conversations last month, many of you mentioned the importance that code generation represents to them, and there were two separate reasons for it: performance, and learning programming.

From the performance point of view, graph-level code generation is not always mandatory, and might in some cases create restrictions to some of your workflows, or even to performance. We want to provide high performance, but also the convenient flexibility to use the same graphs for both monobehaviour and DOTS, and enable you to consider graph updates at runtime that balance performance and interpretation. As part of our next steps we aim at implementing an interpreted runtime that will save the costs of runtime reflection, increasing already the performance by an order of magnitude. Then we would include snippet-based nodes (pre-implemented nodes at a higher level of abstraction) that will be more optimal than an automatically generated equivalent, and provides optimisation opportunities based on the graph structure.

Regarding code generation preview for learning opportunities, we see the value it provides but consider it lower priority in the short term than other aspects such as performance and data model scalability. Graph-level code generation is still part of our longer term plans, so this topic isn’t closed, and will be discussed again.

Does aiming at enabling non-programmers exclude serving programmers’ needs?
We mentioned the intention to aim at enabling non-programmers, and some of you last month felt it was opposing this to serving programmers, or interpreted it as avoiding to deliver programming concepts in visual scripting to all, including artists.

We want to clarify this point. In fact programmers can work in Unity today, but it is extremely difficult for non-programmers to leverage Unity for their projects. This is why we are taking action in this direction. However many of you pointed out rightfully that programming concepts, such as a more consolidated data model, or better type management, are important to consider larger scale production. It would be useful for non-programmers to better structure their creation in order to be more successful, or even learn programming for those inclined to do so.

Visual scripting next steps will contain such improvements, with a particular attention to making those accessible to non-programmers.

What other graph tools would be unified using Graph Tools Foundation, and would we get access to this as a public API?
Unification of graph-based tools brings several sets of value for different reasons. First it is a question of productivity for you, leveraging your muscle memory across the Unity ecosystem. Second, it makes Unity more approachable to newcomers by consolidating practices across the engine. Finally it forces us to architect our various tools in a componentized way that will help us evolve faster in the future the graph-based tools you use.

The UX layer we intend to use for unifying graph-based tools across Unity is called Graph Tools Foundation. This layer is architectured so that we can share it across tools within Unity, but we also intend to deliver it to you all so that you can benefit from this technology for your projects, to accelerate graph-based tools development, and get a large part of the UX aligned with other tools in Unity that users are familiar with.

Our team is currently working with several other teams across Unity, and some of the migrations projects have already started. Shader Graph and Visual Effects Graph are examples of teams that are already evaluating their migration to Graph Tools Foundation, and the conversation has started for multiple other experimental packages.

Stay tuned for more details for public access.

We hope this clarifies many of the questions you asked, and I invite you to tell us what you think. You will be able to get your hands on the first version of visual scripting in Unity as part of upcoming releases of Unity alpha and beta versions.

As always, thank you for your feedback.



Both Bolt 2 and DOTS VS technologies will be used in our next steps.

What about those who bought Bolt 1 specifically to get Bolt 2 as promised but now aren't getting it? Using their technologies in the next step isn't Bolt 2, not even close. I've tried to contact support but it has been WEEKS since and I've not heard anything from them.

EDIT: To me it still seems like you're focusing on existing support instead of fixing the system for the future. Incremental fixes here and there to support all the existing Bolt 1 stuff seems to miss out on a lot of the issues on why Bolt 2 was being made in the first place. I understand that it is tough breaking backwards compatibility, but if there ever was a time it would be now.

What about releasing what exists currently of Bolt 2 to those who wish to do their own branch on it? Or creating some tool to convert from Bolt 1 to Bolt 2?


Hi @Stexe , I can poke our support team to find out what's happened with your request. Could you please send me a couple more details in private (date of submission, and if it was with this Unity account or another one)?



I think my concerns are largely addressed.

Better docs for custom nodes, considerably better editor and build performance, variables and events system improvements, better fuzzy finder too. I'm also hopeful for the mentioned consolidated data model - graphs really need a closer relationship with object scope variables so they can be reused just as easily as macro graphs.

Sounds good! Looking forward to it.


Sounds like you're dedicated to delivering a strong VS foundation in the future. Once all the core issues listed "in development" are addressed I will revisit Unity VS. Until then, all I can say is good luck. I hope everything goes smoothly.


Thanks for the update, there is one more argument for code generation, some client projects don't accept visual scripting and want only the source in code.


Interesting. Can you elaborate on the reasons they wouldn't accept visual scripting from your experience?

Visual scripting is less expandable and understood by most people. I do think visual scripting is going to be the future -- just as programming has evolved over the years, visual scripting could be the next step. But it needs to be done properly. I'd hope that in the future Unity can get it right but still seems it is off focus from a lot of what other people were asking for.


While I did had some cases like that, the argument always used was that they would need a license to the VS tool to be able to modify the source, with Bolt being free (and soon enough will be built-in) this is not an issue anymore.


Excellent update.

I'd like to suggest that a behavior tree implementation be tucked into the visual scripting roadmap at some point: AI is something most games need and is sorely missing in Unity at the moment. I think it can dovetail nicely with Bolt's integration, and can make AI programming more accessible for content designers since they can keep using the same graph system they will be using in the future.


Source control is a big one, and being able to do diffs


But for me personally it would not be a big miss, for me high level nodes are important and being able to interface with other tools, ( input, gestures, networking lobby etc )

For example triggering particles / sounds from a collision event, or setting a variable in an asset store plugin or shader.

Those basics are what make most of the game play scripting for me.




1 Like

Thanks, this addresses my needs (Variable hell + Performance). Thanks for listening.


Yes, we're having an active conversation with multiple teams, including state machines and behavior trees. We hope to make them all unified with Graph Tools Foundation, which would both make them look and feel the same, and simplify data interop.


Good one. We're considering revamping the serialization to most likely use the Unity main serialization component. This should help with things like adressables and graph DLC, and should open up the possibilities for diff and source control.


Nice detailed roadmap update. Looks promising. Thank you!

I wish Bolt brings in vertical flow soon. (IMO, It makes a big difference)


This topic is coming back all the time in our conversations. So definitely something we should expand on in a future update. Thanks for reminding me!


While I appreciate their candidness -- I too wondered about these 'next-steps'.

This... not a roadmap.

These 'next steps' are the bulk of what the "roadmap" is to me (and clearly other users).

A few more details on how things will be 'addressed' in these steps would be nice.
Maybe a simple bullet-list?
One thing I worry about is the "interpreter" part. -- What does that do to performance / ECS workflows?

Interesting. I'd like to hear more.

I just wonder what this means to me, on the ground level, as far as timescales and tool/workflow dependencies go.
For example, there may be "state machines" and "behavior trees" in 'interpreted' graphs, but what about ECS-style graphs? -- Stateful data in a stateless environment is complicated, but a "tagging" system like I've suggested in previous VS drops would help something like this by bridging these interdependent "systems" and attributing stateful data to stateless systems. Yet, how many years are we looking at for this kind and level of integration?

This is just where I am right now -- no really "new" information besides "Hey, we hear you." (which is still important, but doesn't address the above.)

Either way, it really is great to hear that you guys are planning to integrate the feedback somehow.


Can't wait for better event support! ...seriously...can I have it now? ;)

And the Graph Tools Foundation is really exciting. There could be all sorts of great features build off of that. Behavior trees. Dialogue trees. Level streaming setup. GameObject referencing in a scene. Great stuff.

1 Like