Visual scripting being removed / beta very close

Yeah, it makes sense. The visual scripting never really worked and was badly maintained. It was basically just the GDScript API in visual form, which is not very useful. Because in order to use it, you'd need to know how to use GDScript, in which case it would be easier and faster to just write the code. Blueprints and some other visual languages provide a lot of helpers and high-level constructs, which Godot was missing. So I can understand dropping it, since no one was using it and it would be a ton of work to do properly.

cybereality One because it wasn't very well designed or implemented

If it was improved, then it would be used.

I'll just remind that:

It can be a great tool for non-programmers like game designers and artists.

This phrase is particularly amusing now:

In fact, Visual Scripting integrates so well to Godot that it's hard to believe it was added only in version 3.0.

I would use visual scripting and shadergraph, if they were good/well designed. IMO they never were.

cybereality A bunch of people (mostly people NOT using Godot) requested the feature,

I was one of the voices asking for visual scripting, and I don't think we really got what was asked. But there were like a billion voices each asking for something different tbqh.

Tomcat If it was improved, then it would be used.

I honestly think it was beyond saving/improvement. I'd rather see someone create a new system from scratch, which might well become an opportunity now.

duane At the risk of repeating myself again, godot is free software -- if you want something, the best way to get it is to add it yourself. If you want visual scripting to continue, find some fellow enthusiasts, start a project, and build it the right way.

With GD extensions that will likely be a very valid and viable options option, even now with GDNative it might be, though not as convenient. But back then neither of these options even existed.

duane At the risk of repeating myself again, godot is free software -- if you want something, the best way to get it is to add it yourself.

It is a perverse argument and a road to nowhere. If, for example, you decide to bake a bun, do you start by ploughing the land, planting the grain or, still, do you go to the shop to get the flour? If you start adding all the necessary functions yourself, you will no longer have the time or energy for the project itself. This, by the way, is a common mistake made by developers of their own engines.

There is another aspect that is not obvious. Godot is seen as a game engine. Perhaps it will become one at some point. But right now there are no big memorable projects on it. What is there and what has it already achieved? At the moment, it's a great start for learning engines and programming — it's easy to learn initially. And throwing out a pretty serious thing, and visual programming (setting it up) gives important experience, is extremely reckless.

duane No, I would buy a bun or pay someone to sell me dough.

But I would prefer to make the dough myself, as it is the defining feature of home baking. There's already a discussion going on about cooking. But the analogy is actually pretty accurate — to what level game developers can rely on off-the-shelf assets (ready-made ingredients) and when they need to write their own tools.

duane However, in a free software project there usually isn't any money to pay people, so the participants are best advised to do for themselves. When there is money, the people providing the bulk of it generally have the say in where the project goes, not the folks who are using it for free.

The problem with funding free software does exist. There are ideas on how to solve it, but… the "first million" problem isn't going anywhere.

cybereality This is the whole problem, though. Visual scripting is not easier than coding, it's actually harder.

Why do some people think that Visual Scripting is easier to use than GDScript?

My impression is that the main use case would be a team project, where the team includes a non-programming artist. The programmers would set up some pieces of the project using VS, so that the artist could make tweaks to the art without having to use "real code".