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.
Laurent