Does a professional need Visual Scripting

Hi all,
I am a programmer (20 years now)
I like coding and I am free enough to write the code I need.
However, still, the colors and styles of visual scripting are alluring to me. Is there any logical reason for me to still learn visual scripting and using it?

 

If you do it cleverly, you can use this system to develop state machines quickly. The performance will still be abysmal, comparing to handmade code though...

 

For a coder Bolt state machines are not that useful - you can't custom code a state. You can only use reflection to access your existing C# script code or custom code Bolt nodes, but current Bolt node API isn't documented and is being phased out and replaced with something else they have in the works. Bolt also doesn't know which state is currently active since you can nest Bolt states infinitely or have multiple states active at the same time by marking multiple states as Start states.

In general though, visual scripting is very useful for one-off logic like scripting level design related stuff - doors, traps, various triggers that are unique to the level. Or for adventure games where intractable hotspots have bespoke requirements, triggers, dialogue, etc. ie VS is great for scripting high level logic fast, great for visualizing AI and for organizing your C# code into a visual flow, for example, having a visual state machine for your user interface.

So it highly depends on the kind of game you're making - if it has bespoke logic that does not repeat elsewhere in the game or if you want to visualize complex AI, UI, etc flows.

 

25+ year developer here, everything from FORTRAN to Typescript, and I have fallen in love with visual scripting for rapidly prototyping, experimenting with new ideas, and learning the intricacies of the Unity API.

To me the biggest pros are:
- Can write loosely coupled "superunits" that can be easily reused in many places
- Editor runtime visualization of behavior basically gives you a degree of debug logging for free
- Can modify logic while the app is running in editor and see the results instantly, without the cycle of "stop app - change one line - recompile - start app"

Anecdote about the last bit - I was trying to get a network character controller to do what I wanted, and did not understand what some of the vector math i cargo-culted was doing... it was literally 3 lines of (albeit complex) code. I spent a couple hours of "stop app - change one line - recompile - start app" with no success. I finally said "f it" and changed the code to just fire a CustomEvent that a visual script could respond to. I spent 2 minutes reimplementing the vector math in a visual script.

INSTANTLY, I could see which vector math functions were not returning the results I expected them to. It took about 5 more minutes of trying different methods in the visual script to see what I needed to change. I didn't need to stop the app, or write a single line of code, or recompile.

Once I'm past prototyping, if the project goes anywhere, I imagine I'll want to translate some of the visual scripts into C# -- which should be trivial. The main reason is that visual scripts do not diff nicely. Once there's another developer working on the project (or even me 3 months later), there will be a lot of suffering if we can't see what each other are changing in every commit. Other things like type safety and getting rid of magic-string variable names are needed once a project grows to a certain scale.

But in terms of "quickly getting stuff to work", visual scripting beats C# hands down, imo.

 

When I started programming with Unity C# was a Jungle and Visual Scripting (Bolt) was Heaven to me (Colors and pipes etc.)
However Bolt wasn't free those times and I didn't get it. It was also a sad experience.
But in one month I learnt C#.
and now several lines of codes do everything I want.
Besides I am not bounded any 3th party plugins (VS).
For the sake of freedom, practicality and deep solving ability I vote C# today.

 

I didn't know how to code, so I got into Bolt. It was a struggle at first because you don't need to code anything but you still need to understand many things that are basically taken as a given when coding. So eventually, after learning how to use Bolt for more advanced stuff, I realized I knew the basics to code. So I started learning and I finally understood what Bolt was doing and what that meant in code.

Long story short, Bolt helped me to learn how to code in a way and how to understand Unity as well. I don't use Bolt anymore.
Maintaining big Flow Machines is so tricky, terrible spaghetti no matter how clean and organized you are.

 

I agree that Bolt is a poor C# replacement when used as such. But it doesn't have to be one or the other. Bolt works best when used for orchestrating your C# code via reflected nodes or with custom coded high level nodes.