Official Visual scripting roadmap update - August 2020

Called it.
https://www.sec.gov/Archives/edgar/data/1810806/000119312520227862/d908875ds1.htm

I guess we just hang on tight and see what happens.

 

Beat me to it, was just about to say the same thing.

Guess this means we'll actually get a look at what is going on in the company and why they would make this decision... Like, it could be a good move for them (and hopefully us), but I dunno...

 

Just saying my piece then I'm done:

I'm actually describing how BOTH concepts are not mutually-exclusive and also how they can easily work together.

Except.... I didn't. -- You just cherry-picked my words. -- In no place in that post did I ever compare ECS (alone) directly to OOP (without referring to C# or other languages).

I was clearly referring to ECS as a better "language" (than C#, for example) for programming (with OOP concepts).

In fact, my exact words in that post: " ECS is a better way of programming in general -- including how it is better at "Object Oriented Programming" (OOP) than any other language in existence today! "

Literally the entire post was spent discussing how OOP concepts, when applied to ECS, made ECS a much better "language" for OOP-style programming in general (which, just so happened to be in a thread where I was discussing Data-Oriented language as it relates to Visual Scripting / programming structure in general.)

You're entitled to your opinion. No worries.

And while I agree that further conversation along this line is probably counterproductive between us, I can't help but feel the "if it's not Bolt 2 -- i.e. something I can put my hands on NOW -- I don't want it." vibe coming from your words.
Either way, no hard feelings.
I also agree that further "derailing" with something I can only tell but not quite show right this second (except through sound logic and reasoning) is clearly not as productive as I would've liked it to be -- So that being said, as you've pointed out -- I better put my money where my mouth is and put up or shut up until then.



To anyone else who's interested in my reasoning for sharing all this:

Spoiler

I honestly just wanted to help.
By me freely sharing the logic behind this, I was hoping Unity would consider integrating this new workflow themselves so that anyone (especially beginners/hobbyists) could (freely) use this workflow to avoid the structural pitfalls beginner programmers often face. While I could make an asset, and make money, I have also been in a place where I just wanted to make games, but I couldn't afford the tools to do so, so I could only dream -- and while dreaming is cool -- it always sucks when you actually wake up.

Being an artist, I didn't want to learn programming -- I just wanted to bring my art to life.
I started programming because, like many others, I (erroneously) thought: "Well, programming's just logic. I am good at logic. This should be easy."
However, just as anyone with any real programming experience for any real game project knows, programming is NOT at all "just logic" -- it's "just your logic versus the underlying logic of the language you use". The beginner programmer is always fighting the structure and inherent semantics based on the language's underlying logic structure (often called 'syntax') -- versus their own semantics/structure on top of that, which is, again, dictated by the language's logic structure and reasoning -- not your logic and reasoning as a programmer -- meaning your eventual program structure, built on your 'desired' semantics and reasoning (built through and through around the limits of constraints whose limits are defined and enforced by syntax, not by logic itself). These limits and the logic that arises from them are clearly, by default, not your own design -- Syntax and language semantics inherently separate you from defining / designing your own logic by default.

So if you are a beginner programmer -- and if you are able to understand this so far, please keep this distinction between logic and syntax-structure in mind as you write your programs.
One day (soon hopefully) you will realize just how big of a monster these "experienced programmers" were for attempting to snuff out these particular "new" ideas.

Mindlessly defining yet another "language" based on feature-set alone is the mistake we keep on making -- This is history repeating itself. There are too many things to consider -- and pulling the trigger on a solution -- yes, even a progressive tool like Bolt 2 -- without understanding the exact shape of the overall problems that fundamentally establish the foundation of our house of troubles will only lead to more troubles down the line, be it through game performance or workflow.
These troubles may not collapse the whole structure -- but the structure that breaks will be a lot more expensive to fix later on... kinda like our Visual-Script "spaghetti-code" will be too, if the developers of our Visual Scripting tool of choice ignore these issues...

 

So maybe that means that if* we had Bolt 2 the C# output could convert to ECS ? or would it be DOTs ?

Either way here is a question for Unity ... How many people in percent wise 60 %? how many do not know how to write C# and or do not want to learn and or have a far easier time using Bolt ?

My point is I think there are far more people that could use Bolt 2 Over the high concept programing needed for
either huge game worlds or maybe movie or TV applications ? just saying I believe there are far more
low level user's, then " high level users " OK last thing sorry /rant off

 

Here is how unity's visual scripting could have been.

 

It still can be.. I don't understand why they can not do both is all. People have been waiting for a good
2 years now, there was talk and planning though for Bolt 2 a year before that I think.

The real question is where does unity make the bulk of monies. They will end up doing what they want anyway.

 

this means (in theory) that in dots vs, the C # generator is not necessary, since at low level, the code generated by it would have the same performance as the normal C # code thanks to the burst.

 

That's not how visual scripting works. Every single VS tool will always have some sort of overhead compared to pure code. Even bolt 2 does have overhead. This is mainly because the point of visual scripting is to take away many "elements" of the programming language because they aren't very obvious at the first glance or overall need better understanding of programming to utilize them properly. Because of this, there is always a need for some sort of API that will take care of what the user wants to do with his nodes.

Machine code has literally nothing to do with it. Both Bolt 2 and c# can be essentially compiled to the IL but one of them can perform worse.

 

Bolt 2 had overhead, that's true, but in my (limited) tests it was near indistinguishable from native C#. We’re talking about 0.01-0.05ms difference here. Any tool that does not have a C# gen output will produce considerably slower results, even with directly implemented C# snippet nodes.

I guess DOTS is faster than regular OOP C# anyway, so perhaps if the nodes are directly implemented snippets it could end up being faster than Bolt 2 C# gen by the nature of being ECS based. Who knows.

 

In this recent video author specifically called BOLT (1) as new official visual scripting tool several times(.

 

On the bolt discord server, they have already warned that the name will probably be unity visual script

whatever the name, unity bought the bolt, so it can continue to call it a bolt if they want, or create a totally new name (as with dots)
we always called the drops DOTS VS

 

That's why I said in theory.
I'll try to explain better what I'm trying to say ...

I know it's overloaded (because the way the visual script is created is quite different, as you explained yourself) I'm referring to the low level code generated by the burst itself in DOTS.

DOTS is literally designed to make everything faster (performance by default), and when the code is well designed, it achieves great performance. Therefore, if the C # generator in mono has a performance similar to or close to the normal C # in mono. Therefore, in Dots, the visual script would have the same performance as C # in mono, or better, because of the burst. And with the possible sniper nodes, this can be even better .... to the point of being the same as the scripts created in DOTS.

I am not saying it will be better, I am saying it can be close or equal in performance in some situations. And that would be very good for everyone.

 

Well I you meant, It could work almost as good as code then yeah, that's a valid statement
But in theory (which is supposed to mean, on paper) visual scripting always will be slower than normal code, which isn't anything bad. Main purpose of VS isn't to develop the most performant games but to create them as fast as possible. Which doesn't mean visual scripting shouldn't be fast. Users simply care about developing games asap and then, about performance.

But yes, it's definitely possible to make it almost as close as code. Bolt 2 was really good at that while bolt 1 is really terrible.

 

All I want to know is if we are getting code generation and optimizations that don't kill the Editor speed.

Thanks,
Eric

 

Codegen is not happening as per the OP announcement. But it seems they also won't stick with Bolt 1's reflection as is. There are other, more performant ways of generating low level nodes. That said, it still won't be native C# speeds Bolt 2 promised. But it should be much better in theory. And the new tool's focus is directly implemented C# nodes, so those will be more performant by default.

Editor optimization should come, I imagine they'll rewrite the current IMGUI implementation to UI Toolkit, eventually. We're waiting for their next post that should go up in a week or two. It should go into more technical detail on what their plans actually are. Everything we're discussing here now is mostly speculation based on available information.

 

https://forum.unity.com/threads/free-ualive-bolt-inheritance-live-to-compiled-c-generation.918518/

 

Wow! This community is AMAZING!

Thanks,
jrDev

 

Thanks Unity for listening! I hope you will continue with Bolt 2, if not please open source it. The programmer-centric approach was the key for making it a success. In my own testing with AI scripts, bolt 1 capped at about 100 units, with Bolt 2 the cap was around 1000-2000. Also the variable hell Bolt 1 creates was solved in Bolt 2.

Thanks again.

 

I still don't get the programmer centric argument. A Discord member said it much better than I could:

"Architecture isn't "programmer oriented", its just a side effect of working with data and logic, no matter who you are. You can't make a game without a solid way to organize and manipulate data and logic."

Bolt 1 has no meaningful organizational/architectural capacity for graphs, variables and custom events. While Bolt 2 resorted to the true and tested Class model, it worked. It really did. If classes are too programmer centric, do something else. But it has to be something else. Going back to Bolt 1's free form structure is not the answer.

There were a lot of benefits for the Bolt 2's class structure beyond C# gen:

1. Classes enabled object/component scope variable reuse. Variables and graphs are separate concepts in Bolt 1 so while you can easily reuse macro graphs, the same doesn't apply to object scope variables which have to be remade by hand every time. Bolt 2 Classes grouped variables and graphs together so you could simply drop a class on something and all the variables were there.
   
   And because object scope variable reuse is such a pain in Bolt 1, people usually resort to using Scene variables since they can be accessed from anywhere in the scene and they can hold scene references like Object variables. So a typical Bolt 1 user ends up with a very long list of Scene variables that can't be organized or searched. One could say Bolt 1 promotes bad practices by default with its structure, even if we ignore the magic string matching.
   
   
2. Same for Custom Events which in Bolt 1 are magic strings somewhere in your graphs without any tools to find, organize or refactor them. You also can't search for them in Fuzzy finder. Bolt 2 fixed all of that with events being grouped under classes which made them easily discoverable, refactorable and searchable in the fuzzy finder too.
   
   
3. Better integraph communication via function graphs and being able to check if the receiving class is of a certain type. ie if this Is Enemy, invoke function DealDamage. Custom events can't do that (at least they can't without belonging to a class). Return values is also something enabled by function graphs and which doesn't exist in Bolt 1.
   
   
4. Organizationally Graph Explorer was excellent as a project overview and graph organizer. Being able to see everything in proper class and namespace categories was invaluable both for planning further and accessing existing graphs, variables and custom events.
   
   
5. Fuzzy finder becomes much more usable when nodes are grouped in classes which can have custom icons. In Bolt 1 all variables and superunits look the same, you only have the magic string to search for and determine if it's the variable/superunit you're looking for. In Bolt 2 you could find things by class if you forgot the variable name and accertain the corectness of search results by seeing the icon and strongly typed port previews.
   
   
6. Generally I preferred to work on reusable Bolt 2 function graphs which made my graphs much more modular and reusable. Bolt 1 by default promotes monolithic graphs since it has no structure.
   
   
7. You could apply custom icons on every class, function graph and custom event which made graphs a lot more readable.

If Classes are too programmer centric, call them Groups or whatever else is approachable, but we need structure. Without it, you will designate the tool to be a delivery device for custom C# nodes that are meant only for limited scope high level scripting. That's the complete opposite of what Bolt 2 promised and why people were excited for it.

Bolt 2 was not programmer oriented, it was the natural evolution of the tool based on years of community feedback and experience. It adressed the two main issues of Bolt 1 - performance and structure.

There's a reason no well known game has used Bolt 1 in production despite it being around now what... 4 years? Part of the problem is performance, but it's also the lack of structure which doesn't scale well.

 

Someone in unity understands "programmer centric" visual scripting as a tool that allows for a lot of things c# does allow. It's truly an absurd thing to say, especially in the first post as an excuse to why they wanted to remove bolt 2.

Artistic centric visual scripting doesn't mean It's dumbed down so even the most stupid person can do simple things, or there are many colorfull icons.
It means the tool is easy to get into. The fact that bolt 2 does have classes and functions, means It's more artistic tool, mainly because these features are supposed to make it easier to organize graphs and thus, make them easier to read in the future.

For most (if not all) of the professional artists, the job isn’t about making art/ levels/ animations/ UI etc. looking nice, but to make them easy to understand, so the user can get immersed.

 

Seems to me with this many people complaining, and yes many, many people were looking forward to Bolt 2 ..
like many people, we were all looking to Bolt 2 even as bolt 1 was being worked on.

Maybe if they can ? Give Bolt 2 back to ludiq so he can finish what we all want. Anyways I will try not to post any more on this thread. I just can not believe that Unity will kill this, for all the new and other people that need this type of tool.

 

it would be better to buy a playmaker, there is an absolutely human-readable fsm machine. All assets that do not develop with a UNITY have one problem - users lose projects due to a bunch of bugs. I used the playmaker very conveniently. But this is a crutch for the program and a lot of bugs and inconsistencies arise.

 

That's very shallow approach. Your ultimate goal should be to simplify Unity for everyone.

Think out of box for a second and create a solution that would be better (and simpler) than writing C# in VS/Rider. Why? All programmers job would be done faster. All non-programmers would find it easier to learn programming.

For ex. this plugin in Unreal:

If someone would take this idea seriously and implement all features that normal IDE has (or implement it inside IDE) it could change whole programming industry.


Oh and btw adding builtin Visual Scripting in engine sometimes doesn't simplify the platform. I've learned that in Unreal, half of samples/tutorials are in Blueprints, other half in C++. There's also whole Blueprint to C++ integration and dozens of flags in editor making learning experience a lot more complicated.

In other words imagine what happens if in 5 years every Unity programmer will be expected to know not only C# (as it's the case right) but also DOTS and Visual Scripting (and Visual Scripting to DOTS to C# integration ehh...).

 

I'll never understand aiming a VS at non-programmers. If you aim it at programmers, then it will be powerful enough to generate high-level nodes for beginners. Then it's a case of having a Simple/Advanced mode.

Simple mode only gives you nodes such as FPSMover and FPSCamera. Class becomes a "Group", as mentioned in a previous post. Advanced mode exposes the entire C#/Unity API...

To me it seems to be a simple UX issue, not a technical issue, but maybe I don't get the complexities of it.

 

but there’s one thing, unity wanted something more general, and not just use cases. The playmaker is good, but I'm not sure he would be scalable. Not to mention that it works totally differently from other visual scripts in the industry.

 

Playmaker allows you to program the actions ( in c# ) and use those in the playmaker editor.
Thats what makes it pretty powerful.

 

Maybe Unity has taken too much on. It seems very ambitious for all these features.

Bolt I understand is not working in the latest version of Unity already .. with all they have to do It seems a lot to make
sure, that Bolt works in all Unity versions, or at-lest have warnings for what versions Bolt won't on... the idea being that
new users to Unity wanting to try to the tutorials might run into problems, and have no idea why.
As it is now, you get warnings that mono was deprecated starting Unity2019.3 ?
New users always want the latest greatest software, so Unity support maybe taking a lot of time to help new people with Bolt and the right version of Unity it will work on.

Bolt is good because as beginners you buy all these different packages and with reflection it is fairly easy to get them all talking together, this is one of Bolts main strengths, for people that can not code for what ever reason.
Without the possibility of Bolt tying different assets together, People sooner or later realize that throwing money at assets, water, sky, rpg assets, etc.. eventually find it does not matter how many assets they buy, since they cannot code and all the packages need some level of understanding C# to get even simple stuff working. This I can see people going to check out Ue4 once they get frustrated enough.

My point is that with all they have going on... So, I wish/hope that Unity and Ludiq could come to an agreement
if* both parties can do this. Simply give back control of Bolt 2 back to Ludiq for development.
Unity has a lot to deal with, sometimes a single developer can work faster since they have fewer moving parts then the Unity engine and all the new features Unity is developing. including now Bolt, for Unity beginners.

If* Ludiq could have Bolt 2 back, ( assuming he has the will/time to take it back and develop it. )
IMHO, Ludiq could develop Bolt 2 faster, then Unity and keep it updated. To me it seems reasonable and I believe for sure all the users of Bolt under the Ludiq team, would be more than willing to pay/support a new version Bolt 2 under their team.

 

Difference between a solo dev and a 3379 people organisation that all need to communicate is not to be underestimated,
solo can make split decisions and only need to be accountable to the users,
vs a team in unity needs to be accountable to the users + management + company vision + quality assurance + etc.
Not an easy task.

 

A friend of mine at his company, had a saying .... they have meetings to discuss when to have
the meetings while having their coffee latte o/c.

I agree Unity has many different parts to look after. This is why I think Bolt 2 is out if Unity keeps it,
or even if not out... they have so much to handle, I can't see them doing Bolt 2 justice, like
Ludiq team could.

 

I can't speak for Lazlo, but he hasn't expressed any desire to pick Bolt 2 back up. He’s also leading his own game studio and has to support Peek so his hands are full. And there are legal issues of ownership. Unity can't just hand Bolt back like a stick. The acquisition took several months originally.

Furthermore, Unity aren’t throwing Bolt away, they'll keep supporting Bolt 1 for the current versions of the engine (though I do agree that support has been slow) and they'll use some of Bolt 2 tech in their new tool.

Asking to hand Bolt 2 back to Ludiq is not realistic. Perhaps the open source angle is an option, but I don’t think the community has enough power behind it to finish it with no funding. I also don’t know if there’s a precedent for Unity open sourcing previous acquisitions.

 

It's definitely unfortunate news. I would caution against trying to avoid one issue or "mistake" so strongly that you become unable to see other mistakes being made in doing so.

Yes it would be better for Unity to be shipping more stable/ready features that gradually grow and don't break compatibility. But that shouldn't become a hard rule, otherwise you end up with very lackluster features that dared not push the boundaries for fear of not being stable/ready quickly enough. Especially with such core features as this will absolutely become in the Unity ecosystem. This is one of those things where if you're going to do it, you should really want to in a way that solves the problems that existing VS systems have had, that evolves the concept, allowing it to be a shiny, attractive feature of Unity that draws users in instead of just another basic VS system that Bolt 1 is.

I hope the team will consider going with the original plan and challenging themselves to integrate Bolt 2. Even if it will take you until 2022 instead, it would be a much better feature-set to have in the long-term.

(The open source idea suggested is nice, though not ideal due to our lack of access to Unity core source and thus inability to do tight integration. But I would gladly take it over simply putting Bolt 2 away in a vault forever.)
---------------------------------------

On the subject of Unity's recent issues with "siloed technology" though, I would argue the issue is more so many features being released way earlier than they should have been. That is the unfortunate downside to allowing everyone to be an alpha tester for your features, people just start using it and expecting things to work and not change much, no matter the label of "preview", especially with the age of Youtubers showing off flashy new features that aren't production ready to hundreds of thousands of people as soon as they're available. This is the reason certain other big engines avoid these complaints, they don't really involve the average user and only give public access when the feature actually is production ready or very close.

Not that I'm arguing against this more open system, because it is much nicer to have more community input, like we're able to have in this thread; just that it should be recognized as a source of problems more so than the tackling of a big feature that frequently changes over its development is, because normally those changes wouldn't be seen/felt by the users. I think these effects are being amplified and felt by the Unity team more right now due to the fact Unity has been going through a big transformation these past few years in trying to replace so many of its core systems, especially the rendering system and development direction missteps that has led to. But Unity is starting to come out the other side of this transformation now and the worries should start to lower, so I hope the weight of the problems that arose during it don't stifle the drive to push innovative features instead of status quo.

 

One of the things that worries me is the sheer number of bugs that seem to be in the current version of unity bolt (in part to the ide changes) but when you get stuck with nodes on your mouse and unable to delete the links between nodes or stuck with the node search window and have to make a new node you don’t want because you can’t cancel it.

It feels a bit like looking at your friend in a hospital bed. unsure whether they are gonna be ok

 

Definitely frustrating news to me.
I come from a technical artist / game design background, and have tried most of VS solutions around. They all have their own quirks, and whatnot. Pros and Cons... but ultimately every one of those fails in one critical thing. They can not be used in any production because of the performance.

When I tried Bolt1 a while back, it was disappointing because of the performance just like any other VS solutions out there. In fact, it was even slower than the playmaker which I have had a lot of experience with. Eventually I was frustrated enough that I just ended up learning C# myself, and had been working in C# directly since then. However, even now, I really wish there was a competent VS solution that can put both visual node's presentations with the competent performance, as I am very visual person. I find it much easier to construct / play with / Debug in visual flow than in text format.

I'm not sure who's keep thinking that the artists and writers and designers don't want a releasable modern product. That those *imaginary and yet non-technical* people want some shiny tools that's just good enough to make a flappy bird or an Angry Bird clones. But the games they want to make aren't just those antiquated simple examples, but also include the likes of fortnites, Overwatches, Mario Karts, and whatnot as well, and all VS so far can only say "You can make a prototype of them"...

I really think Unity should try to make a full fledged games out of the Bolt1, see where that goes, instead of bunch of tutorials that hits a brick wall, the moment you want to get out of the tutorial scale. I don't know if Bolt2 was the right answer, but it certainly felt miles ahead compared to the Bolt1 in that respect.

Please. I sincerely hope whatever Unity's VS's top priority should be to provide a visual tools to build a releasable product. Whether the user just wants to build the next flappy bird, or the next Overwatch, the tool should allow that progression, instead of it being good enough for just the flappy bird. If it's not good enough for that, then the name shouldn't even be *Visual Scripting*, but rather *Visual Prototyping* because that's all it's good for in the practical world.

 

Visual Scripting was never meant to replace coding. It's a tool like any other and should be used wisely like any other. (e.g. ImGUI is a great UI tool about all productions use, yet nobody uses it to make their real game UI).

You cannot build the next Overwatch with visual scripting because no tool can do everything. You cannot do Netcode, shader programs, animation state machines, AI behaviour trees, UI scripting, etc. with 1 single do-it-all tool.

Sure, performant Visual Scripting would be cool, but would you be willing to lose features for it? Unfortunately, nothing is free.

 

For a large group of people it can be a better interface for coding, no it will not replace coding ( visual scripting is a form of coding )

And features can be build in c# or in visual scripting blocks.

 

You can't do UI scripting, AI behavior trees (and overall AIs), basic netcode synchronization with 1 single do it all tool like visual studio? Half of the stuff you wrote here are the most basic things a game can do and they should be done with VS for the sake of development time, which is always the biggest cost of making games.

You literally can make overwatch with VS, it's just going to run slower. How much depends on which tool you are going to use it. Sometimes the game will be unplayable, other times no one is going to see a big difference.

The stuff that should be done in code are complex systems, like transport of packages, 2D/ 3D grid systems, pathfinding systems, more advanced shaders. They can take noticeable processing time in a game (unlike to what you should do with visual scripting).

What feature (singular) do you lose by having code generation like in bolt 2? I know that making a new nodes is harder but that's only it.

 

Earlier in the thread:

 

Soo, What feature do you lose again?

Code generation for mono and dots with visual scripting can be done, and there are tools for each. Unity didn't want it because you lose something with it but because It's too much work to maintain code generation.

 

People have made and are making games entirely in visual script. With Blueprints, with Playmaker, with Flow/Node Canvas. I've made a card game framework almost entirely driven by Bolt for a client. There are plenty of commercially successful games that are developed almost entirely in VS tools like The First Tree.

For most game types indies develop solo or in small teams, some missing features don't really matter that much. Bolt 1 can do about 90-95% C# can. Bolt 2 could do just about anything C# can except polymorphism and async/await. The missing features can be handled with some simple C# wrappers quite easily too. And Bolt 2 had native performance via generated C# code. Visual scripting is still coding, it's simply a different language, a visual one with benefits like much easier debugging when you can visually see the execution order and values being passed on connections in real time, or easier prototyping since you can edit graphs at runtime and instantly see results without compilation or even exiting Play mode.

The perception that the scope of Visual Scripting should be limited to simple level designer tasks like scripting doors and animator state machines is common in AAA and perhaps AA gamedev world. They have large teams with large budgets and people dedicated to writing custom nodes and people dedicated to rewriting slow VS implementations of puzzles/minigames into native engine code. Like that recent Kingdom Hearts vid on Unreal Engine Youtube channel, where they absolutely loved Blueprints for iterating on design but then rewrote all of it to C++ once the design was finalized.

At a smaller indie scale for us solo developers and small teams, we don't have resources to rewrite VS implementations to native code or spare limited programming resources on custom node implementation for designers. Lazlo acknowledged that with Bolt 2.

Bolt 2’s design considered visual scripting as a first-class citizen and that's why so many of us were onboard. There was finally a tool in development that was both feature rich and performant and solved almost all VS scripting issues currently present in other Unity visual scripting systems in the store. The two main ones being performance and structure. And unlike Blueprints limited nativization process, Bolt 2 would've generated native, human readable code for all its features. It was quite literally the holy grail of visual scripting.

The directional change has its benefits for sure. I like the VS tool unification goal. I would definitely like a more streamlined (and documented) API for implementing custom nodes. Shipping new functionality over the web or in asset bundles sounds nice in theory but doesn't really apply to me or teams I'm a part of - this is mobile game and games as a service territory. We don't do any of those.

So the refocus on high level nodes in many ways feels like a step back since performance once again will probably be an issue. And it's essentially a whole philosophy shift. Bolt 2 was all about having a robust set of tools and structure that would let users make just about any game they imagine, it had performance by default without the need for handwritten C# although you could still freely interface with it.

This meant that let’s say a level designer not only could make anything they imagine without bothering programmers, their implemented code (assuming good practices are in place) would also run almost the same as hand written code. Meanwhile, Unity Visual Scripting is all about custom implemented high level nodes it seems. Assuming that's correct, then most of the organizational, structural and functional responsibility is on programmers (and not the tool) to ensure. Only time will tell.

All this VS in Unity uncertainty has pushed me to phase Bolt (and any 3rd party VS tool) out of my workflow and towards frameworks like Unity Atoms, which I'm enjoying a lot in my recent client projects. I wish I had the debugging power of Bolt at times but it's just not performant enough and still has bugs reported a long time ago (6 months or more) that haven't been fixed to this day.

 

@msfredb7 Guess if this was made with a) pure text coding b) some text coding and some visual scripting or c) pure visual scripting: https://store.steampowered.com/app/673130/AMID_EVIL/

I assume you're an advocate of visual scripting for some aspects of development, but not all of it (otherwise you wouldn't be engaging in a VS thread on a VS board); graphs are just the intermediate between the programmer and the engine, if you can do one thing, you can do all things.

 

Bolt had a huge caring community and at this point, still does.

Here is a re-post for UAlive, that will in a few months time generate C# and much more is planed ..
For any that are interested or want to help >> https://forum.unity.com/threads/fre...to-compiled-c-generation.918518/#post-6231285

Also 2 days ago I found a new release from a community member giving back.....here is a library of 100+ Bolt Super Units ( free ) https://assetstore.unity.com/packages/tools/visual-scripting/bolt-super-units-177410

 

2 myths
#1 - visual scripting can't be performant
#2 - visual scripting is necessary node base interface

Adressing #1 the real reason it's slow it's because the execution structure is like this:

Visual scripting -> C# -> IL -> C++ -> assembly* -> machine code

*assembly (asm) has some high level aspects it's not a 1 to 1 mapping to machine code

There is no reason you can't do:

Visual scripting -> assembly

But in unity we could expect more like

Visual scripting -> IL

In fact Visual scripting can be a first class performance representation, every time I show a graph, the arrow mean compilation, at the language to asm level the compiler use an internal representation that is a parse tree:


As you can see it closely ressemble the usual node graph expression structure, which mean the visual graph could be translated directly into the parse tree, be optimized, then compile directly to asm.

Could be...

The real reason text based coding is faster is because we have a tradition of nerding over its syntax before visual anything could be a reality, we have academic infrastructure thinking about text code structure all day long (who is old enough to remember when Dijkstra single handedly killed the GOTO instructions so hard it became a meme before meme was a thing? https://en.wikipedia.org/wiki/Considered_harmful ), while visual encoding and manipulation hasn't have that depth of reasoning behind, and most people just implement it as a dumb toy to calm the "whiny dumb kids" (as they see artist and designer) to let the "real adult" in the place do real programming job. IF we don't get past that mentality, visual coding will remain a dumb toy.

I would also need to quote the actual creator of modern programming language, Grace Hopper, on how people resisted the idea of using toy like a dumb high level language that need to go through a compiler, while real men did machine code, and before that machine code was looked down in favor of actual wiring the hardware ... History repeat itself, we haven't learn from the past.

 

I strongly agree with Ex-Crow, Neoshaman and others has already said. Of course I don't expect VS to completely replace every aspect of the programing, and that's not even what I'm asking for anyway. I'm asking for the VS to have the performance as one of the key aspect when the VS is being developed, instead of being a second citizen, and again, mostly treated as if it's for just tutorials and simple games.
You can make many games using purely VS of course, I certainly made couple of games myself and some with different partners mostly out of Playmaker before. But because of the rather significant overheads in performances, there *is* a clear limitation to what type of games or *scales* of the games you can make. That was already frustrating, but from my experience, Bolt1 was even slower to work with.
My argument is, *if* Unity is trying to unity number of VS solutions they were developing, then why not start from something that can have a much better performance to begin with, instead of, again, basing off of something that's good for tutorials? And in that regard, it's very disappointing to see them choosing to go with Bolt 1, instead of starting with Bolt2.

As I mentioned before, after all the frustrations with various VS solutions, in the end, I ended up using C# directly for number of years already, but for the life of me, I still miss the visual representations and working of the the scripts, set ups, flows, and debugging. If the overhead cost wasn't just so damn much, I'd prefer using a VS anytime.

And someone said people shouldn't use VS to make Overwatch type of games earlier. Why not? That's ridiculous assumption to have, and just the thoughts that I hope isn't part of the VS design team at Unity. I applauded when the cofounder of Unity said "I don't want to F*** around with double, or triple performance boost for the next couple of years. I want 100X performance, so we are doing DOT, and figure out how to get there together". It showed a great industry leader, that says no to the *norm*. They are the leader, and what work on becomes the norm, instead of them chasing the norm.
VS is a different development tool, a programming tool. It might use a different interface and paradigm for different type of Developers, but nevertheless it's a development tool. If so, then the performance should be part of the consideration at its core and any issues associated with it should be solved, instead of "if you want more than the angry birds, then learn to type the code in". And Unity VS team choosing to start from Bolt1 is rather disappointing.

 

That said, Imho they need the dumb down bolt 1 for the visualization and audio visual market they are chasing on, ie those who don't need the performance pressure of game, which the shafer graph appeal to too. Like I said before in another thread, when management want you to have an architectural presentation by 15h this afternoon for meeting, they don't gave a frak about knowing vertex lighting, dots, or if it run on little timmy's integrated gpu, and whatever interactivity there is ain't skyrim either.

I have the feeling that unity will simply ghost us to appeal to that market for a while. The report on the ipo imply they need money yesterday...

 

Here's a question: Is it posible to use bolt on non playmode in the editor?

I know playmaker only works in playmode, I would like to use bolt to create some links to editor scripts

I would like to use bolt in the same way as "drivers" in blender.

 

Bolt 1 has a community extension that lets you execute a flow in editor mode - it's like a custom event, but with a button on it you can press manually. It has some limitations, though. But there's nothing that would execute every frame.

 

Thanks! thats good news

 

I do not understand why you adquired Bolt instead of Playmaker if your aim was to develop a high-level visual scripting. I am not a big fan of Bolt but you are destroying it. Bolt was designed with a different mindset. You are making your life harder. Bolt users are dissapointed too. You do not listen to your users. Go to Discord. Read what users are saying. A lot of people is migrating to UE. Who says that game development has to be dummy-oriented?

 

i am going to use unigine for my next project. that said there is unode to look forward to right now, unless unity is gonna ruin that too, somehow.

that said, lets see where is the so called roadmap or technical reasoning that was supposed to be posted 2 weeks ago.
dont keep your hopes up, it will be 3 years before, bolt would be any usable and thats a big IF.

 

I'm new to programming and game design but came from much simpler visual scripting in the HVAC industry. This post is so spot on even though I don't follow every point. I've just started learning bolt, and could already tell many of these things were missing and so went searching for bolt 2 info I had seen. I believe visual scripting is the future, I think many do. Unity, maybe you could reconsider if the feedback is there and the decision is still fresh...