Official The road to 2021: Visual scripting in Unity

I have questions but most of them have just been ignored before so... /shrug

EDIT: Since it seems you're actually answering questions for now, I'll post some again later on.

 

This blog post seems somewhat useless
Do you have plans at leas answer what direction you move VisualScripting now?
Something more than that "VS is cool and we do our best to make it to 2021"

What will be with bolt 2 features or when we can expect anything?
What good ideas of Bolt2 and community you decide to throw out and what to implement in your vision?
Actually what is your vision? You say you gather feedback from community but you never say what you do with this feedback just silence.

Everything we know for now is that you ignore Bolt2 features and go back to good old Bolt1.
May be now 4 months later you have more to say about your vision and what we can expect from Unity 2021 VS solution?

For me it is more interesting when you plan to bring Bolt2 like VS into Unity if ever?

You promise to answer our questions in this thread https://forum.unity.com/threads/visual-scripting-roadmap-update-september-2020.978732/ but it is never happened. May it is time too?

 

I have a ton of questions:
When Bolt was taken over by Unity it was said that bolt 2 would be in the process of being released as beta in a couple of weeks from now(23 April 2020) I had my dough ts already then https://forum.unity.com/threads/welcome-to-bolt-2-beta-coming-soon.874729/page-2#post-5817064

Bolt 2 seems to be dropped and now bolt 1 is about to be integrated into Unity and it blows my mind even further.
From what i understand its a rewriting of namespaces and some class and method names to make if work better with the existing structure.
It's more complicated than that i am sure but the basically its Bolt1 merged into Unity.
At least that's what i understand about it.

I have the following thoughts:
first off Bolt 2 power was that it would generate script files and so reduce much of the added lag using an other layer of coding.
Secondly it seems Bolt 1 integration isn't using the Graph and GraphView etc libraries but it seems to still use the Ludiq framework still.
What i find puzzling to say the least.

Third: How about using visual coding using the Dots system ? Is that project dead in the water?
I am not sure what the current status of Dots is and about the visual coding that did use Graphview. But it seems Unity is betting on all kind of horses at the same time. (My personal opinion is that Unity should have created a total new branch with only Dots rather then trying to integrate it in the current Unity build but that's an other discussion )

I understand that there is much interest in visual scripting. Hack i think it has great potential for me at least for big project (Not even game related) to get quicker an overall working of a program and dive deeper in your code and see what is happening visually and visually debug while the program is running.

For people wanting to code but finding it to hard i can imagine that visual Scripting seems a much lower stepping stone. I just hope that visual Scripting will take on the DOTS and other systems and provide script export functionality to be able to use Visual Scripting with at least performance loss as possible.

So I do not understand the roadmap and how above concerns i have (And hopefully many others) are being taken care off or are even considered.

Truth be told i haven't read much the forums and stuff last year so i might be unaware of some stuff but that's reason to write here to get answers and information and be corrected and i am just a hobby unity user .

 

I’d like an update on what's being technically done to improve the main Bolt 1 issues - performance, API documentation, variables and custom events weak typing/general usability issues, QoL features like graph search and error highlighting in the graph when clicked in console. The roadmap mentions most of these will be addressed, but it's not clear how and how soon they will be improved.

I’m not asking about concrete dates, I’d just like some kind of list of priorities like the old Bolt 2 roadmap back in the Ludiq days. Lazlo never gave any dates, but we could see what’s the plan and what’s being worked on now. Sure, some list items were later removed and assigned as unfeasible for one reason or another, but that’s part of development.

Basically I'd like to get some kind of idea in what direction the tool is moving and roughly when it'll get there. Right now it seems it'll be years until all main pain points will be resolved, which is confusing because Bolt 2 already had addressed all my current Bolt 1 issues.

 

There was absolutely no information whatsoever as to what is the actual roadmap for visual scripting, it's just written that it's awesome and will help many developers but that's really useless to be in its own blogpost at such an early stage when visual scripting is so bad right now.

There have been no updates on the graph view and its usage in other packages or even providing a public API for it
In its current state Visual scripting is pretty much useless for anything other than prototyping in a small game jam.

I can't build anything on top of it because it's just really bad right now(no type safety, no error prediction(compiler error kind of thing), nowhere near comparable to performance to C#), and it's sure to have breaking changes in near future, so I really don't see what goal unity achieved by integrating it as core package at such an early stage, I would really like to get some insight into the real roadmap for visual scripting instead of what was in this blogpost

 

Hi @theor-unity - this is great stuff, we're very excited about VS. Could you tell us more about your plans to make it customizablea and allow developers to create custom nodes and maybe even custom graphs? For example, if a developer wanted to use VS to create a custom version of behavior trees (which involve both special nodes and special execution logic), could they do that? If not, is it on the roadmap?
Thank you!

 

Any plans on adding code generation later? or will it be a never

 

IMHO better publish you current vision with BIG label of "EXPERIMENTAL VISION!!! EVERYTHING CAN/WILL BE CHANGED UPON RELEASE" Than keep us without info about direction Unity is moving.

Or may be just return BETA users sub forum and restruct access to that forum only for developers that actually understand what is Experimental or Preview version of package

 

Any news on Graph Tools Foundation?

 

I really like Bolt, but I understand it's not perfect,or runs slower than C#.
Is translating Bolt to C# later straightforward? or is it a minefield?
How soon are we going to be able to use DOTS within Bolt? I understand there's a lot of things you guys are trying to do, but is this a multi-year thing? I guess I don't understand what the actual plan is anymore. DOTS seems very useful, and the sooner it gets into Bolt the sooner Bolt gets supercharged. It might be a better way to get devs to take advantage of that power without feeling overwhelmed.

Can you guys even say if you are actively working on the DOTS/Bolt integration now, or is it waiting for something else to get done, like redesigning Bolt first?

Also, is it likely that Bolt/DOTS will be an order of magnitude faster to run than just Bolt, like DOTS to OOP, or is there still something that will critically slow down the code just by the nature of it being Visual Scripting?

cheers

 

Well this one said absolutely nothing useful in a couple of thousand words, so not really happy with it. Dev diaries are great if they're about what developers are actually doing.

If you have exactly zero things to show for your effort yet, maybe don't make a big fuzz about it? Like

There's nothing behind the scenes in any of the stuff you wrote? You're just saying that you're working on the same things that you said that you were working on September last year.


Look, like, we get that it takes time to make stuff. If your engineers doesn't have anything that's ready to be shown, nor anything concrete to promise other than "we'll keep working on it", just wait until they have. We're not in a hurry to be marketed to.


Edit: Just clicked some more around the forums, and every single one of theor's posts are much more informative, interesting and useful than your entire blog post. Maybe cut out the middle man next time?

 

Agreed

 

I'm seconding the call for more information on custom nodes and graphs. Being able to call methods on MonoBehaviours is nice and all, but there's some real power to be had from custom nodes. Easy guards for accessing singleton systems from under the hood, multi-flow splits, hooking into generic game systems and exposing their operators through VS, etc.

 

I bought Bolt, and while I was happily waiting for the official V2 release, it was acquired.

I didn't get any compensation, and I didn't get the features and performance I wanted in the new version, which was very disappointing.

I think the authorities are too slow and I don't want to wait.

Later, I bought the uNodeV2 plugin, which implements all the functions of Bolt2 with better performance, and now I use uNode, which I think is fine.There's vertical streaming, there's code generation, and even the ability to turn C# code into nodes, which helps me learn and understand C# code better.

I've given up on Bolt for now, and based on official development efficiency, I think I'll come back in 2-3 years.

 

I think you misread his post... he isn't happy. The lack of compensation and lack of features / performance alone left him disappointed. The same with so many of us...

I tried to get a refund from Ludiq / Lazlo but was ignored at every turn -- even when Unity contacted him on my behind. Like... we're just all disappointed and definitely NOT happy with how things turned out. Sacrificing so much for backwards compatibility and then horribly explaining it and what you're going for has soured so many of us... not that we should be surprised since it seems Unity does this at every turn. Like how many years did it take for one of the most requested features (nested prefabs) to get implemented? Yeah... =/

 

@theor-unity In 2021.1.7f1 Errors thrown in the console in playmode open the script editor when double clicked instead of jumping to the graph where the error is located, imagine you have 256 Visual Scripting graphs and there is one faulty graph throwing errors in playmode ^^
I wholeheartedly suggest the Visual Scripting team to make this a priority 1 issue, make it quick and easy to find faulty graphs.
To construct an example, use a switch node and dont provide it with any input values but some cases, link the switch node with the update event, then deselect the object with the graph and press play.

 

Here's maybe an easier question/request: Is it possible to still get "Programmer Naming" when in the Visual Scripting editor in Unity 2021.1? I see there is a checkbox in Preferences for "Human Naming", but when I uncheck it, I don't see a change in Visual Scripting -- not even if I start a new script!

I'm asking because with Bolt I was having my students start with "Human Naming" then move to "Programmer Naming" before transitioning to writing code directly in C#. This was a great way to get them to understand what's going on in a program before making them read or write good old fashioned blocks of code, so I'm hoping it's still an option and I've just failed to figure it out (despite searching the docs quite a bit)!

 

Awesome, thanks for the quick reply! BTW, I am running 2021.1.3f1. I'll try to check if the problem still exists in 2021.1.11 once I have time to update!

 

So, more and more I see posts and videos that tells to migrate from VS to C# since now that it is a part of Unity, updates will be slower to keep with the Unity Engine updates. For example every feature of Bolt 2 has been either scrapped or in the roadmap for the far future. Do you guys think that this is the case, should I completely scrap VS from my project, or maybe just use it for basic functionality, while leaving the heavy logic to C#, cheers!

 

Generally, if your Bolt code runs fine, then you're good. Bolt/UnityVS is about 5-10 times slower than C# but then GDscript in Godot is also 10 times slower than their C# implementation and GDscript is the default Godot programming language. You can do a lot even with the considerably slower performance.

New features do come slowly, we basically haven't had any for the past year besides added support for the new Input system and a few, very niche nodes. They've mostly worked on converting Bolt into a package and general bug fixing.

That said, 2022 will bring the new runtime which will solve a lot of the performance problems. It remains to be seen how soon it'll actually be usable in production though. So I wouldn't place any bets on that just yet.

My favorite way of working with UnityVS is to hold all variables in C# scripts (because C# variables can be organized with headers, can be renamed and are strongly typed so you can see variable type icons in graphs. C# variables also take less space in graph visually than a Bolt variable) and offload the performance intesive logic to C# scripts. UnityVS is more of a logic sequencer for me, not the main coding tool.

 

Coo! That is the path I am slowly taking, putting most of my variables in C# . Thanks for the tip!

 

I'm not good at writing readable code, and lo and behold, there is visual programming in it, can I implement everything in the same way as in the code?

 

No. It's not possible right now or planned AFAIK.

 

If you're asking if Visual Scripting outputs human readable (or any) C# code like guybro_thunderboots implied, then the answer is no, it does not.

But Visual Scripting in its current form is a C# visualizer - for every public Unity method and property there's an automatically generated UnityVS node. It can also automatically generate nodes for any C# API be it Asset Store packages or random code from github. As long as the variables, properties and methods are public, UnityVS can access and manipulate them.

In that sense UnityVS can implement many of the things C# can with a few exceptions. Currently, it can't deal with any kind of generics by default which can be solved with custom coded nodes. It also doesn't support callbacks/delegates which also can be solved by custom coding event nodes. UnityVS also can't really do any kind of inheritance or advanced composition techniques so stuff like interfaces, abstract classes/methods, etc are not possible. So proper project architecture can be a challenge in UnityVS alone but still possible.

If you can implement something in C# code, you can likely do it with UnityVS as well. It's just not the best tool for the job a lot of the time, in my opinion.

 

I took the question to be more literal: "can I do everything in Visual Scripting that I can do in C#?"

To elaborate on my answer ("No"), there's a category of things that Visual Scripting doesn't and probably won't support:

- Implementing C# interfaces
- Inheriting from C# classes
- Creating C# events
- Creating delegates
- Listening for Unity's magic method invocations

While you can avoid those things in any Visual Scripting graphs you create, there's going to be times when you need to interoperate with C# code. That code may expect to receive an object that implements an interface, inherits from a class, is a reference to a delegate, etc, etc, etc. In those circumstances you'll be forced to write C# glue code. Thus, a pure VS approach isn't always going to be possible.

Now, some of these limitations are "resolvable" on Unity's side. For example, if Unity introduced either a core message bus or an event bus, the need for many of these C# features go away when we discuss interoperating with other systems, regardless of implementation (C# or VS) and ownership (your own or a third party's).

But we're not there and it doesn't seem like Unity is moving in that direction.

 

I'm very curious about Unity's plans for C#-VS interop, and especially job system/burst interop.

I'm personally not a huge fan of UE4's approach to treating everything like an inheritance because of a rigid single-parent binding, but I can see the merit in its consistency throughout all its systems.

I personally would really like to see how Unity approaches it because having high-level systems inside VS makes it more accessible for designers to modify, while the low-level performance-sensitive systems can be handled inside traditional text-based code.

For that matter, I'm also very curious about the approach to a high performance interpreter. Will it have a C++ backend for added performance to the virtual machine, or will it be built on top of C#, which... already runs on the .NET VM.

 

I'm curious, would "High performance interpreter" allow in some way to make vs in runtime? I'm interested as loading C# dlls in runtime isn't possible on il2cpp.


Battlefield Portal looks interesting:

 

What do you mean? There are already IL, lua, python interpreters that work in il2cpp but aren't optimized.

From different thread:
Looking at trends more and more games allow players to be creators (roblox best example). There are many Unity games that refuse to add scripting as it's not cross platform (won't work in il2cpp ios). Hopefully that will change at some point. This should have a bit higher priority. As you can imagine players that end up learning and scripting in C# in a game would have pretty easy way of picking up Unity. In a sense it's a way of converting players to Unity users.

Worth saying that Unreal noticed it and they're adding new language for that exact purpose https://twitter.com/Nephasto/status/1340046706642186247/

 

Thank you, interesting. Hmm, maybe something simpler: what in a case where players will mod a game (using uMod for ex) in Unity editor. Could new graphs be loaded in runtime on il2cpp? That's what I understand from "enable DLC graphs" but in this case modders don't have access to a full project.

 

is there any support for async/await functions? I have a monobehavior class with an IEnumerator, that calls upon an Async/Await function.

 

I have high expectations for Visual Scripting.
What are the enhancements compared to Bolt at this time?

 

1. There's a rudimentary support for the new Input System package.
2. Renamed a bunch of stuff. Branch → If. SuperUnit → SubGraph. Flow Graph → Script Graph. Flow Machine → Script Machine. Macro Graph → Graph Asset. Control Input/Output → Trigger Input/Output. Value Input/Output →Data Input/Output. Self → This. Unit → Node. Assembly Options → Node Library.
   
3. There's also a new, flat'er skin with icons from the now defunct Bolt 2 (I think). Performance in editor might be slightly better than Bolt.
4. It can now create new graphs from the Graph editor window if no graph is selected.
5. Support for RenamedFrom attribute on enum members.
6. Graph Inspector and Variables windows are permanently embedded in the graph editor. You can't open them as separate windows anymore.
7. Unit regeneration option has been transfered from Tools/Bolt to Project Settings/Visual Scripting. In the process we've lost the manual option to Update Unit Options rather than doing a full regen. It's still exposed in the API, however. So you can add your own button for it.
   
8. On that note, AoT Pre-compile is now run automatically before building and also automatically cleaned up after.
9. Slightly better documentation for the C# scripting API as there are concrete examples for custom nodes.
10. A few dozen bug fixes that might or might not be an issue inside Bolt. I know I often get ghost Null Reference errors when selecting/deselecting graphs in an old project I have to maintain.This appears to be fixed in UnityVS.
    
11. A few new nodes:

• SetScriptGraph node
• SetStateGraph node
• GetStateGraphs node
• GetScriptGraphs node
• GetScriptGraph node
• GetStateGraph node
• HasStateGraph node
• HasScriptGraph node
  
  The changes so far are mostly bug fixes and superficial improvements. All the good stuff like the new runtime, the new UI, the variable management improvements, etc are all still ahead. But at the current pace, probably at least a couple years away from being production ready.

 

Thank you for your polite commentary!

After all, the integration with Unity is the biggest update.
It looks like it will take some time to implement the advanced features that Unity Technology is aiming for.

 

Crikey. If the new VS is really 2 years away that's very disappointing. I realise that you don't have an inside line but I know you have an excellent grasp of things so I listen to you.

 

They will release the alpha for the new runtime for testing later this year or early next year. And considering how engine releases work where they have planned everything, like 4-6 months ahead at least, that runtime is not releasing in 2022.1. Maybe in 2022.2. Can't happen in 2022.3 LTS since LTS versions of the engine don't include major new features. So in the worst-case scenario, it'll be stable by 2023.1.

The lead developer on the new high performance runtime has left the VS team for a different internal Unity project, so 2022.2 looks hopeful since most of the major work is done by now. I guess it largely depends on how stable the alpha test will be and if it'll require a lengthy beta test after that.

The current UI is still the old IMGUI based one. They intend to replace it with UI Toolkit based solution called Graph Tools Foundation. The GTF package has received no updates since July because they're now integrating that into the core engine as well. It might be in 2022.1 or 2022.2, but it's hard to say from an outside perspective. And by in, I mean available for use to other Unity teams. The integration with it is a whole different matter.

The Graph Tools Foundation package has been moving forward at a glacial pace because all graph based tools - Shader Graph, VFX Graph, the new animation graph, Unity Visual Scripting, etc - will migrate to it. So they have to support them all and communicate between several geographically scattered teams. I highly doubt the GTF migration will happen next year, especially because the VS team will be focusing on the new runtime, but maybe? My somewhat educated guess would be that this will happen sometime in 2023.

Unity have mentioned some other enhancements, like the variable management improvements and serializer tech migration from FullSerializer to Unity's native serializer, but that's not happening before the new runtime is in. So further improvements will happen either in the second half of next year or in 2023/2024.

Recently, I've started to doubt the direction of the package. It seems that Unity value backwards compatibility with Bolt and early versions of UnityVS (which is still re-skinned Bolt at this point in time) above all else. That means they intend to inherit some suboptimal design decisions from Bolt 1, like having the GameObject variables still be a separate component not tied to a graph. Which means you can't reuse graphs as easily as you can C# scripts because you have to manually recreate all variables on every reuse. That also has implications on their plans for variable improvements and making variables GUID based so they can be safely renamed and safely referenced. Can't really have GUID based Object Variables if they only exist on a GameObject instance.

I feel like they lack a strong creative direction for what VS should be. And it's extra frustrating because they have to solve the same issues Bolt 2 already fixed, albeit it also introduced a few new ones which the Unity approach avoids. The new runtime from a design perspective is a great piece of tech and I'd say it's more future proof than what Bolt 2 had. But at the same time, their thinking on the UI/UX and general UnityVS architecture, which prioritizes backwards compatibility with Bolt 1, is frustrating. Bolt 1, while great for its time, is not exactly the peak of visual scripting.

 

This is the most disappointing of all. I've used Blueprints and not enjoyed the experience. I guess it's the old problem of backward compatibility...

To be honest, I'd rather they ditched backwards compatibility for the new VS. Leave the Bolt/VS as it currently is and develop a high-performance, no-compromise visual architecture that is capable of supporting multiple stakeholders. Sure, we'll never want to use it for real in high performance games (complex conditional logic and looping anyone?) but there are dozens of genres that might have 100% visual games, not to mention the value to the dev lifecycle of collaboration and stubbing.

I'll be downloading the alpha on day 1 and trying it out because. I see great value in education (I'm teaching a new module at Uni starting this semester using VS) because I can separate language complexities from good games design practice. My young son can do far more in VS than he can in code, though I would expect that to change for all actors over time.

Thanks for your insights. Always very useful...

 

Part of the new interpreter is codegen, so that avoids old Bolt altogether which is a big reflection engine, and hence why when building to IL2CPP, Bolt seems to run at the same speed. While I haven't had the opportunity to test the new interpreter on IL2CPP yet (not currently working) I assume on top of the already massive speed difference (or loss of node latency which was always the issue), there should also be the improvements when building to IL2CPP as you would with normal code, especially if a whole graph can be amalgamated into a piece of code (one day) rather than per node. If the one is possible, I'm sure the other is too. Although, I think the direction is that it's still meant to be a visual interface for plugging high performance code together from an AAA perspective programmer/designer, rather than writing something completely using it. Although this is still very possible to write something completely using just a visual interface.

The main advantage of visual scripting over coding, is no compile time. I don't know how many times I've waited that 10 seconds after I changed 1 item in code! So it also means, if you are prototyping some high performance code that does something in particular, well at least you can find the best method of achieving the goal output before that. Also don't know where Visual Studio hot reloading comes into things, and whether that will also change the code/compile/play aspect, but I hope so!