What is your opinion on Bolt visual scripting?

So I've given it a try before and couldn't really get it to work as I wanted, but I've watched a video this morning about someone using visual scripting in one engine and using that and turning it into code despite being bad at it "or so they said" and I thought that might be a good way for me to finally learn how to make sense of programming as I can never manage to despite learning it for years xd

Has anyone used it here? Is it any good or just a waste of time?

Thanks in advance, also if you have used it and could link anything that would help me in figuring bolt out I'd appreciate it

https://sarkarijobs.gen.in/

 

From my few experiences with Bolt I wouldn't recommend it for learning code. Also it throws too many errors that I don't understand. Makes a lot of things more complex than they really are. But this is only from my perspective as a person that didn't use a lot of visual scripting tools.

 

I have been using unity for quite a few years now (since unity 4.5 I guess) and still for me the preferred way of creating logic is through code,
Bolt's current implementation just screams at me for optimization in any real-world usage, it's just done in a really unoptimized way, even the variables are not type-safe, it has a lot of potentials as shown by unreal's blueprint system but bolt has quite a long way to go
Currently, it's really unintuitive for me to use it especially because I need to create core gameplay systems and that for sure can't be based on such an unstable and performance-heavy base and as far as prototyping goes it's still far easier to create a script with intended features then bolt's current UX

Although I do hope it changes for the best because as a programmer it will be much easier to provide a tool for designers but right now it's not for me

 

I tried Bolt for quite a bit and I was very underwhelmed. Really poor performance, no type safety, no refactoring tools and it doesn't tell you that something is broken until you hit the broken piece of logic, which can be absolutely catastrophic if that sneaks into a released project, which is a very real possibility

It also lacks most C# features which makes it very limited in what you can actually do.
No delegate/event support for example is a massive problem in my eyes. And their custom event system that, kind of, serves a similar purpose is string based.
Other things that come to mind is no inheritance, interface, struct, #define or generics support.

Unreal Blueprints really helped me understand how code gets executed and flows.
After getting comfortable with it I've stopped programming visually almost completely.
Exceptions are HFSM or BT systems for AI/Character States which can really benefit from being visual.
I think that visual programming has its place, but Bolt need some serious development before I will ever consider using it in an actual released project. Right now it's a nice toy, and can be useful to learn code flow. But for actual projects I would stay the hell away, it's a mine field.

If you want a good visual programming solution that is very well battle tested, look into Paradox Notion stuff on the Asset Store.

 

Absolutely not waste of time. I'll tell you why. Coding is very hard. It's very hard and very boring. Have you seen these coding videos as a noob? You cant stay awake. I tried so much to understand it but like you I just can't take it. Every video is like disarming a nuclear bomb. You have to refer back to the code you are copying, trying to put all the syntax in place. etc etc. All of this in another editor. And then when you get the code working you don't want to change it, because you might break something and forget what it is you broke, because you have so many variables, and you have to keep reffering to your variables in the main body of your functions, so you have to read these god awful names of functions with underscores, etc etc etc.

It will work if you do it that way. You will become great at code. You will be super employable and your salary will sky rocket. So do it that way if you "want to be a coder".

However, if you want to have fun while learning how code works, choose Bolt, for your sanity. You have already said you just can't get code, so I'm presuming you actually know the basics but are struggling with an overview of how all these things fit together. Bolt is great for that. The color coding, only allowing particular ports to be joined together, the graph inspector, the "variables as a particular colour box", these are great helpers for to learn how the overall machine works. You are learning a lot of coding, but it's like it's for kids. You just hook things up because you can and it takes 10 seconds rather than 2 minutes.

Your performance might suffer, but what do you care? really? it's not like you're actually shipping a game anytime soon. If you do then you presumably port it to C# manually.

 

Bolt is great for Unity newbies, especially visual thinkers. It abstracts a lot of the initial complexity of C# and lets you focus on the design of your code with far better feedback on what's working or not working when compared to C#. This is why it's great for beginners. Later, the switch from Bolt to C# is nearly seamless too. So starting with Bolt and then graduating to C# would be my suggested learning path.

Bolt 1 in its current state, however, is not fit for production. It lacks too many quality of life features, has fundamental design issues, and it eventually breaks down because of outdated tech it's based on such as FullSerializer or perhaps because the tool has never been stress tested in a major production project and it just crumbles under large amounts of data ie when you have a lot of custom types added. But most users won't come across the latter issue unless they're a year or two into a serious project.

The current main Bolt 1 issues:

1. Performance - reflection based runtime severely limits the application of this tool. You'd think Bolt would be good for simple games and in a sense it is if you're targeting Desktop, but mobile suffers both from bad performance and noticeably increased loading times.
2. Variables system doesn't scale - it's fine for a small project but once your project grows, there's no way to organize or refactor variables. That's on top of all the other issues that originate from a loosely typed system such as not knowing the type of the variable in graph unless you manually look it up in a completely different window.
   
3. The only way of communicating between graphs are custom events which are based on strings. There's no way to view how many custom events exist in a project, where they are, what calls or receives them. You can't refactor them either.
   
4. Bolt's UI is IMGUI based, so it suffers from the same issue all other IMGUI based graph tools suffer from - it tanks editor framerate which often makes the game untestable in the editor unless you close all of Bolt's windows. Except, Bolt's errors in console when clicked do nothing, so you have to have the graph editor always open to debug your logic.
5. Bolt's API was considered "unstable" by the original developer of the asset, which is why it was never documented. Custom node writing therefore has never been well supported in various ways such as nodes breaking in graphs when value ports are added or removed. And a compilation error inside custom node code can break Bolt, sometimes irreversibly. And these broken graphs have to be discovered manually by clicking and viewing each graph individually since clicking errors in console does nothing. So even though Bolt's shortcomings can be coded away somewhat, it's cumbersome. Prepare for dozens of lost hours dealing with this unsupported pipeline.
   
6. Limited support for basic Unity C# features, such as delegates/callbacks and custom generics, which forces you to write custom nodes. See point 5 why this is not pleasant.

I could still name a good dozen issues with the tool right now.

According to Roadmap and previous official announcement threads, Unity will replace the current runtime with a new, much more performant runtime. They also have promised they'll improve both the variables and custom events systems, though it remains to be seen in what ways - if they'll be strongly typed. They're also working on replacing the current UI with their new Graph Foundations UI layer and a new API that's not based on the current API and will eventually be documented.

So in a couple of years Bolt might actually be production ready. Until then, I'm sticking with C#. (If I was a complete beginner though, I'd start with Bolt. I couldn't wrap my head around C# in text form, but Bolt really revealed to me how code flows and how Unity is structured. Bolt's intelligent search, context relevant results, realtime code analysis and Play mode editing enables the user to explore and experiment in ways that just don't exist in C#. Bolt assumes the user doesn't know what they want to write, C# assumes the user knows exactly what to write).

And if anyone is in serious need for a competent, production ready VS tool then look into Flow Canvas/Node Canvas combo. Those (unlike Bolt) are proven in production in well known indie and AA games such as The Long Dark, Graveyard Keeper and Kingdom series.

 

Remembering that most of these problems are currently being treated ... So it is likely that by 2021.LTS everything is already well underway

 

2021LTS is more than a year away. All of that will definitely be underway, just not finished or battle tested, therefore not production ready. Even if they manage to do all of that in a single year, I still wouldn't consider it production ready until the new changes have matured. My personal experience has shown that adapting new Unity tech is not worth it for my projects unless it's been out for a while - at least a year.

 

Or you could use Playmaker in the meantime. It's a different kind of visual coding, probably higher level, but by now there's literally an action (equivalent of a method) for about any case you can think of.

 

I am just a hobby developer, but I really like the visual scripting tool. Have been using C# a while and before that C/C++ (professional at work). It took me some time to get used to get the right nodes in the graph, but after a while I figured it ou. And then, it started to be fast to get things up and running. I guess a combination of visual scripting and C# wold be a very powerful combination.

 

Bolt is terrible, cant even do simple things that are 1 line long in C#, the "coding" is very slow (why do I have to do 4 clicks to enter super unit??). The community is also bad, the amount of documentation and tutorial is almost zero. I made 3 topics here with questions and got zero answers. Now I started using C# and already doing things faster and on bigger scale than I would in Bolt.

 

Hand coding is certainly faster at doing a great many things but the point of visual coding is to manage more complex operations in a visual way that speaks to people who want to see the logic of the code in a more obvious way. It gets time to get used reading classical code while visual organizing has advantages.

 

I agree with that!

I finally managed to create a Finite State Machine with super nodes, and I must say that following the signals in the graph when running the FSM is very helpful. Visual Scripting can be useful just to visualize complex logic. Imagine to create a digital twin of a fully automated distribution center with Visual scripting and gameobjects in Unity

 

It is very good...well at the beginning that is. As time goes on, you'll eventually need to type in some script since there is some limitations to bolt. Like referencing a script. In standard C#, in order to get a script, it has to be referenced through GetComponent<>, and even then, you will need and object to even use GetComponent<> that the script is in. Bolt is good, not going to lie but I started Unity with Bolt. It just that even after starting to learn how to script, Bolt doesn't really prepare you for that. Of course, it does cover the basics but even then, scripting alone is something that has to be learned, not built from. What's worse is sometimes how if you try to put an object from the project tab, the object that the macro is in needs to be also in the project folder, and traditional C#, it doesn't matter whether the object is in the project folder or not. I can't say how it is now since it's been months since I use Bol, but all in all it is a very great thing to use. Not recommend being use for business use.

 

I know it is not popular opinion... but as a lone developer I have seen significant gains using Unity Visual Scripting. I would challenge most developers to attempt to understand that the gains from visual scripting are not directly measurable.

My Thoughts
However, I believe the gains can be anywhere from extremely low to high. This is largely dependent on organization and the principles used to structure the visual graphs. It took me a few attempts at completed products, to get a good grasp on better practices. I hope to find time to share what has worked for me in the future.

My Experience
Admittedly, I can certainly code 4 times or more of functional code than with visual script. The noticeable gains were not from the speed of work. I started to notice that my need to reiterate code, started to reduce significantly. I started spending less time rewriting and bug fixing. Almost like a tortoise vs the rabbit(hare) effect. The slow steady accuracy of my structured logic produced a closer to final draft completion of code. Where I would have moments that I spent stuck and have to step away to brainstorm certain complexities of code structure, I never encountered a struggle when using visual scripting.

Of course my opinion is only that, because I am not operating an a sophisticated team structure. I also may just do better overall from the visual aspect of UVS.

Pitfalls
Where Uvs fails like, string based custom events. I use a strict naming convention (with prefix/graphnames) to avoid issues. Replacing variables with scriptable objects. And a few custom nodes I have not encountered anything I couldn't do with uvs that I could with C#.

I can not speak on performance, as I have read the downfalls of performance. My completed projects/product are not performance heavy/hungry. I currently have a Vr project operating with 95% uvs to c# and I'm cruising a 90 fps with handtracking 2.0 on the meta quest 2. C# is only used for the quest hands themselves.

 

After trying Visual scripting I filled 3 bug rapports within 2 days and stopped using it.
I also noticed that if the case file id's are correct that there around 120 bug rapports filled per day for Unity in general.
So i don't think fixes will be any time soon.
I do know that visual scripting will be completely changed in the future. So i don't think does bug rapports will get any priority.
The many bugs is also the problem with Unity in general. New and replacement components (UI, Input / networking / DOTS etc) are added all the time while a bucket load of bugs remain and only increases witch each 'new' item. After each survey this is mentioned and improvements in bug fixing are promised but if you keep replacing components and adding new stuff the bug count will onyl increase not decrease. So that will never change i bet.

 

Since people are necroing the thread, my opinion from more than a year ago hasn't changed. Bolt/UVS has received a few minors bugfixes but the fundamental issues remain.

 

Don't you have a massive asset spam with scriptable object based variables? Or do scriptable objects hold more than one variable? And how do you work around values not resetting when exiting play mode? Do you reset them to some default value that's also on the scriptable object?

 

I made an extremely simplified version of Unity Atoms (https://github.com/unity-atoms/unity-atoms) for visual scripting. I keep all variables organized in a folder with sub folders to separate functions. The scriptable object base class includes a previous value and current value of every variable to help with bug testing. The values never reset after play mode. However they do reset after the editor is closed unless the are explicitly set.

The base class includes a method to add/subtract/reset and hook a delegate to listen to any changes. All I do, is right click in the project folder and I select a variable type of choice including list types. Or i can drag the variable asset directly into the graph to choose a variety of actions to perform with it.

It helps somewhat simulate an MVC (Model View Controller) approach by keeping all data separate. I'll probably share it as soon as I can get to it.

Asset spam? Perhaps, It hasn't bothered me at all if you mean a folder full of scriptable objects. I have anywhere from 5 - 50 to a folder group. The only time i use UVS blackboard variables is to referenced game objects/components in scene. Searching my project folder is much more convenient that digging graphs and every SO(scriptable object) is global. SO can be renamed without breaking references as well.

I transfer a fair amount of data via server as well, so I will use a scriptable object with on large class of variables to keep json imports to minimum of one unity web request.

 

I last used Bolt about a year ago. i was getting very familiar with it, and not knowing much about C# scripting, it gave me a good view of how the C# underneath worked. However, eventually I didn't like that there were so much nodes, and wires to follow. Things were less easily recognisable. Also I knew performance would be an issue eventually, and I didn't want to invest time into something if in the end I would have to learn C# anyway. So I have been learning C# instead, but I do recommend Bolt for new users or artists who don't want to go into typing C# directly. It's actually an arguably better teacher of Unity api than anything else out there. In fact I might just install it again, because the way of browsing methods is way more faster, pleasant than in VStudio.

 

My opinion. While Bolt are a pain almost ever, also a big C# project becoming from another people sucks too. And I think that at least, will be good a cross-made way to visual and C# code, so it´s fast to recognize the program flow. Visual or Scripting Code are useless without understand what happens. A tool to make that will be more useful.

 

Try Playmaker, it's extremely streamlined in comparison and gives you ample control over the functions in your game.