Unity Visual scripting roadmap update - August 2020

I am not sure how I feel about that but seems like a good shift overall. I am happy that Unity realized that those things should be unified sooner than later. But I have some questions:

1. Does that mean that Bolt (let's skip the numbering from now on ) will have a backend refactor anytime soon? Currently, it relies heavily on reflection and misses type-safety (which was what I was most excited about Bolt 2).

2. How will DOTS fit here? The blogpost barely mentions DOTS at all, and now that the focus will be in Bolt it feels like we won't see a DOTS-compatible VS solution anytime soon, is that correct?

3. Which features should we expect coming to Bolt in both short-term and long-term? Bolt was in "maintenance mode" and all the new features were coming to DOTS VS and Bolt 2.

 

Well I’m going to be one of the first to say I’m disappointed. Bolt being visual had the potential to teach programming. But not really in the bolt1 format as it didn’t have a like for like mapping to actually coding it.
Bolt2 had that. It had speed. It had power and potential and I feel it’s all but thrown aside in the new plan

 

So this seems to indicate that DOTS VS won't be developed anymore and instead will be integrated into Unity Visual Scripting (BOLT Integrated) at some point in the future most likely when the DOTS API is stable since stability is the highest priority now. So essentially DOTS VS is gone until then.

Is this correct?

 

That must've been a tough decision. I haven't tried Bolt yet, and don't know how much version 2 was supposed to improve it, but for me this makes things clearer and more predictable, and so makes it easier to make decisions regarding visual scripting in the near future. Thanks for detailing the plans.

 

Wow, thanks for the quick response!

That was pretty clear for me, my question is more about "when" (like maybe in 2022?) we should expect it. DOTS-VS was in the prototyping phase and receiving some good improvements, now seems like we are back to 0 (which is for a good reason, but makes me wonder if DOTS support is something planned for sooner or later on Bolt).

 

The constant change of plans indicates that Unity lacks a clear vision.

 

As a person that spent many hours testing and discussing all the features and advantages of Bolt 2 that I was salivating for this is distressing news. I understand from a logistics point of view why you would approach your future plans this way, but is Bolt 2 completely dead? Or will it's features live on through your new road map?

Like Events in Bolt 2 finally made sense and weren't a wreck like in Bolt 1. The strong types, refs, enums, delegates and many other Bolt 2 features all gone? And most notably a "class" based structure. Is all that gone as well? Or will these things be put into this new incarnation of Bolt?

I see where you need to find efficiencies and stabilities in a long term outlook but are we throwing the baby out with the bath water?"

 

Hm, Bolt 2 code generation was the main feature I was looking forward to though.

The main problem with bolt to me was the lack of inspector tools, and how certain things that would work fine with code didn't work with bolt. Like for example PPSv2 might work easily with Bolt 2 but doesn't work at all with Bolt 1 (Without some written code to work with it).

At least for me I was hoping for a more unified experience between written code and nodes. I don't exactly need it to be easier as much as I want to make sure me using bolt connects well with a proper programmer.

Cause with bolt 1, if I want to hire someone to work on an aspect of my game, they would need to know bolt, but with bolt 2 it doesn't seem like they would.

 

I am not surprised by this at all. It was no secret that you guys would ruin Bolt. Fortunately there are useful alternatives like uNode that will hopefully see the developer choose to improve and expand to completely fill the gaping hole that you guys have left in the area of user-friendly yet versatile visual scripting tools.

 

Ah alright. I wanted to see how DOTS VS was positioned in the new VS system So what I'm understanding is Unity VS will use the style of nodes/Graph View that DOTS VS has (Front end - So it looks like the other VS tools) along with Updated Bolt (Monobehaviour backend) DOTS VS (DOTS backend) but this will be released in a later phase.

So Monobehaviour workflow first with a new UI based on Graph View and DOTS workflow sometime after. I was wondering when Bolt would be transitioned to the Graph view so this is a welcomed change.

Also, does this mean the DOTS VS Drops will stop and maybe replaced with preview versions of Unity VS leading up to the 2020.1 release of the new tool?

I'm not trying to push DOTS VS I'm just trying to see how everything fits. I'm patiently waiting for it to become solid.

 

How is it ruined? It's simply being integrated into the editor with a new UI for the nodes and with better performance. Nothing is being removed from the tool, your imagination is running wild here.

 

I was looking forward to using Bolt 2 along with my hand written C# code for being able to visually setup how the code interacted, a UML diagram that actually drove the code. Bolt 1 is lacking so many features for this and just seeing the features and things people were doing with the early Bolt 2 alpha in the Bolt Discord server, I thought it would finally be possible.... Hopefully you keep programmers in mind who want to utilize visual scripting as an additional tool in their belt.

 

Simple request:

Make Bolt 2 Open Source

 

I has been preparing to try out Bolt 2 to see if our team could use it in production. But today news pushes that plan further, we will stay with plain C# code for a while longer while keeping an eye on Bolt development.

 

Same situation. I even applied to the alpha and was willing to work towards making it production ready...

 

So my understanding is that Bolt2 is done, but the ideas/concepts from it we slowly be rolled into the core Unity VS (Bolt1). And im also understanding that DOTS VS is finished as well and its ideas for broader, artist-friendly nodes will be rolled into this new Unity VS. And Unity VS will freely work between gameobjects and DOTS.

Is this correct?

Though, Bolt2 seems mighty different architecturally, so i'll be interested to see how a lot of those performance gains, and workflow improvements manages to transfer over without breaking compatibility.

Was looking forward to DOTS VS, but these changes and integrations seem like they're for the best and looks to keep Unity simple. Can't wait to see the fruits of all of this. Good luck

 

I really don't get why Bolt 2 was thrown away for it being "too developer-friendly".

Isn't Unity3d supposed to be for developers anyway? I mean, don't get me wrong, I still love Bolt 1, but I feel like all the additions that Bolt 2 would've had would've been way better in any way, shape or form.

As Nembroten said, making Bolt 2 open-source would probably be a better idea than not releasing it at all.

 

Perhaps you didn't read the original post.

Bolt will become a dumbed-down visual scripting environment similar to Build Box.

Bolt 2, the one that we all wanted for various reasons, will not exist.

Unity has once again failed to keep the faith and deliver on what they initially promised for Bolt just like every other asset they acquire.

That is pretty ruined in my book.

 

Forgive me, but how exactly is this nonsense even remotely considered user first?

Unity has again completely failed it's users and been less than honest throughout the process. That is all that you guys have demonstrated.

 

Please consider this:
https://support.ludiq.io/communities/5/topics/2343-mandelbrot-like-infinite-zoom-and-free-real-state
I believe something in those lines could be a leapfrog for Unity regarding visual scripting instead of a try to catch up.

Also, I worry about the constant expression of "accessible for everyone" every time Unity programmers talk about VS. They've been condescending in this subject. I worry they see VS as a cumbersome high abstraction toy. At least consider what made Unreal develop Blueprints instead of Kismet. We need visual scripting with low level power.

 

Bolt 1 while great for beginners and some simple high level scripting is not fit for production for several reasons:

1. Editor performance dies if you're working with medium to large size state machines, large flow graphs or long lists of Bolt variables. I have to deselect anything Bolt related to test my games in Play mode because the editor can't handle it, it's literally a slideshow. Live mode preview and debugging become pointless if I can't have my graphs selected when I test my game due to this. Anyone will come across this a few months into a project.

This happens on an i7-6700k, 16GB DDR4 RAM, RTX2060 PC. It's not the fastest machine around but it should be more than decent to handle some graphs and variable lists so it's not my PC.

(While Bolt 2 has inherited some editor performance issues, it's much better already. Perhaps because variables are better organized and exposed, and because Bolt 2 encourages the creation of smaller, more reusable graphs)

2. Bolt 1 variables system is not good. It doesn't scale well - no way to organize, search, reuse or refactor variables. Since variables, graphs and custom events are separate concepts in Bolt 1 - while you can reuse graphs you have to recreate variables by hand on each object. Want to rename a variable? Go ahead, but now you have to hunt down all instances of that variable in all your graphs manually and change it there too. Bolt 1 variables are also loosely typed meaning that in graphs you don't actually see variable types and when entering Play mode variables with null values lose their types altogether. Reflected C# variables look more native in graphs than Bolt 1 variables.

It got so bad that I had to spend minutes scrolling around for that one Bolt variable in my long list of Scene variables, at which point I migrated all my variables to C# scripts where variables can be organized (separators, headers, etc), can be searched for(ctrl+f) and can be refactored. And god forbid you accidentally press that "-" icon next to a Bolt variable, there's no way to recover it.

(Bolt 2 fixed this by having strongly typed, strongly referenced variables. Renaming a variable would propagate that change to all graphs. You can search any graph for any variable. Accidentally deleting the variable from a class would let you recreate it from the node still left in a graph and any references in other graphs would automatically connect. Or just press ctrl+z after deleting the variable, this does nothing in Bolt 1)

3. Custom events are magic strings buried somewhere in your graphs - no way to search for them or refactor them or even have a list of them. I refuse to base anything on magic strings, yet I don't have a choice when it comes to certain state machine transitions.

(Bolt 2 fixed this by having strongly typed, strongly referenced custom events, creatable and visible right in the Graph Explorer window. Bolt 2 also introduced proper global events which Bolt 1 doesn't have)

4. Bolt 1 performance in builds is not good. At one point I needed 64 update loops for finalizing the design before optimization. I had 15fps in the editor and around 60 in a desktop build. Here I couldn't use Bolt 1 for prototyping, had to switch to C#. The event system especially is incredibly performance intensive in Bolt 1.

Here's a comparison between 100 update loops in Bolt 1 vs Bolt 2:

5. Fuzzy finder is slow and breaks when you add a lot of custom types of your own and/or 3rd party libraries.

(Bolt 2's fuzzy finder is much faster, smarter and all around better)

6. Bolt 1 doesn't support many important features such <T> generic types, delegates/callbacks, LINQ, arrays, etc. These missing features severely limits your ability to interface with your own code and 3rd party libraries on the store. And even if you want to integrate these yourself, Bolt 1 custom node API is not documented.

(Bolt 2 supports all of the above features not available in Bolt 1)

7. Adding your own custom C# types takes an immense amount of time. You have to rebuild the whole unit database just to expose a new script to Bolt. If you've already added lots of custom types, this can take minutes and makes me want to stick with either just Bolt or just C#. There is an Update Unit Options button but it only updates changes made to already added types. You have to run Build Unit Options every single time a new script is added. And while units are being regenerated, I can't do anything else.

(Bolt 2 fixed this with incremental unit database extract and general unit extract optimization)

8. Dealing with AOT Pre-Build for AOT platforms can be a nightmare. I can't make this work on cloud build at all because I have to run other pre-processors together with this as well.

(Bolt 2 was about to eliminate the need for this entirely due to C# gen)

9. Bolt 1 lacks essential debugging features. When you click an error in the console with Bolt 1 - nothing happens. It doesn't point to the faulty graph or node. Sometimes it points to the object the graph is on but not always. And if an object has multiple graphs you still have to click through them manually. And if the error is nested inside other macros multiple levels down, sometimes you can't see anything wrong on the top level at all.

(In Bolt 2 when you click an error in console it opens up the right graph, centers and outlines the erroring node. This was a pretty big breakthrough at the time.)

Bolt 2 fixed the above issues via optimizations and via strongly referenced and strongly typed variables and events, and the class structure. It also added a lot of quality of life features such as Graph Explorer which lists all your project's graphs, variables and events in one place and Graph Search which lets you search for any node, variable, custom event in the graph. And with superunit creation from selection and easier superunit input/output configuration simply by dropping value/flow connections on them. You do have to create a lot of superunits in Bolt 1 and it's painfully slow when compared to Bolt 2 or other assets like Flow Canvas.

It's mentioned that Bolt 2 was programmer centric - I disagree. I think a class like structure where graphs, variables and events are grouped together enforces much better practices by default and are in no way harder to learn for non-programmers. It makes you think in terms if reusable functions and everything you're looking for is in one place in the Graph Explorer. Bolt 1's lack of structure is not a strength, it's an immense downside - it lends itself to huge, strongly coupled megagraphs which spawn spaghetti memes. I don't see anyone complaining about Blueprints being programmer centric - it can do both heavy duty game logic and high level scripting.

What I loved about Bolt 2 is that it was a tool for everyone - you could absolutely make fully fledged games with it or use it as a tool for designers & artists tm. Now it seems Bolt is being designated only as a tool for designers and artists since Bolt 1 has a free form structure, limited ability for code reuse, no layer of abstraction, limited feature support, and a variables/custom events system that doesn't scale past gamejam projects.

Bolt 1 hasn't seen any meaningful feature updates for the past two years in favor of developing Bolt 2. Though I understand why the decision was made, it's tough to see all that progress gone.

 

Just for clarification, does that mean future VS tools won't support code generation in real time like bolt 2 does? I can understand that the current solution is hard to maintain, but the bolt 2 is one of the best things that has happened in the last few years to unity.

Also, about the upper point. Bolt 2 was a perfect tool for designers and artists, while It's true about more programming like approach, bolt 2 made a really great compromise between ease of learning and use, performance and amount of possibilities to create high quality, complex content. I would say the opposite, the DOTS VS should be totally redesigned because It's doing everything wrong in terms of what really matters for a visual scripting tool.

 

Just to this point:

It does seem like this is being considered. But like Unreal, they seem to want to have a lot of high level nodes that do a great deal of work under the hood, but have just like 1 or 2 inputs you need to interact with to get something cool happening on screen.

 

Bolt 1 and Bolt 2 already auto generates low level API nodes, it's the default way of working with them so I'm not sure what you're pointing out. The problem is not the access to low level API, it's everything else.

 

So what's suppose to happen with Bolt 1? I was under the impression Bolt 2 is to completely replace Bolt 1 since it addressed so many problems that Ex-Crow just mentioned. Wouldn't it be better to release the originally intended version of Bolt 2 to replace the out dated Bolt 1. And THEN work on a separated unified solution of Unity VS instead having us use an out dated VS like Bolt 1 as our main driver? Or do you plan to directly tackle all the major problems in Bolt 1 as Ex-Crow mention?

 

I belive all these decisions were made to move people towards their in house, terrible solution since their programmers already knows it rather than try to learn someone else, not finished product.

 

Yeah even as mainly an artist, I think a programmer centric approach is a much better long term solution. For me it matters more that a tool is visual not how simple it is, for me I want nodes to be as close to real programming as possible. The thing about all visual scripting is eventually, you reach a point where the nodes don't cut it as your general skill and understanding improves. The benefit of bolt 1 was how it felt like real programming for someone learning, the benefit of bolt 2 is that it is written code with a direct reference.

For my project I recently transitioned a big chunk of my bolt 1 nodes to c#, and a lot of being able to do that is thanks to learning bolt. But it wouldn't have been nessecary to do with bolt 2 I feel. And to me that is the most valuable thing.

 

Wow, this is hugely disappointing. I was really hoping for Bolt 2 and all its benefits to go forward, but it seems like this is a huge step back. Instead of going for all the improvements that were made with Bolt 2, they are going for the more simplistic and non-programmer friendly Bolt 1 option... that goes completely against some of the points you made though.

Except they will be working on something completely different if they are using something like Bolt 1 that can't convert to code or even work similar to actual code, which Bolt 2 simulates much more effectively.

So, I just don't get this decision at all. It seems like they saw the amount of work it would take to implement Bolt 2 and make it future proof and just decided to not do it and justify that with all these other excuses. Or am I missing something here?

 

oh i had no idea. Never used bolt, they said it like it was something Bolt hadn't done before...

 

I keep reading and all i see is "Yes, Bolt2 is better, we need to work on making Bolt1 and the rest of our VS as good as that" and all I'm thinking is "Why the hell is that since you already have Bolt2 on your hands?" . It's not making much sense tbh

 

You guys should occasionally poll your users on what they expect and how they want to use things XD

 

Would that amount of work be more than what you have to do with Bolt 1 today? Again, you are leaving the current users with Bolt 1. A tool that has been feature lock for years. Why not just release the originally intended Bolt 2 and work on the integrated VS solution behind the scenes? At this rate we will be stuck with Bolt 1 for many more years.

 

Thanks for the update and all your hard work Laurent and team! Could you explain what "snippet based nodes" are?

 

Honestly, i'd rather wait longer and have a tool modern tool that's going to withstand the next generation of Unity... not sure how many will share the same sentiment in here though.

 

Unity bought Bolt in order to bury Bolt 2.

 

But you gotta understand, to us bolt 2 was right around the corner, but now it's what at least 2 years away? And at least to me and others the benefits of what you said isn't as clear as the benefits of what Bolt 2 is.

"Developer friendly" is the more appealing moniker, else people who chose Bolt would have chosen playmaker or something.

Will Bolt 1 just continue to be basically on version lock until this new thing comes around?

 

That is where I disagree and tend to think that is repeating a mistake. Instead of finishing something that had users (even too many to give access to the alpha). You think you know better and are going for something, again new, with simplicity in mind for non programmers. So people using visual scripting won't get any improvement so you can make something for people who don't care.

 

great, so you are basically making bolt2 the best vs tool into playmaker branded as unity vs. may i ask why dont you drop bolt 1 and keep all your current plans of dots and bolt being integrated but with bolt2. the amount of features bolt has and its architecture of class based, cant be ported to bolt1 without breaking compatibility, and dividing and confusing your community even more. i dont disagree with unified solution, i disagree that its on top of bolt1. keep the same plans just do it on bolt2.