Official Visual scripting roadmap update - August 2020

Unreal engine use this approach and they stated few things about it:
- Their VS implementation is around 10 times slower than pure c++
- The overhead doesn't come from nodes, but from connections
- the more connections, the slower scripts gets, because of this in blueprints, user should always avoid loops and scripting something like AI. This is very limiting for both visual scripting and game design.

And this is a really huge step backwards, something like this can be easily overlooked by the designers and programmers which have never worked on creating VS. This feature doesn't look like something big or even necessary at the first glance, but the thing is. When VS is supposed to be an primarily tool for artists and designers which doesn't know how to code, any visual scripting is just programming language, and sooner or later when they will learn their first programming language, they can jump to c#. This actually happens a lot in many teams, people switch to visual studio because it does have better UX.

Now, this seemingly unimportant feature was supposed to really speed up this process. In my opinion bolt 2 was a truly "nextgen" visual scripting tool and this is a real shame that right now, we are going back to the current generation for absurd reasons.

 

Everything 100% of what Ex-Crow said, but *especially* this:

A class is not a complicated concept to explain to artists. I've been teaching introduction to programming for gamedev to 15 year olds these past months. Artists aren't retarded, they can learn how to use a mildly more complicated system in the same time it would take them to learn the Bolt 1 system. Except with NONE of the massive, massive limitations and architectural issues Bolt 1 has.

One wonders if the Unity team even tried to make a serious production project with Bolt 1? I'd bet *NO* since they also never do production projects for anything at Unity, apparently. Well I have, and it ain't pretty. Had to give up on Bolt and redo everything in C#. That was *fun*. And then didn't touch Bolt for over a year, just looking sporadically at Bolt 2 progress.

Now you're wiping out all that progress with Bolt 2 *and* by releasing Bolt 1 free are knowingly subjecting Unity's entire unsuspecting userbase to the inevitable fate that they coded their entire game in an inefficient, slow and unrefactorable system? This is literally the *opposite* of being user-friendly.

Forward incompatibility of Bolt1 to 2 is far, FAR preferable to developing a project based on a knowingly dysfunctional system. On the surface people would probably whine about it, but in the end the architectural changes make up for it a hundredfold. And the amount of complainers would be small because the *paid* Bolt userbase was small compared to the now entire unity userbase.

I was concerned when Bolt was bought because I feared the development would be hindered by Unity. When they announced they were releasing Bolt 1 I was very disappointed, and people were saying I was being too negative, but it made no sense why they would release a known flawed tool when there was a basically a much superior feature complete update that required some polish. And now this...

Someone mentioned they should open source it. That would be fantastic. Then the superior system would truly win, Bolt2 as originally envisioned, or UnityBolt (maybe in 2023). But since they paid for it, I sincerely doubt it.

 

Bolt 2 was at least a year away from being production ready too. So time frame differences are not as huge as one might think.

 

Yes I understand. I mean I don't want to diminish your feelings, just saying I can relate. When I joined the project, I was the first one to be excited about having something "already finished" that we should just ship. And it didn't turn out that it was just ready to ship, but coming with massive upfront architectural debt in the direction of unified front-end, dots support, and dividing our focus. As some have mentioned already, Bolt 2 was unlikely to be usable in production before a while.

I guess the debate is now turning a little bit toward who has the best understanding of the "right" approach. This is a fair debate, and we will all continue this conversation moving forward. Please keep it coming.

I would like to repeat one thing: we do not consider Bolt 2 was bad, or wrong, or flawed. We were just about to rush a new solution, as we did so many times before, without trying to consolidate, and improve the existing in an incremental fashion. For once, we want to try it. And this means incremental value, in short period of times, as opposed to wait for multiple years for a promised land that might never come fully.

 

I think it's fine but while adapting Bolt 1, just don't forget about everything Bolt 2 had. Please make sure that at least some of the cool features of Bolt 2 that were heavily discussed by the user base are rebuilt in that new unified version.

I feel most people are just not happy when features that they wanted are lost. It doesn't matter if they are in Bolt2 or in a new unified version. The important is that those new features are not ignored.

There's a lot of manual work and hardcoded things in Bolt 1, just keep that in mind while building that new visual scripting tool!

Your roadmap is already predetermined is a sense:

1- Adapt Bolt 1 to Unity's workflow and UI
2- Implement all the features that made Bolt2 great

I think a great way to move forward and to make sure people don't feel too let down is to have a space where everyone can list and vote on features that Bolt2 had. That way when you get to the point of improving Bolt1, you can just look at the most requested features and go down the list. Similar to what Microsoft have where you can vote for features.

Cheers,

 

What are the quirks of Bolt 2's implementation that makes this work so hard? You briefly mentioned in the first post that there is a lack of separation between front-end and back-end, but I honestly can't understand how bad this could be. I've read a lot of Bolt 1's source code and it is very well separated for the most part, and if Bolt 2 is in any way based on Bolt 1, I cannot in my mind understand how it would be so so bad, having been written mostly by the same person/people, even in an experimental state.

My guess is there are other reasons other than front-end and back-end separation, such as the whole code generation business and how it is done.

I ask this because I honestly think you guys may have the right idea here, in terms of the workload necessary to reach unification of VS. Implementing most of Ex-Crows list in Bolt 1 is not conceptually impossible, so if it takes less work to do that than it takes to start unification on Bolt 2, so be it.

With that all said, I still have a very big problem with one of the first statements:

This makes me worry a lot. Bolt 2 is very close to Blueprints. And I've never heard anybody say Blueprints should be simplified.

If you think the addition of another layer of class-orientation in the ecosystem of Unity overcomplicates things, just go Blueprints all the way:

Make a "Prefab Bolt Graph" which does exactly the same thing a Class Blueprint does, integrated with the Prefab Workflow. So a prefab B, which inherits from prefab A, has a Prefab Bolt Graph Y, which inherits from the parent prefab's Prefab Bolt Graph X. Make this Graph statically aware of all other components in the Prefab, and show it in the UI somehow. And you have most of what Class Blueprints is.

I honestly believe this is overall the best approach for thinking about VS integration in the engine. "Main Components" are a very widely used pattern, because it's a very obvious and useful one. It makes things obvious. If you have a "Vehicle" object in your game, you will usually give it a Vehicle/VehicleController/VehicleSomething component whose job is to orchestrate all other components (or even do ost of the work). If someone else wants to understand how it works, they will look at this one first.

It would even mesh well with the current direction of DOTS (with it's use of "authoring components").

The lack of interaction between C# class-orientation and Prefab class-orientation is something I think is bad even in the current state, so I do believe it would get worse if yet another version of it hit Unity without care. In UE4, the three ("prefabs", blueprints, C++) work in perfect unison. Prefabs are Blueprint Classes, and Blueprint Classes can inherit form C++ Actor classes.

In Unity, Prefab and MonoBehaviour inheritances are disconnected. A Vehicle Prefab can't have a Vehicle Component if you plan to make a Car Prefab with a Car Component which inherits from Vehicle Component, because if it did, the Car Prefab would also have a Vehicle Component, alongside the Car Component. I think the team's concerns are the same as mine here: if you added yet another form of inheritance, this time focused on non-programmers, even, it would make things even worse.

Of course, my take is that everything should be made better as a whole, not that it shouldn't be done at all.


(Sorry about this wall of text, the topic is going kind of fast and I want to put my opinion there fast, so I don't want to spend anymore time revising it)

 

I agree with everything that is being discussed here. bolt 2 was literally around the corner and was much simpler to work with, and avoided the many problems that bolt 1 has.

BOLT 2 is not just for programmers, it was aimed at EVERYONE, because it was EASY. how can you say it was not good for non-programmers if even those who do not program in C # liked the ease of use ????

And what makes me more upset here is that you want to take the technologies out of bolt 2, send them to bolt 1, since bolt 1 has several problems today as described by our colleagues above ... disappointing because if I remember correctly, even DROP 6 from VS DOTS was based on these ideas from bolt 2 (before the unit acquired the bolt). AND EVERYBODY agreed that it was a great way to work, and now you say you can't?

BOLT 2 was a correct evolution of what should be done, a powerful VS tool that, in my opinion, could face any other.

So if it is to give a suggestion it is ....

Work on the solution for 2021 as you intend to do, but do it on top of bolt 2 (Integrating with DOTS VS tbm). this is what everyone wanted, and this is what everyone wants now ... (As I saw on reddit, Discord and here on the forum)

But even if I say that, I think you will not go back to that decision. so if it is to work on bolt 1, I hope it will at least improve this VS tool from unity more and more, and help our workflow

 

You've got to understand something too.

Please study unreal blueprints.
How popular is It? Very popular and, in fact, is the best visual solution in game engines for many years ago.
Who can use it? Almost everyone on the team. That means it is highly unified for both programmers and not programmers - for everyone.
What concepts have blueprints? It is a like a class it has events, delegates, functions, variables, overriding, inheritance. And yet it is highly appropriate for artists too.

Answer to yourself what is more similar to blueprints, Bolt or Bolt 2? For me it is a Bolt 2.

And after that, please do not present your decision(by choosing Bolt over Bolt 2) as more unified, and do not include arguments about programmers and non - programmers!

By trying to not repeat one kind of mistake you are making a new more severe one.
With your current decision you will drag the whole industry down.

 

Yes Bolt 2 is very good for non-programmer too. Removing the programmer-centric approach is a bad idea. That's why Bolt 2 was created. Bolt 1 made that mistake and now even a small project becomes hard to maintain and debug.

 

Any visual scripting is still a programming! And I think it is better and safer for all to base your tool upon proven programming concepts.

 

At the end of the day, just don't guess what the Unity users would want by saying Bolt 2 wasn't this or was too much of that. Bolt 2 is based heavily on users' feedback. Just use that feedback and don't try to be too smart and make that new integrated version too different than Bolt 2.

 

Then you made a wrong choice. I just want to remind we had:
- VS DOTS, something that is in development for way too long with no clear future or even understanding what visual scripting is, no potential here especially since It's made with boilerplate heavy dots which is the exact opposite of what you want in VS.
- Bolt 1, a nice tool for game jam and too basic scripting for production, nothing really more. It was bad enough that previous developer prefered to start from scratch rather than continue with the current mess.
- Bolt 2, not finished but a tool which looks like something that does have great potential, something that requires bugfixing, polishing, refactors, potential changes in the future.

And you have removed of all, the bolt 2. The end result will be people complaining that you have two separate visual scripting tools, both in a disappointing state for next few years.

We can understand that there is something wrong inside of the bolt 2 because of which It's not worth developing, but then I think unity could at least clearly tell us what is wrong here. From what I have heard in this thread and others related to the VS, unity simply doesn't want to work with something as complex as bolt 2 and prefers to use a dumber tool.

 

Interesting decisions being made here. Hope this doesn't set Unity back too long...

As long as we can have something similar to:

- Classes, Interfaces
- Events, Delegates
- Scale-able, override-able modular 'Functions' or Subgraphs
- States and State-Machines, Decision trees
- Simple way to code your own nodes or "actions" in C# (this is pretty easy already in DOTS VS)
- 'Network Events' nodes for multiplayer, so Unity can finally have something easy to get our games online.

I will be happy.

I also assume that the plan is to eventually move away from mono entirely? So this visual scripting solution will work on both mono and DOTS using the same graphs?...so the transition to pure DOTS will be easier?

Really trying to figure out why Unity is trying to get far away from "programmer-centric" visual scripting.

 

Constant change of plans means that Unity is finally trying hard to listen, adapt and deliver what users want while looking through the prism of their vision. Which is more often good than not.

It is far worse to stick to what they think users need. And taking them ages to deliver something that ultimately won't be welcome.

On the Bolt 2 topic... it indeed looks like Unity chose to get rid of something that felt more complete to some users, however I feel this was not an easy choice, and there probably were solid reasons why they chose to dump so much work and invest on something that is in a much earlier stage.

In any case, I do not really see many people using a DOTS oriented visual scripting solution any time soon. Bolt 1 still seems to be the more relevant approach for the next couple of years.

 

Thanks again everyone for the feedback. I think there are two aspects of the original communication that are particularly sensitive here. The impression given that Bolt 2 was designed wrong, and the impression given that Bolt 2 is entirely lost.

Many aspects of Bolt 2 are excellent, and the team can chose to use Bolt 2 code in the next increments of visual scripting.

We will regroup as a team, reflect on this, and come back to you all with more details about how this implementation will evolve.

Thank you.

 

Thank you for listening Laurent!

 

Thank you too for being communicative.

 

I think there is a lack of communication here

1 - do you intend to improve bolt 1 (making increments little by little) and join DOTS VS at some future time?

2 - Are you using BOLT 1 as a base to implement functionalities of bolt 2 + DOTS VS?

3 - Is it something totally new using: DOTS VS + BOLT 1 + BOLT 2?

I think everyone may be getting mad about nothing, because they may already be at the roadmap, and we just don't know

 

What it sounds like is Unity is moving towards, if not already, a Scaled Agile Framework. Talk of increments and value delivered is what Scaled Agile development is all about. Although it may seem like things will slow down, it does not. In fact SAFe (Scaled Agile Framework) has proven to increase productivity, value to customers, and stabilize software at all levels.

If you are interested in these paradigms I would look up Agile and Scaled Agile. The knowledge might give you some insight into why Unity is doing this with Bolt 1, 2 and DOTS VS.

 

@LaurentGibert, if you want to provide as much value to your users as possible, dump the Bolt 2 code on github with no license.

Then there can be something workable that people can use that comes out of this acquisition. Or just give Bolt 2 back to Ludiq.

Taking years of hard work and dumping it because it's hard to make the UI work well with your other stuff is just inane. You can talk about "silos" as much as you want, this ends up as a waste of thousand and thousands of man hours for corporate nonsense.

I don't even care about visual scripting! I just really don't like it when worthwhile stuff gets bought up and then discontinued for no god damn reason.

 

Slow Product but Ready for Unity 2021
Or
Fast and Great Product but Not yet ready until Unity 2021 LTS

who is responsible to answer this question?
Why the rush.
There’s a popular quote in the games industry.
Bad games released rush are bad forever,
Delayed games released late are eventually good. Does that doesnt apply for Game engine features? That’s a simple thing.
Why “complicate and compromise”, I believed you picked the worse combo, worse but fast iteration. You’re still giving people subpar stuff, and people already knows there’s something better.
You get what you expect: what do you expect?

I’m not calling out to certain people, I loved the Devs, I call out for Unity, we know it’s a corporate decision.
Sometimes calling out works nowadays and companies change decisions. So don’t forget to let unity be reminded. When they forget, it is permanent. Thinking it’s one of the best decision they’ve made. Probably get some bonus. It is not.

 

My goodness,... Bolt 2 was a dream becoming true, being able to have REAL performance, with a tool SO EASY TO USE AS ITS PREDECESSOR, its not programmer centric,... I´m not a programmer and bolt 2 felt way more organized than bolt 1,... This decision is really a sad one, instead of having what would be a really standing apart solution, a dream for a lot of us, you kept with what the competition already has, seems like a huge step backwards,.. it very difficult to understand this decision, a least release bolt 2 open source so the community may continue the work,...

 

Nice to see this is conversation rather than an ultimate.

 

After reading all the posts up to here I think the whole concept what is planned now is a mistake.
Bolt1 is a nice thing in terms of visual scripting but in my opinion it should not be integrated into Unity. I am of this opinion because of the strong performance losses and the limitations of Bolt1. But there are better and faster alternatives. (I refrain from naming names here). Bolt2 on the other hand would have had the potential to be integrated but as you can see here the idea seems to be born dead. As I said, these decisions that are made here disappoint me deeply. Finally a glimmer of hope and the whole structure is torn down with such a crazy idea.

I started with Unreals-Blueprint and I am thrilled about the way you can work with it. It is intuitive, easy, very pleasant to work with. Drag and drop and ready are the references etc. just easy. Okay, it's not super fast either, but it works great. Bolt1 doesn't even come close in my eyes. Yes it is intuitive up to a certain degree but that's it. I give Bolt here only 5.5 of 10 points. I don't want to talk about the performance ... but there are enough explanations in the previous posts. To use Bolt1 in short, I think it is a mistake concerning the fixed integration. Bolt2 on the other hand would have been a decent idea, but you can't even bring this online ...
Of course I also read the roadmap of Unity itself. What is said there sounds good at first but I also think that the implementation of some features should be better exposed and more focus should be put on usability and stability. (no I don't mean Bolt1 integration).

Short and sweet. I am disappointed and think you are missing your goal.

 

When you say "unify our graph-based tools", does this mean you're going to change the look of Bolt? I really hope not, I love the look of Bolt.

I realise this is a tiny thing and nowhere near as important as other points raised.

 

It's good to hear that VS Team has thoroughly evaluated the situation after testing with users and thought long and hard about the path forward. I know it can be tough to make unpopular decisions, but that's just the nature of large projects in general.

I hope to see some of the improvements of Bolt 2 merged into Bolt 1.

In particular:

- Strongly typed variables
- Strongly typed events
- General aesthetic.

Aside from that, I hope that this also leads to a strong focus on native engine integration on par with Unreal Engine's Blueprints.

 

That looks like a list of common things we have to use to make a game, yet it seems their solution will actively avoid implementing as many of those as possible, because they're too complicated.

It's always strange when they talk about tools for artists, because I'm an "artist" (graphic/website designer), yet I would never use Bolt 1 because you can't make a game with it without going insane.

 

The discussion looks like:
users: We want Bolt 2 with the option of custom scripting, custom functions, and all those cool stuff around
unity answers: That's nice, but we want something else
it looks like they're stuck without the original developers
Does anyone know of any better Bolt alternative that can do custom sctipting and custom functions?

 

I have been SCREAMING about the awesomeness of the "architectural" changes since drop 6, which was what inspired my extremely long (but-important) posts on "Data-Oriented Visual Scripting: The structure of a language."

STRUCTURE matters, @Unity.




The above is what happens when you _don't_ have structure.

But even _that_ terrible (UE4 Blueprints) graph can be salvaged with a _little_ structure:




However _this_ is what happens when you _do_ have structure:



Despite the "portal-centric" approach (which I address here), for a demo, this was still a thing of beauty to me as far as "structure" was concerned.

I don't think Bolt 2 was "programmer-centric" -- but I get what you mean.
Bolt 2 wasn't perfect, but it definitely didn't try to tell artists/designers "you're too dumb to figure data-flow out yourself -- so do it _this_ way". Instead, it gave artists more advanced options (presented in a friendly, more data-oriented, way), offering them a path to doing things for themselves -- in a much more sensible way (thanks to how _structured_ its approach to data is -- that is, Bolt 2 structured data in a slightly more 'tiered' fashion, which takes into account that "tagging" workflow I keep pointing out -- which is used for defining "sibling-like" hierarchies as part of the workflow, and this approach, unlike UE4 Blueprints, wasn't at all 1:1 with C# OOP -- nor was it ABSTRACTED to hell and back!)

This, inherently, is why artists/designers (and yes, even programmers!) loved the Bolt 2 approach, @Unity!

Classes of prefabs/objects/behaviors are important -- but so is the ability to switch the behaviors between them on-the-fly (which is why people want to be able to modify their code after a build!). When "classes" are 1:1 with C#'s backwards-ass interpretation of oop classes (i.e. having the child determine its behavior based on what it chooses as its parent), the "classes" swiftly become too strongly-defined to work with in gameplay scenarios, where the behaviors prefer to be more loosely-coupled and modular. This is how designers work, after all -- i.e. with modules and behavior.

It sounds like we're on the same page -- I _really_ need to spend time illustrating the way I envision a "tagging" system and its respective programming workflows. That should clarify how easily a "classes" concept should work with Data-Oriented Visual Scripting, and the reason why Blueprints (and regular C#) classes could be MUCH improved for game design.




Also, @Unity --

As per someone else's suggestion in a previous drop's thread, you guys probably should just hire me. ;P


I'm pretty smart on design, I have a lot of technical know-how and experience, plus I'm your target audience.
Also I've been thinking about Data-Oriented Visual Scripting since like 2003 (probably earlier).

I also understand your new unification approach (and the need for it as well), and I am confident that I can wrangle in this project's design to where it fits artists/designers again, and deliver a product even _better_ than Bolt 2.

But to build the low-level flowcharts and example workflows you'd need would take a lot of time and explanation of the hows/whys -- something your hour-long (non-technical) interviews/feedback sessions just don't cut.
Drop 6 was an important step in the right direction, and so was Bolt 2, but after Drop 8, to most users, you guys really dropped the ball and disappointed a lot of users (mostly because of the silo thing you discussed). But now that you're dropping Bolt 2 too, you (surface-level) appear to be taking a wrong turn again by ditching a lot of people's last hope for an artist-friendly(-ish) VS solution.
But I believe Bolt 2 wasn't the end-all-be-all of Visual Scripting -- despite its important contributions.
That said, I definitely FULLY understand (and appreciate!) how important it is to unify your toolchain and un-"silo" your tools -- a decision in which I TOTALLY support btw! -- (I'm glad you guys have finally come to your senses on this one!!!)
However, I do think this whole process could have been done a little more gently than purchasing (and then dangling) a new useful "toy" in front of a lot of potential users, with the promise that they can have it someday soon, making them feel the need to beg and plead to you for it -- then yanking it away, suddenly telling the users that you just changed your mind.
It does come-off as just a _little_ bit mean-spirited, don't you think? -- Just like no child would listen through their tears and heartache, despite your assurances, I doubt very many users are feeling all that confident in Unity right now.


So I ask that you take into account that users are human too, and many of them are really looking for a tool to make the experience of programming much more fun (and efficient!) for them. I can help. I've got the, ehrm, "Blueprints" for that experience in my head right now. If you want them, all you have to do is ask. But it will take more time than I've got to deliver them, and as such, we will need to have a few heart-to-heart conversations first before I spend more of my time and energy.
And no -- these aren't UE4 "Blueprints" for Unity, nor are they a cheap carbon-copy of the Bolt 2 engine. There's a LOT more to consider about the inherent design and structure of the "language" that people call "Visual Scripting" -- and I don't believe a programmer or artist/designer (alone) has a good enough understanding of both worlds to make the big judgement calls to determine that language structure should be designed. However, I can offer you one better:
I just so happen to be an artist, who is also a pretty decent technical guy, who happens to program (across quite a few languages) who hates being a programmer for one major reason -- the structure (and inefficiency!) of nearly _every_ single programming language I've come across.

And, oh yeah -- "terrible visual tools/functionality" is just insult to injury for me as an artist, since I am primarily a visual / visceral person. And as such, these tools bother me on a personal level -- especially since I can describe exactly how these can be fixed to no longer annoy me on this level.
I apologize for my tone, but the ergonomics of certain tools/designs drive me up the wall -- so the more access I have to help with improving tools like that -- the happier of a person I'll be.


I advocate being human above all else -- and inconsiderate tools tend to make me feel more like a robot instead....

 

So this begs me to ask...will you guys be open sourcing Bolt 2, or did you just inadvertently buy up and shut down the product we all wanted, formed a community around, and many paid money for?

 

Hmph.

 

Yes I feel the same, I would even prefer if the UI look of dots VS became unified with bolt instead of bolt starting to look like the unrefined VS Dots UI

 

My final thoughts on the topic - ultimately I wish visual scripting is viewed as its own language that empowers visual thinkers, artists, designers, animators and even programmers to achieve anything they envision within the limits of the engine.

And I mean anything - this would include both sandboxing for designers when needed but otherwise would enable us to script anything from character controllers, to inventories, to advanced camera setups, anything. Blueprints has that premise. Bolt 2 had that premise. This implies a structure that goes beyond the free form nature of Bolt 1 which fundamentally is not able to achieve a lot of this in a reasonable manner. Either because of the lack of structure, scalability or performance problems. Bolt 1 is fit for high level scripting, that's it.

I do not wish all of this to result in a niche, limited tool for "artists & designers" where structural, organizational and functional responsibility is on programmers to code their own custom nodes per project basis. We absolutely need a more streamlined API for custom nodes, but it shouldn't be the only way of working within Bolt.

 

Actually, I'll say this one more time, Flowcanvas came before Bolt 1 and still slays Bolt 1. Bolt is a rather poor imitation of Blueprints and Flowcanvas, and performance is vastly worse. There is no reason to use Bolt 1 over Flowcanvas, it does absolutely nothing better and is in many ways worse. I, and others, have elaborated on why many, many times before so I won't repeat myself, but Bolt 2 would have been and indeed was superior to every VS tool on the market, BP included. Fixing up Bolt 1 is senseless, you'd be better of throwing marketing money at Flowcanvas and get in on some of those dineros.

 

Whoever at Unity is making the decisions on this matter needs to be replaced immediately. Your user base is largely telling you that you are doing this wrong, and you are. You are doing this completely backwards and then telling us that we are backwards while at the same time saying that you are listening to us. It doesn't work that way. You are not listening.

People keep mentioning Blueprints and Unreal Engine, and that is for a reason… They are doing it right. They have a product that is superior in every capacity.
You need to be modeling success here instead of modeling failure.

The only way to fix this is to release Bolt 2 into open source and allow the community to do for itself the things that you guys refuse to. We simply no longer trust Unity to do the right thing. Releasing it open source will get Unity out of the way so that actual progress can be made.

Since you have already said that you are throwing away Bolt 2, it won't be any issue for you to do this… Garbage has no value to you and somebody out here in the actual development community will be able to do something great with it.

Please, for once, do the right thing for your users.

 

Even optimistics see the best bolt 1 can be is par with competition, performance is the key word, visual script guys will always have some disadvantage without c# performance.

 

this ⬆. unity is already behind its competition in every level. at the end of the day you either listen to your community fix everything, and stop acting like you know everything or dividing your community and eventually losing your popularity. and stop announcing stuff first, then crawling back to community and asking for feedback, then either not listening and eventually deprecating the project, or listening starting over, and doing the same cycle.

listen to feedback first, discuss and make everything better. and stop with this non answer bs reasons. in this case @LaurentGibert said the code is excellent in bolt2 , so that leads me to believe there is no actual technical reason.
if there is, well, big fail on communication.

as @awesomedata said , unity dots vs ui is awful , so stop trying to make everything like that.

i hope unity comes to its senses, cause right now, there is a lot of people pissed not just for bolt but every unity package.

 

There's no upsides without downsides!

But, I actually meant integration in the sense that you can feel that the UE4 editor has Blueprint in mind everywhere you go. The two are one and the same, in a way.

As for performance, as long as Unity can deliver a tool I can use to help further my ambitions, I think I'm OK with a slight performance hit.

 

After completion of bolt 2, another thing that Unity should focus on are Bolt 2 tutorials + rich database of click & see examples of most used connections in games. That would significantly push the thing forward.

 

You might want to reread the thread, no more Bolt 2 unless they open source it.

 

visual scripting is mainly for designers, if the designer "doesn't see examples", he can't move the game and has to hire a programmer, and a good programmer doesn't need visual scripting because he does the thing in the code quickly

 

I know, I tried to change their mind

 

It’s really a shame, although I understand why Unity did it, I think this is a bad move. Should have never bought Bolt at all then. I don’t want to wait 2 years for production ready tool and I don’t want to invest my time in old tool which has so many flaws. Probably will tru to use playmaker although I can’t say I like it.. or maybe will dive deeper in unreal. I kind of liked the way Bolt worked, visual feedback was one of the greatest features, it makes it so clear where the issues are. Well.. what’s done is done, have to find different ways now.

 

Can you explain this more? Yes, Bolt 2 takes a more programmer-centric approach, but that is because it is much more robust. I don't understand any of the other stuff you're talking about. Does anyone else understand this as a reason to not use Bolt 2 over Bolt 1?

 

How much prejudice... Some "designers" put most programmers to shame

 

Adriano, I write in relation to visual scripting and a designer who is addicted to it and can't program. I don't write about some designers who can program in code.

 

Sorry, misinterpretation...

 

What a waste of everyone's time and the companies money. Honestly why did you all even buyout the Bolt addon if you weren't sure or even were just going to turn around and use it as source material?

Why make it a big deal to all non-coding game creators if this was just going to be the outcome?

Honestly this makes me want to just drop Unity and go over to UE4 (and soon to be UE5). This sudden shift in priorities (that all of us not within Unity could know was coming) is pretty dishonest to say the least. The code generation that was coming with Bolt 2 was a MAJOR point of interest to me and so much so that I even signed up for the Bolt 2 Alpha. Which feels like a slap in the face that I even put the time in to fill out a form that has ended up being a waste of time.

I am frustrated because as a visual learner I've been using Visual scripting as a medium to learn coding and with UE4 using C++ (which is a confusing mess from what I've been told by a few coders who have tried to make sense of the game engine), Unity was my next best shot at making a game. But now? I plan to go install the UE4 launcher because unlike Unity they aren't dropped the ball with their engine and the features they keep adding in.

This is a blunder that will be costly to Unity no doubt.

As a famous game heroine once said, don't make a promise if you know you can't keep it.

 

I am a programmer, and was looking forward to the advantages of Bolt2. The "direction" that the visual scripting team at Unity is trying to follow is just baffling. This is a critical piece of game development that you need to get right and you publicly floundered and failed right in front of your customers.

If you didn't like having three approaches to VS why did you buy Bolt for your MonoBehaviour scripting? However, hearing that you're going to integrate Bolt1 into Unity and make it backward compatible with the asset is just insane to me. Just doing a cursory review of Bolt1, it has serious flaws in its implementation of custom nodes, debugging, and performance. Did you learn nothing from integrating Mecanim and Enlighten? Are you capable of making new tech or are you going to constantly be hindered and slowed down by decisions that came before? From my perspective, Unity is a slow piece of tech that can't seem to make hard breaks in their technology or workflows. They spend all of this time and money on DOTS and then they back out and revert to hybrid workflows. The last break was maybe nested prefabs, which took how long to get right? Finally acceptable in 2020.1, 2 years after release, after 5+ years of broken promises. This is a my perspective as a user of Unity for 10 years. What a mess.

 

For the dozens of reasons other users have pointed out in regards to scrapping Bolt 2, I feel that this is an absolutely terrible decision.

Bolt 1 is neat, sure. Something to tinker around with. Bolt 2 was the first thing out there that felt like an actual tool. Something that could not only get the job done well, but do it while still being performant (Performance by default. Is that still a thing, or is that scrapped now too?), something that you could actually use in a real game, and not just the thing you would recommend to your neighbor because he said his kid wants to make Call of Battle: Modern Hashtag Wars like with Bolt 1.

I feel that making a huge new mistake is not a step in the right direction. Many, many people have been anticipating this tool for as long as years. What a huge slap in the face to buy it out and scrap it right in front of everyone because it doesn't fit the "new vision". As it's first order of business, get rid of one of the most anticipated, and possibly the most useful tools to the community, in general, to be introduced to Unity in a long time.

The majority of the official posts talk about how they are making big changes and are "listening to their users", well, nearly every user in this thread said that this is a mistake and that we want Bolt 2. If you aren't listening to all of the users right here, right now, what users are you listening to? This feels like the opposite of that..

Why not take this opportunity to prove to your users that you actually *are* listening to us and not just repeating over and over that you are? If not, please give it back to Ludiq.