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.
We’re not expecting to stop the drops of DOTS VS. There might be some priority adjustment to reflect the convergence need.
We understand the feeling @Thomas-Pasieka , as part of a major refocus of our teams on being users first, we had to oppose landing Bolt 2 and creating long-lasting technology silos for our users, or focusing on the incremental path forward to unification, and we have decided to chose the later.
We hope to clearly demonstrate in the next steps how this materialize. Thanks for sharing.
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.
This decision does not mean Bolt 2 features were wrong, or its solutions not appropriate. We are choosing to build visual scripting incrementally, learning from some of our past mistakes with siloed workflows that were pushing the risk to users.
So yes, this mean we will be using the smart solutions of Bolt 2 moving forward, but not delivering Bolt 2 as it is.
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:
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)
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)
(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)
Here’s a comparison between 100 update loops in Bolt 1 vs Bolt 2:
(Bolt 2’s fuzzy finder is much faster, smarter and all around better)
(Bolt 2 supports all of the above features not available in Bolt 1)
(Bolt 2 fixed this with incremental unit database extract and general unit extract optimization)
(Bolt 2 was about to eliminate the need for this entirely due to C# gen)
(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?
Thanks for the long post. Many good points in here. I want to emphasize the fact that Bolt 2 is a great piece of technology. But we also need to learn from past mistakes, including how we have been dividing our community by siloed tech stacks, and the main rationale of this choice is to avoid this mistake again. The important lessons from Bolt 2 will live moving forward as we incrementally push visual scripting to a better place.
I would still like to comment on the various points, but please don’t consider the following as arguing how Bolt 2 was, just as how we will try to bring incrementally visual scripting there.
We expect to address performance using snippet based nodes as opposed to global graph code generation. In our recent experimentation the gains are similar but provides multiple advantages such as the possibility to update graphs at runtime without shipping new binaries, as well as providing several implementations for various technologies, in our case monobehaviour and DOTS.
This is a good point, we’ll need to work on our solution here, in the direction of unification with other graph-based tools.
Yes, this is also a bad limitation of Bolt 1, same thing, we will progressively bring this to the next level as we unify our tools.
Same point than the #1, on top of what I said already, we are opening the opportunity to consider DOTS evaluation even when graphs have been designed on monobehaviours.
Yes, we needed anyway to replace the Bolt 2 one with the global search tool in Unity. We will need to do this with Bolt 1.
Point taken. We need to fix our documentation.
oh i had no idea. Never used bolt, they said it like it was something Bolt hadn’t done before…
We will have code generation in a different way, by providing snippet based nodes. But we are likely to not provide a preview for an entire graphs in real-time.
Thanks for the honest sentiment. We will definitely have more conversations on those design aspects. Please remember the whole rationale is made of numerous point. We would have been able to solve one or the other independently, but all together it was a better choice to slow down and deliver visual scripting more incrementally for the benefit of the entire community.
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
Yes, we will build the next steps on top of Bolt 1. We understand it is difficult to see how the “new better version of Bolt” could make us move backward, but this is what we discovered after months of hard work on Bolt 2. We wanted to release it, but the amount of work we had to do in deconstructing Bolt 2, added to the siloed situation with the entire community, was making this move going against the best interests of all users.