Official Visual scripting roadmap update - August 2020

In my opinion this whole decision isn't directed to provide better solutions for the users but simply a monetary directed result. Before they announced this new roadmap, they had to support 3 different VS tools, VS DOTS, Bolt 1 and Bolt 2. The thing that has been already teased many times here, bolt 2 isn't anywhere near the public beta, or even 1.0 release which means it might not come to the 2020 LTS version.

This could mean for the unity team, they have to support bolt 1 until 2020 LTS gets EOL, in 2022. On top of this, bolt 2 can possibly take so much time to develop, DOTS VS will actually get their own "1.0" release (which still will be a pointless toy in my opinion). There are obvious potential workarounds on this problem (like, developing bolt 2 till 2020 LTS as a package, finishing it and only then implementing it inside of the engine) but they decided not to for some reasons.

 

I strongly agree. There's a lot of distressed users who are operating under the assumption that the entire integration will simply be Bolt 1 and not a mix of the available technologies. This was definitely a communications misfire, but also a learning experience.

...having said that, this is the nature of direct business-to-user communication styles. I doubt any of any of Mr. Gilbert's posts have gone through any PR person at all; they're not formal and ambiguous enough for that.

 

Yeah same here. I bought Bolt TWO WEEKS before the acquisition with the sole intention of only ever using Bolt 2 (alpha). I never had any intention of trying Bolt1 after much research regarding its performance due to code reflection, and the difficulty communicating between graphs, as well as incorporating your own types/scripts/interfaces. I considered my purchase an investment in Bolt 2 while having access to the alpha progress.

I've submitted a ticket for an asset store credit (not even asking for a full refund) as I feel robbed. No response in a day so far, we shall see, but I don't have my hopes up that they will care.

 

Indeed.

Bolt1 is in serious trouble (as highlighted here, but can be fixed over time) and bolt 2 is not finished (and also has serious integration issues) ...

Therefore, unity would use the "ready" bolt1 as a visual solution until integration into 2021.x (Correcting its defects and integrating the bolt 2 DOTS VS features into it)

Or (as is being discussed here) use bolt 2 as a new solution / tool to be more robust than the current bolt 1, and try to build it by 2021.x

...

(The difficulty is really having the best of both worlds in just 1 tool)

 

They don't even generate code anymore, alongside drop 8 (I think) they decided to stop doing that. Since then they have done many updates for back end and some event nodes but that's only it. Their whole direction has been moving towards copy pasting blueprints without understanding it. Their big problem is actually lack of friendliness for newcomers and total lack of flow of information inside of the graph.

I personally believe that while drop 6 with vertical approach and c# generation wasn't a bad idea, It definitely was a bad execution, but the team behind VS DOTS aren't to blame in this case. Main problems with their tool were:

- too low level scripting, it wasn't even that but a visual programming which took care of syntax.
- DOTS and It's boilerplate.

Something that has to be clearly understood, bolt 2 can achieve so great c# generation not only because of the previous developer's hard work but because current monobehaviour is simple, clean and easy to get into. Something I can't really say about DOTS. In the current state of unity engine, old monobehaviour already brings “performance as default” for over 80-90% of tasks the average game does and the point is, they can be done quickly. DOTS on the other hand is really performant but with so terrible usability It should be considered only when you have something really heavy, running every frame, and can’t be optimized with c# jobs.

And this is the point why DOTS VS doesn’t have any reasonable future, doesn’t matter how hard they are going to try, the DOTS isn’t focused on usability and by far any tool created for this system isn’t either, especially their VS implementation which is the most “programmer” approach to the VS I have ever seen.

When the team will try to make the performance good, it’s going to contain too many, pointless programic nodes, which will only add a boilerplate. If they are going to implement something directed on ease of use, they will have to remove most of the dots concepts. For now the team decided to stay in between which makes this tool a sad joke.

 

+1 for completing Bolt 2

 

I'm not as big of a customer as some of these studios, but I've been paying for years just like many people on here. And as a paying customer, I'm extremely upset. In the beginning I expressed concern that I expected this to happen and it has come to pass; namely, not delivering timely and / or what was promised / expected.

Invariably, what I want is what you said you were going to do back in May. Which is to convert, finalize, and package / release Bolt 2. You want to go deliver on some other grand vision after that, then fine. Integration sounds great. Combined visual scripting solutions, strong products, etc. But that doesn't address what I and I believe a broad swath of the community wanted, which is just what you stated was going to be done; deliver Bolt 2.

Until we're talking on that wavelength, the rest is just noise IMO.

Thanks.

Sincerely,
Nathaniel

 

To address it even further:

So a version of Unity that is over a year away from even being release, let alone in a "verified" state is when Unity plans to be done with it?

That's not to skip over the explicit statement that Unity is not going to do what they said they would, which is deliver Bolt 2. Just a further example of Unity thinking it knows better than its customers what they want.

And to be fair, I love the vision. I think long term an integrated VS and DOTS solution is great. I'm thrilled about what DOTS will do. But that's years from now. YEARS. And ECS / DOTS has been in development for YEARS (announced in 2018) and is still not fully functional. You want us to sit around for YEARS while you deliver Bolt 2 which was already alpha / beta according to previous statements?

This "delivering a unified visual scripting workflow incrementally" has nothing to do with delivering Bolt 2. That is a vision of something that is going to take the YEARS previously indicated to develop; in the interim we're left with nothing. Bolt 1 doesn't hold a candle to Bolt 2; not even a flicker. So until 2022 effectively, based on Unity's release cycle, we're supposed to wait and have faith? Forgive me if I stopped being a believer with the debacle that is SRP.

• "Will help a wider number of artists and studios to be successful with Unity" and it doesn't help anyone if it's in 2022. We're in 2020 now. And I'm not kidding about the timelines; y'all admitted as much here:

For Unity 2020.1 our guiding principle has been to make Unity an even more reliable and highly performant platform, to help you realize your creative and business goals. In this blog post, we will highlight some of the new improvements, whether you plan to take advantage of them now or wait until Unity 2020 LTS next year.​

That puts a full, "validated" LTS release of Unity 2020 unto 2021 and Unity 2021 in 2022. That's just insane. If you're committed to not delivering until things are fully fledged products and only do 2x tech releases annually, we're looking at late 2021 / early 2022 for an early 2021 tech release with the first version of this combined Bolt 2 / DOTS VS. That. Is. Insane.

Invariably, I don't know I can further expound upon how angry this has made me and reticent to continue my subscription any more. Unity didn't listen, I don't honestly believe Unity is listening now, and I have little faith Unity will in the future. In my experience, fill one hand with fulfilled wishes / dreams / hopes / promises and the other with... stuff... and see which fills up first.

Who knows, maybe I'll be proven wrong, but even a broken watch is right 2x a day.

Sincerely,
Nathaniel

 

This is the answer. Right here.

 

On the Discord uNode was mentioned as a good Bolt 2 alternative. Might check that out.

 

The Bolt 2 has fundamentaly different architecture that tries to fix most of the flows of VS. Bolt 1 will never have this architecture and will have its known flows in its core, no matter how many cosmetic improvements will be done.

 

That's exactly what I'm saying. You aren't wrong at all, Bolt does have a ton of flaws in its Core. That's why Unity is probably going to change Bolt's API and backend significantly to fix serious issues and unify the developers of Bolt and DOTS VS. Bolt in 2020 is not going to be the same Bolt in 2022, I can guarantee it.

 

In this forum, I often see the name FlowCanvas.
Can uNode be a good choice?
I've never used either.

 

• Yeah, good idea.
  
• There is not a single thing wrong with the programmer-centric approach. Please keep it as it is.
  
• This seems to be the problem for Unity, isn't it? Because Unity needs to merge DOTS VS and BOLT2. While DOTS VS cut the code-gen out, Bolt 2 has it. So Unity chose an easy way; removing code-gen instead of having to develop one that can handle both normal monobehaviour and ecs. Either way, I don't care about code-gen if you can keep the performance aspect. But most people here seem to be afraid that without it, they would not get native c# performance?
  
• Understandable.

 

@LaurentGibert I’m sure you expected all of this, but from a business point of view, would even 200 pages of customers recommending you finish and release Bolt 2 make any difference whatsoever, or has the decision irreversibly been made by some higher power who’ll never be convinced?

 

100% agree. I feel like they're going to either regret this or turn a blind eye and continue down this path and face losing more people to UE.

Bolt 2 is far superior in pretty much every way.

 

This thing reeks of “strongly negative community reaction”.

 

@LaurentGibert

The reason Bolt 2 was in development was to fix all the flaws in Bolt 1's core. I don't get it. Why go back to a version that is stable but is known for its problems in its core when there is an improved version that is so much better to work on.

Wouldn't it be better to take Bolt 2 as a start and announce that it will be changed to fit the other Unity VS tools. This way the core of Bolt is robust and scaleable and the Unity team can iterate/refactor it to work with the other Unity tools.

I think the Unity team will encounter a lot of problems when they take Bolt 1 as basis which will result in delay of new features instead of using Bolt 2.

 

Bolt 2 is what we all wanted, that is pretty evident from the feedback here

And we want the UI look like the bolt 2 and not not like something else

 

Honestly for me this is the straw that broke the camel's back. I feel betrayed.
Unity seems to forget we are customers, we are actually the ones that gives the money. It would be nice to feel like the clients and not milking cows.

I will never trust Unity anymore and will start my next project with Unreal Engine. In the meantime I will use uNode.

RIP Bolt, it was nice using you. And also RIP Unity.

 

I like to point out that the roadmap of 2018 already had the visual scripting planned for 2019.2 to be in preview
It was based on mono and could generate c# and it looked neat

I don't know what happened but in the mean time we have nothing usable yet.

I think bolt 2 was the closest to this roadmap design and therefore I hope bolt 2 will be released as it is right now.

And then iterate on top of that.

 

Hello. Where is Forum now? How to ask quation and report bug for each owner of bolt? Reporting to Unity is too long waiting

 

It eventually got delayed due to the decision of making it DOTS-exclusive:
https://forum.unity.com/threads/uni...cripting-in-2019-2.577084/page-2#post-4146832

Now we have those experimental drops...:
https://forum.unity.com/threads/dots-visual-scripting-experimental-drop-11.944793/

...that will be based on

2020.1

from here on:
https://forum.unity.com/threads/moving-dots-to-2020-1.910931/

.

 

Unity really dropped the Bolt on this one.

 

If you don't want Bolt2, please do an asset sale for all VS

 

Think I might just go back to Playmaker, until this has all been sorted.

 

Or Flowcanvas, I really can't stress how much better and actually stable it is in compared to Bolt 1.

 

But what we'd really like to know is, will it make any difference?

 

You are already in it, now the visual script has its own forum there in the general tab of the unity forum

 

If you do care about community feedback I really hope you listen to this universally negative feedback towards this decision and rescind it or at least walk it back a little.

This quote in particular just shows a complete lack of comprehension as to why Bolt has stood out above every other visual scripting software out there:

There are already plenty of tools for artists in the unity marketplace, but Bolt expands on that to give programmers as much functionality as possible. THAT'S why people actually use Bolt and not other low-functionality scripting tools. I'm a year and a half into making a high-level physics game with PUN2 networked multiplayer using nothing but Bolt--not even Unreal has scripting software that can do that. You guys have a chance to create something truly revolutionary for the video game industry, but if you gut Bolt and make it into some mediocre slop that artists can plug their animations into you're not only going to lose the entire community's support, but you're going to make something so useless that artists won't even want to use it.

If you want to add some more functionality to the existing Bolt/Bolt2 framework for artists to plug-and-play their animations sure, that sounds great, but for god's sake don't F*** this up like Unet or every other IP Unity acquires.

 

So I found my receipt for Bolt dated November 27, 2017 7:33 PM, was when I got it. Basically 3 years ago,
when I was then 59, Bday is august. I made One post about how I had used playmaker, but found Bolt so
much easier and I was slowly learning how to kind of code, just by using Bolt ( human naming ) For any one that want to see my full post it is here >> https://forum.unity.com/threads/bolt-visual-scripting.482621/page-4#post-3403264

The essence of the post was this. " But man I would have never been able to do some of the things that I can do in Bolt,
without understanding coding. The simple combination of Realistic FPS and Emerald AI 2 , I could not get the RPFS to
remove the Dead Emerald AI agents. Bolt made this possible for me, simple as that!!! " I only found Unity Dec 2014 and
only do this as a hobby, but like everyone else, I was super excited about the soon to be Bolt 2!! For some one that cannot code at all,... even having the output of c# in bolt 2 to make a cube spin put a huge smile on my face

I am with many others here that say as " user's " they want Bolt2 with c# output, asap. The Bolt Ludiq team for sure would not have been taking another possible 2 years to finish bolt2. And as i hinted about my age and when I got this, well there is a possibility that I will never see Bolt2 or the output to c#. Sorry to say this, but it seems whenever Unity get involved things and features take forever and never really get finished. There have been more than once Unity has disappointed me, saying it is for their customers and user base, though it seems at times it is just to make more money in the long run, by forcing people to seek other ideas/assets while Maybe Unity will get it right.. " think GPU baking and the asset bakery " I know or have faith they were not doing it for this, but it feels like Ludiq was going to get bolt2 with c# output very soon and they wanted to stop that.

I am with others here that suggest, just leave Bolt one as is now, pretty much. Develop Bolt2 now and just get it working and stable on its own. Then When / if the back end gets to where Unity wants.. then simply incorporate Bolt 2 at that time.
Or if needed work on 2 versions on bolt2 when the time comes to hook it into the backend.

I got Bolt for the ease and reflection it could do to make units from 3rd party assets. I been waiting for bolt 2
since it was first talked about Oct 29th 2018, https://forum.unity.com/threads/bolt-visual-scripting.482621/page-5#post-3835579 In other words a long time now.

I am beyond disappointed. And I found that I also got Flowcanvas in the humble bundle. It has reflection and I'd be willing to bet if they wanted, they could try and get c# output and sell many more copies.. or even make an add on for Flowcanvas that will output C# and that way they could make a ton more money on flowcanvas, that is if it is possible for them. Even so I will learn flowcanvas ( It has reflection as well ). I am not going to waste time on a " maybe " when we get around to it, kind of thing.

Another 2 years to just to be able to output c#, now, just seems, like others have said, " it feels like a cruel joke ".

 

They didn’t exactly improve probuilder or progrids (in fact they might have made them worse)

 

It's pretty apparent that @LaurentGibert and his team really have no clue what is in the best interest of the community. The community has spoken and it's a unanimous no from us. So, how are you going to rectify this mistake that you've all made? This isn't the time to dig in your heels just because you think it's the best thing. Listen to your community or lose our business.

 

I am pretty sure that is why dark theme was released the day before. To try and soften the blow.

 

A reminder I did make one here cause i felt it might give a clearer idea to unity. Original post is on page 3.

https://www.strawpoll.me/20773406

 

Man, I´ll take your words as mine. I feel just like you,...

 

I bought Bolt for BOLt2.0. I have been waiting for it for more than half a year, but now you have killed it by yourself. I want a refund or open source!I'm sure that's what a lot of people like me thought when they bought this plugin!

 

In addition, compared with ASE and SF, your ShaderGraph is really bad in terms of humanization, which seems to be a common problem of your official plug-ins of Unity3D.

 

Let's keep this on topic. Railing on the engine is pointless. Unity have been and keep producing a lot of useful features that weren't assets before all the time.

 

I also purchased bolt and I feel cheated right now. The community was told that bolt 2 was going to be shipped. Not scrapped. Open source Bolt 2.

 

Its quite simple. Unity main income is coming through assets. If they give us now the perfect visual scripting solution, nobody would buy playmaker, flowcanvas or any upcoming visual scripting solution. Why would they slay their golden hen? Assets is the focus of Unity. Sometimes I think they keep unity so featureless so we all sheep buying assets for the engine so we can use it. Unity Light? Horrible, buy Enviro Sky or XYZ. Shadows? Nah, by Asset XYZ. And so on.

 

If many core development assets are paid, not integrated well into the engine and have questionable 3rd party support then new users/studios will try other engines first that offer these features built in, officially supported and, yes, free. Your conspiracy theory does not hold up in the actual world of game development. Unity are interested in shipping well rounded 1st party tools and this directional change reflects that goal.

 

What team of experienced developers will develop Bolt 2 full time without any financial backing? I guess if it's a permissive licence like MIT someone could take it and put it up on the asset store under a different name.

 

YES!

 

This is my feelings on the matter.

You hit the nail on the head with "structural" and "organizational" there. I am simply disgusted with a requirement to write custom nodes that are meant to _restructure_ my project for a small bit of customizable behavior for a tiny momentary change in gameplay (generally provided by a global system, such as player movement) -- for a one-shot (level-specific) behavior (i.e. where I need the player to behave like an enemy/NPC momentarily for an "escort mission" or something.)

Again -- this is where the "tagged-component" approach I keep mentioning saves the day.

Otherwise: custom nodes, custom-nodes, and _more_ custom nodes.

To create a custom node for these sort of things gets out of hand -- fast.
Yet modern games are _littered_ with these level-specific gameplay requirements.
@LaurentGilbert : being a gameplay dude, I imagine you know about this problem pretty thoroughly, right?
I mean... you do know this problem well... right??

I disagree on this -- and I can prove it.

Performance does not have to be hindered by the form of scripting -- as long as performance is considered in the visual scripting workflow design itself.

This is why everyone wants Codegen.



@LaurentGibert

To be clear, the only reasons we want "codegen" are because want the flexibility to tweak code (if we need to) -- but more importantly, we want our code to be as performant (and as flexible and as compatible) as real code.



My design for the implementation of a VS solution foregoes custom nodes for a Data-Oriented (ECS-like) approach to Visual Scripting, and does not compromise performance in any way, thanks to its lack of reliance on custom nodes for unique behaviors -- which again, focusing on custom nodes to handle your 'tweaks' to unique level / coding situations brings out the tedious requirement of making tons and tons of reusable nodes for each and every situation. If this is "by design" -- you have doomed your Visual Scripting Language.
After all -- if this "custom nodes/actions" thing was a good solution, I'd go back to Game Maker's UI in the early 00's -- It had the best (non-node-based) scripting solution out there -- and it was flexible as hell.
But it wasn't perfect.
It was limited in the same ways node-based solutions like Playmaker are -- except _without_ the spaghetti nightmare (which was always a plus to me!)
But ever since node-based solutions were born, everything's always been the same 'solution' -- "custom node" this and "custom node" that.
Why? -- Because of the novelty factor.
But that "novelty" is quickly wearing off -- at least judging from the responses in this thread.
People mention NodeCanvas/FlowCanvas because Playmaker had the exact same problem -- "Look, ma! -- No scripting!!" -- and yet, the exact _moment_ you want to add unique behavior to a repeatable action just ONCE in your game -- and then perhaps change it up in a big way later -- It is at this point where your game's _architecture_ kicks your ass.
Despite its great VS approach, this was a HUGE problem in Game Maker because it's "nodes" (or "actions" dropped into a sequential list) were so freeform, and there was no way to hit _every_ relevant bit, but remove _some_ behavior that wasn't necessary at the moment. No visual-scripting interface, node-based or not, can solve this problem -- at least without revisiting the _entire idea_ of what it means to _script_ in the first place.

You should probably consider me in this process -- I can probably verbalize some things for you pretty well, and give a few technical reasons why there is a better way. However, an hour-long session is probably not enough. So perhaps set aside at least two or more. I promise it will be worth your while.

 

I wouldn't read much into this beyond "People are so baffled by this decision they think this conspiracy is more rational than Unity just missing a seemingly obvious mark again"


As a side note, in reply to the above post, i totally get the "no more custom nodes" thing, which was part of why I like bolt 1 cause it would just read code no need for a special node. But even that doesn't stop the eventual dev problems that could arise which prompted me to convert most of my nodes to C# in the first place so i could hire a proper programmer with less issues.

 

I purchased bolt 1 to get the promised bolt 2. I dont care about bolt 1.

 

Are you sure about that? The way it reads they are going to a more non-programmer and easy to use system that isn't designed for full game production, like Blueprints or Bolt 2 could be used for. It sounds more like a way to teach people basic coding and get non-programmers to do a little bit of stuff instead of actually being visual scripting.

 

Plenty of companies maintain open-source projects that they don't necessarily earn any money from. It's not always about monetary gain when it comes to open-source. Open sourcing has it's benefits in that they won't necessarily need to dedicated resources full-time because anybody can contribute. Of course Unity won't do this considering they want to make this a deeply integrated feature of their ecosystem, meaning they can't open source it due to all the other things being closed-source.

 

Blueprints system is production ready, but this is only because of the amount of high level nodes and overall maturity their system has. Almost every major release of the engine brought a bunch of nodes, some of them even giant redesign/ cleanup of them.

What's more, with blueprints and python you can create custom nodes to manage workflow between different programs. As far as I know, neither bolt 2 nor DOTS VS are allowing for such possibilities.