Well, from my own expierience, visual scripting is just "another language to learn"...

It might no scare away coding newbies with ugly ASCII characters, but its still some kind of "Syntax" you have to learn and understand.

From my own expierience with Unreal Blueprint system, it is a Syntax that is not necessarily easier to learn.

I found the Node based Shader system of UE4 really easy to get into, and very powerful once you understood all the options. After some months of experimentation, I feel comfortable creating quite complex shaders, and even at the beginning I learned stuff fast. Its just intuitive.

The rest of the blueprint system on the other hand is just a nightmare for me. Complex code turns into a visual mess (which sadly is also true for the Shader editor), if you are trying to look up information online the documentation is lacking, and worst of all, the name of the nodes shown in the node editor doesn't match the name of the nodes in the selection list.

The logic of the different node types and flow is not really tied to the logic that would be used in a C++ script.

My guess is, if a Game Designer or artists takes the time to get into Blueprint and really get good at it, he would have learned C# basics by then. Maybe even more than basics, or C++.

So to me, yes, Visual Scripting really has some merit. It can ease the step from zero to coder, and it can enrich the existing code possibilities of an engine.

It does not do away with the need for a good traditional API though. Unity C# API is really good and well documented. I would say a good coder will be faster writing production ready C# code than trying to bash a visual script into a production ready state. All the while the resulting "code" will be easier to read and maintain in the long run.

However, if the visual scripting systems get more intuitive for everyone, they might serve well for quick prototyping. Or as glue code, so that non-coders could combine functions written by the coders into finished game objects, and free the coders to write more important stuff.

There is a new engine again and I think it has a visual scripting editor same as Unreal. Question though when do you use Visual scripting and when do you do coding? VS is use mainly on gameplay I think and if that's the case then will there be a time that coding will be replace by VS on game engines? Cause Unreal have VS, Cryengine have VS and infact they all encourage people to use VS rather than coding(since most tutorial focus more on VS tbh. For example unreal. There are too many tutorials about blueprints.)

When to use either is entirely subjective, but in the objective sense of their express purpose, a VSL stops being useful when what you need to do is going to limit your production to a given platform (0 portability) or custom environment that is unsupported.

Their popularity in game engines is reasonable, given that game design in many cases tends to the visual, making coding in the same manner more viable than say... writing a bank's loan and interest processing schedule with them.

We are already seeing instances of Games' creator(s) expressing that they do not know how to 'program' at all, but managed to produce quality results regardless.. so replacing the direct method with a visual tool is clearly viable, but as with all things, they are not universally applicable.
Complete replacement with visual methods is unlikely to happen before we reach the point of being able to create from natural language.. describe what you want and it is created for you.

Going forward, we will certainly see them become more common. As we did with IDEs, as we did with high level languages, as we did with Assembler over Machine code.
It is just another step in the evolution or programming.

(too many tutorials about blueprints)
I felt the same way when everything turned "Object Oriented."

Visual tools are not scalable and do not produce long-term maintainable programs (although as the tools mature, that last may be remedied a bit -- source control integration for example).

There's nothing wrong with them for small simple things that do not need to live very long. The kinds of games most beginners write will fall in to this category, so I can only see them as a good technology for introducing people into the world of programming.

I would be curious to know what you see in a VSL as limiting to scalability.

"small simple things" && "most beginners" -
While they do lower the threshold for beginners to enter the field and begin learning, they are not by any means limited to or centered around that.

The most used VSL currently is that in UE4, Kismet. It has already been central to the development of a number of AAA Titles, and is a key production tool in dozens more currently in production.
From more recognized titles like (Lionhead Studios) Fable; Legends and (namco) Tekken 7, to EA and upcoming games like (wildcard) Ark and inXile's planned rebirth of a franchise with Bard's Tale 4.

VSLs evolved quickly, and in their (general) present state, offer access to all of the portable features of their parent language. And of course, if you want to reach deeper into a given platform at the cost of that portability, you can always write that into the VSL.

Visual tools are not scalable and do not produce long-term maintainable programs (although as the tools mature, that last may be remedied a bit -- source control integration for example).

There's nothing wrong with them for small simple things that do not need to live very long. The kinds of games most beginners write will fall in to this category, so I can only see them as a good technology for introducing people into the world of programming.

I would be curious to know what you see in a VSL as limiting to scalability.

"small simple things" && "most beginners" -
While they do lower the threshold for beginners to enter the field and begin learning, they are not by any means limited to or centered around that.

The most used VSL currently is that in UE4, Kismet. It has already been central to the development of a number of AAA Titles, and is a key production tool in dozens more currently in production.
From more recognized titles like (Lionhead Studios) Fable; Legends and (namco) Tekken 7, to EA and upcoming games like (wildcard) Ark and inXile's planned rebirth of a franchise with Bard's Tale 4.

VSLs evolved quickly, and in their (general) present state, offer access to all of the portable features of their parent language. And of course, if you want to reach deeper into a given platform at the cost of that portability, you can always write that into the VSL.

Kismet has been superseeded by blueprint AFAIK... but you most probably already know that and made a typo.

I think if you start developing more complex Blueprints, you will see where visual scripting stops making sense. The visual chaos is just not worth it. Of course you can organize the script into smaller parts and use Macros and whatnot to make it visually more managable. Still, harder to read than well organized code in a good IDE for sure.

I second Bregmas concerns about Source control. Given that I don't know really if the blueprints are stored as ASCII or binary, the version control options might be more limited than with C++ code.

I would dare to guess that AAA titles using blueprint are not using it as their sole, or even main programming language, with most of the games (more complex) logic still being written in C++.

There is a tangible gain using visual scripting to allow Level Designers to create the small, simple scripts needed to get their levels going (open a door when the player gets near, stuff like that)... or give Game Designers a tool to prove if their newest idea MIGHT be a good addition, without disturbing the coders from working on more important stuff.

I don't think we will see big AAA titles firing their coders anytime soon and shifting their responsibility to the level designers and game designers. And I don't think a programmer will be using visual scripting for anything more than where it actually makes sense (simple quick scripts, prototypes, shaders)... if C++ is the quicker way to do it, and you are fluent in C++, why go through the whole Blueprint hassle?