Search Unity

  1. Dismiss Notice
  2. Looking for a job or to hire someone for a project? Check out the re-opened job forums.
    Dismiss Notice
  3. Unity 2020 LTS & Unity 2021.1 have been released.
    Dismiss Notice
  4. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice

Unity Visual scripting roadmap update - August 2020

Discussion in 'Visual Scripting' started by LaurentGibert, Aug 14, 2020.

Thread Status:
Not open for further replies.
  1. LaurentGibert

    LaurentGibert

    Unity Technologies

    Joined:
    Jan 23, 2020
    Posts:
    137
    Hi everyone,

    We wanted to provide more details about our plan for Visual Scripting in 2021 and beyond, and get additional feedback from you. We would like to thank all of you for your dedication in engaging with us, and your direct and honest feedback.

    We will soon create a dedicated forum for visual scripting conversations.

    You can see the general outline of 2021 in this blog post:
    https://blogs.unity3d.com/2020/08/13/the-road-to-2021/

    Beyond the general excitement of bringing Bolt to all Unity users, many of you, on various forums and one on one discussions, have expressed concerns about the next steps for visual scripting in Unity 2021 and beyond for various reasons: incompatibility between Bolt 1 and 2; the role of DOTS VS; the fact that Bolt 1 is an asset and not a package. More generally, we’ve been asked how we will ensure both long term stability of this platform to secure your usage of it, while evolving it to the state of the art of visual scripting practice.

    Our ultimate goal for visual scripting is to make it as universal and accessible as writing a simple script, so that it:
    • Enables more creators, in particular non-programmers, to leverage Unity and achieve their goals faster.
    • Improves team collaboration by giving artists more opportunities to work directly in the engine, closer to developers.
    • Maximizes every Unity user’s productivity, by progressively unifying graph-based tools, regardless of the workflow (gameplay, graphics, animation…) and regardless of the architecture (Monobehaviour or DOTS).
    Quick recap of recent events
    We had been developing a DOTS-based visual scripting tool for some time, which would have excluded all Monobehaviour projects from using it. To accelerate delivering visual scripting to all users, we acquired Bolt, a proven solution in production. The team at Ludiq were already working on Bolt 2 which was in an alpha state. Bolt 2 was a complete rearchitecture and not compatible with Bolt 1. Bolt 2 promised better performance through code generation, and a deeper emphasis of programming concepts, among other enhancements.

    We’d like to share some of the aspects we needed to navigate, as this will help provide more context for the road ahead and why plans have shifted.
    • We needed a single visual scripting solution for all our users. There were 3 technologies that we needed to harmonize (Bolt 1, Bolt 2 and our internal DOTS focused solution). These were not designed to be compatible with each other.
    • Bolt 2 takes visual scripting towards a more programmer-centric approach, while our ultimate goal is to simplify the platform for non-programmers.
    • The Bolt 2 code generation process using CodeDOM had to be replaced by a more future-proof solution. Code generation for entire graphs also reduced our ability to support shipping non-DLC graph updates.
    • The Bolt 2 architecture wasn’t providing us with the best separation of front-end and back-end needed to ensure a progressive transition toward unified UX with other graph-based tools. A good separation is also essential to providing DOTS support, in the future.
    Visual scripting plan for 2021 and beyond
    We won’t ship Bolt 2. We will instead integrate Bolt 1 as a core feature of Unity 2021, so we can focus on evolving this platform in the direction of unifying all our graph-based tools. This milestone includes:
    • Shaping Bolt 1 as a core package that ships with Unity and progressively brand it towards Unity visual scripting.
    • Work on making the Bolt user experience align with Unity Editor UX.
    • Clarify and document the support, or non-support, of non-DLC graph updates, as well as visual scripting execution in editor mode. We wish to support both use cases, but there is still some on-going analysis in this area.
    • Complete documentation and learning content material.
    In subsequent releases, we will leverage the technical know-how acquired with Bolt 2 and Unity DOTS VS, to continue to transform Unity visual scripting in order to:
    • Deliver consistent workflows and a unified user experience across visual scripting and all graph-based tools.
    • Support MonoBehaviour & DOTS with high-performance, snippet-based, high-level artist nodes.
    • Support auto-generated low-level API nodes to preserve the flexibility to use visual scripting for any C# exposed library.
    Advantages of the updated plan
    • We are delivering visual scripting iteratively, meaning delivering concrete value today, while creating the conditions to support Bolt graphs as we move forward to a unified experience for graph-based tools. This also means you can safely build on top of Bolt, with Unity 2018 LTS, 2019 LTS, and 2020, because the data and acquired expertise will be forward compatible.
    • Starting with 2021, it will be safe to expect visual scripting to be available in every Unity users' environment, simplifying production management, and tools development using visual scripting.
    • Our development team will be more focused on fewer technology components, accelerating our work in unifying the UX of graph-based tools moving forward.
    Thank you
    We fully realize this update will be disappointing to those of you who were highly involved in the development of Bolt 2, and have been waiting for it for a long time. This was not an easy decision to make. We believe that the world is a better place with more creators in it, and delivering a unified visual scripting workflow incrementally with fewer disruptions, will help a wider number of artists and studios to be successful with Unity.

    We would like to hear from you, please send us questions, comments, and feedback.

    Laurent
     
    Last edited: Aug 14, 2020
  2. brunocoimbra

    brunocoimbra

    Joined:
    Sep 2, 2015
    Posts:
    588
    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 :p) 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.
     
  3. bugfinders

    bugfinders

    Joined:
    Jul 5, 2018
    Posts:
    208
    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
     
  4. LaurentGibert

    LaurentGibert

    Unity Technologies

    Joined:
    Jan 23, 2020
    Posts:
    137
    Hi @brunocoimbra,

    1. Yes backend refactoring is a major element of the transformation toward a unified visual scripting workflow working across monobehaviour and dots architecture. This and performance will come from implementing snippet-based nodes.

    2. Like quickly mentioned above, this is the main intent to provide one workflow, for any architecture. This is one of the main element of the rationale. I wish I would have been clearer about it, maybe I should rephrase some of the content?

    3. Yes, feature development is going to be focused back to the core visual scripting of Unity. This is definitely another element of the decision, enabling focus by being less divided across multiple technologies. In the initial drop in 2021, we need to complete a few things like doc and learning content, plus clarify editor mode usage and non-DLC graph updates. There are some UX adjustments planned too. Beyond this, please stay tuned for more update as we refine the plan.
     
    bguyl likes this.
  5. Grimreaper358

    Grimreaper358

    Joined:
    Apr 8, 2013
    Posts:
    741
    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?
     
  6. Oxeren

    Oxeren

    Joined:
    Aug 14, 2013
    Posts:
    95
    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.
     
    laurentlavigne likes this.
  7. LaurentGibert

    LaurentGibert

    Unity Technologies

    Joined:
    Jan 23, 2020
    Posts:
    137
    Not quite. Trying to not go into too much architectural details, and knowing that there are may technical options in front of us to still chose from, the Unity DOTS VS contains both a front-end and a backend. We want to reuse the front-end to unify our graph-based tools, visual scripting being the main one, and keep using the DOTS VS backend as its implementation for DOTS.

    It's really a phased approach. Bolt accelerate visual scripting API-level nodes for monobehaviour, while DOTS VS was visual scripting artist nodes for DOTS. and we will make those 2 meet in the middle so we can have both API and artist nodes, working for both monobehaviour and DOTS.

    Which tech is what doesn't really matter as we're focusing on a unified visual scripting. From the point of view of users, we aim at making those steps transparent.
     
  8. brunocoimbra

    brunocoimbra

    Joined:
    Sep 2, 2015
    Posts:
    588
    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).
     
    LaurentGibert likes this.
  9. Thomas-Pasieka

    Thomas-Pasieka

    Moderator

    Joined:
    Sep 19, 2005
    Posts:
    2,121
    The constant change of plans indicates that Unity lacks a clear vision.
     
    echeg, PutridEx, ElliotB and 21 others like this.
  10. ChrisSmith

    ChrisSmith

    Joined:
    Nov 3, 2016
    Posts:
    3
    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?"
     
  11. sacb0y

    sacb0y

    Joined:
    May 9, 2016
    Posts:
    302
    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.
     
    PlayCreatively, NathanielAH and Stexe like this.
  12. RadioactiveBullfrog

    RadioactiveBullfrog

    Joined:
    Jul 8, 2017
    Posts:
    51
    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.
     
    PutridEx, astearon and NathanielAH like this.
  13. LaurentGibert

    LaurentGibert

    Unity Technologies

    Joined:
    Jan 23, 2020
    Posts:
    137
    I can't tell a date. But VS for DOTS is already working. And we have now VS for monobehaviour. The limiting factor is our ability to bring them both together. This is not expected to be very hard, especially as we got a better focus with this decision. More details to come as we get closer to 2021 release.
     
    brunocoimbra likes this.
  14. Grimreaper358

    Grimreaper358

    Joined:
    Apr 8, 2013
    Posts:
    741

    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.
     
    LaurentGibert likes this.
  15. Grimreaper358

    Grimreaper358

    Joined:
    Apr 8, 2013
    Posts:
    741
    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.
     
    landonth and Lukas_Kastern like this.
  16. Samuel411

    Samuel411

    Joined:
    Dec 20, 2012
    Posts:
    642
    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.
     
  17. Nembroten

    Nembroten

    Joined:
    Nov 28, 2013
    Posts:
    9
    Simple request:

    Make Bolt 2 Open Source
     
  18. Laicasaane

    Laicasaane

    Joined:
    Apr 15, 2015
    Posts:
    75
    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.
     
    leni8ec and Samuel411 like this.
  19. Samuel411

    Samuel411

    Joined:
    Dec 20, 2012
    Posts:
    642
    Same situation. I even applied to the alpha and was willing to work towards making it production ready...
     
  20. Ofx360

    Ofx360

    Joined:
    Apr 30, 2013
    Posts:
    136
    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
     
    mysticvalleycsa likes this.
  21. Loupyboy

    Loupyboy

    Joined:
    Dec 23, 2015
    Posts:
    5
    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.
     
  22. LaurentGibert

    LaurentGibert

    Unity Technologies

    Joined:
    Jan 23, 2020
    Posts:
    137
    We're not expecting to stop the drops of DOTS VS. There might be some priority adjustment to reflect the convergence need.
     
    Grimreaper358 likes this.
  23. LaurentGibert

    LaurentGibert

    Unity Technologies

    Joined:
    Jan 23, 2020
    Posts:
    137
    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.
     
    landonth, ElliotB and laurentlavigne like this.
  24. RadioactiveBullfrog

    RadioactiveBullfrog

    Joined:
    Jul 8, 2017
    Posts:
    51
    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.
     
  25. LaurentGibert

    LaurentGibert

    Unity Technologies

    Joined:
    Jan 23, 2020
    Posts:
    137
    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.
     
  26. RadioactiveBullfrog

    RadioactiveBullfrog

    Joined:
    Jul 8, 2017
    Posts:
    51
    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.
     
    Kennth, astearon, Mark_01 and 4 others like this.
  27. andre-ivankio

    andre-ivankio

    Joined:
    Mar 29, 2010
    Posts:
    53
    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.
     
    Last edited: Aug 14, 2020
    PutridEx, SenseEater, Kras and 14 others like this.
  28. Ex-Crow

    Ex-Crow

    Joined:
    Aug 14, 2020
    Posts:
    111
    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.
     
    Last edited: Aug 17, 2020
  29. banan1234

    banan1234

    Joined:
    Mar 31, 2018
    Posts:
    119
    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.
     
    Kennth, Gekigengar, Mark_01 and 4 others like this.
  30. Ofx360

    Ofx360

    Joined:
    Apr 30, 2013
    Posts:
    136
    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.
     
  31. Ex-Crow

    Ex-Crow

    Joined:
    Aug 14, 2020
    Posts:
    111
    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.
     
  32. dre788

    dre788

    Joined:
    Feb 15, 2013
    Posts:
    51
    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?
     
  33. banan1234

    banan1234

    Joined:
    Mar 31, 2018
    Posts:
    119
    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.
     
  34. sacb0y

    sacb0y

    Joined:
    May 9, 2016
    Posts:
    302
    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.
     
  35. Stexe

    Stexe

    Joined:
    Feb 2, 2014
    Posts:
    186
    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?
     
    SenseEater, Kennth, astearon and 6 others like this.
  36. LaurentGibert

    LaurentGibert

    Unity Technologies

    Joined:
    Jan 23, 2020
    Posts:
    137
    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.
     
  37. Ofx360

    Ofx360

    Joined:
    Apr 30, 2013
    Posts:
    136
    oh i had no idea. Never used bolt, they said it like it was something Bolt hadn't done before...
     
  38. LaurentGibert

    LaurentGibert

    Unity Technologies

    Joined:
    Jan 23, 2020
    Posts:
    137
    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.
     
  39. HitsuSan

    HitsuSan

    Joined:
    Sep 28, 2014
    Posts:
    124
    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
     
  40. LaurentGibert

    LaurentGibert

    Unity Technologies

    Joined:
    Jan 23, 2020
    Posts:
    137
    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.
     
  41. sacb0y

    sacb0y

    Joined:
    May 9, 2016
    Posts:
    302
    You guys should occasionally poll your users on what they expect and how they want to use things XD
     
  42. dre788

    dre788

    Joined:
    Feb 15, 2013
    Posts:
    51
    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.
     
  43. homemech

    homemech

    Joined:
    Mar 14, 2016
    Posts:
    6
    Thanks for the update and all your hard work Laurent and team! Could you explain what "snippet based nodes" are?
     
  44. HitsuSan

    HitsuSan

    Joined:
    Sep 28, 2014
    Posts:
    124
    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.
     
    PlayCreatively and OCASM like this.
  45. TextusGames

    TextusGames

    Joined:
    Dec 8, 2016
    Posts:
    413
    Unity bought Bolt in order to bury Bolt 2.
     
  46. LaurentGibert

    LaurentGibert

    Unity Technologies

    Joined:
    Jan 23, 2020
    Posts:
    137
    Thanks.

    It is higher level nodes that already have a code implementation as opposed to be code generated automatically. This enable us to provide performance, runtime graph updates, and different implementations for different project architectures.
     
  47. LaurentGibert

    LaurentGibert

    Unity Technologies

    Joined:
    Jan 23, 2020
    Posts:
    137
    I understand how you can feel this way but simply no. We invested all our efforts in trying to release Bolt 2, but decided to throw away this work for the interests of the largest user base possible.
     
  48. sacb0y

    sacb0y

    Joined:
    May 9, 2016
    Posts:
    302
    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?
     
  49. sinushawa

    sinushawa

    Joined:
    Dec 8, 2012
    Posts:
    3
    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.
     
  50. parrotsgame

    parrotsgame

    Joined:
    Apr 9, 2018
    Posts:
    6
    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.
     
Thread Status:
Not open for further replies.
unityunity