Re-implement VisualScript using a 'block and wire' system

[qaptoR]

The system is very straightforward in concept: Scratch-style puzzle-blocks with the flexibility of Blueprint-style node-wiring.

Visual scripting seems to be dominated by a node-wiring paradigm throughout the biggest game-engines, which is great for flexibility and seeing the flow of process logic, however it quickly becomes visually busy and unappealing to work with as scripts become larger and more complicated.

Partly, this complexity can be addressed with an abstraction feature which can encapsulate complicated logic into a simple new node, however, I feel an even more clean approach would be to embrace the verti-linear structure of code blocks as seen implemented with Scratch, and Googles 'Blockly' system. https://developers.google.com/blockly/

Essentially. Wiring would be limited to just the types of blocks necessary to implement the continuation of program flow. That is, most of the program would be written as vertical 'clusters' of code-blocks representing some portion of the necessary logic (ie. a step in whatever process is being achieved), and then wiring would connect that cluster to the next which represents the next step.

For example, when one finds the need to do some complicated process inside a loop or nested loop structure, but would otherwise complicate the present cluster, the wiring flow could break away to a cluster dedicated to the loop, and then come back from the loop to a new cluster which can be directly below the inital cluster before the break-away.

This allows for cleanly putting code aside, while also using the visual layout to describe continuity. It may even be preferable for the first and third cluster to reconnect in a distinct manner to explicitly describe the continuity.

EDIT: This is a very rudimentary mockup that just shows how clusters of blocks can have verti-linear flow much like text-based scripting, but still benefit from wiring flow, allow for a more freeform organization of code. note the verti-linear flow would also help visual scripters transition to text-based scripting

[derkork]

Coudl you maybe post a mockup of how this would look? I have a hard time imagining this.

[fire]

Can you post a photo? I am not sure which of the three types of visual scripting it is.

1. flow based programming (blueprint, godot)
2. blockly
3. event sheets

[lyuma]

My understanding is that all three of these are just different views on the same data.

It should be possible to equivalently structure code in any of those formats. If I understand, @qaptoR, you are proposing to allow users to use nestled blockly/scratch style blocks, and then take multiple of these code blocks and continue flows with wires?

Making functions to split up the code into smaller pieces is another way to do this, but wires could work too. I don't think the proposed paradigm will work if wires are nestled inside code flow.

For example, when one finds the need to do some complicated process inside a loop or nested loop structure, but would otherwise complicate the present cluster, the wiring flow could break away to a cluster dedicated to the loop, and then come back from the loop to a new cluster which can be directly below the inital cluster before the break-away.

I don't know mixing and matching in the way you suggest is possible. For example, imagine you had a loop inside an if statement:

[if enemy_nearby {
    [for i in range(particle_burst_count) {
       [print("Spawn bullet")]
                     ----> spawn bullet ----> ???
    }]
    # is this a separate block? is tick_particles moved below?
    [tick_particles()]
}]
# what about the case where I don't go in the if statement

I wonder if once a particular part of the code has been split up, all the parent blocks would have to be split up. But then what if there is an if statement surrounding the whole function?

Example modified from https://github.com/geekdojo-io/scratch-programming :

Here's some example I threw together with Visual Script adding 1 to transform.origin.y 4 times every frame: prints:

[X: (1, 0, 0), Y: (0, 1, 0), Z: (0, 0, 1), O: (0, 389, 0)]
[X: (1, 0, 0), Y: (0, 1, 0), Z: (0, 0, 1), O: (0, 390, 0)]
[X: (1, 0, 0), Y: (0, 1, 0), Z: (0, 0, 1), O: (0, 391, 0)]
[X: (1, 0, 0), Y: (0, 1, 0), Z: (0, 0, 1), O: (0, 392, 0)]
Hello, World!

Here's an imagining of how scratch style blocks could be done:

How would this be done in this proposal? I imagine that blocks can be pulled out and carry a connecting wire with them, kind of like:

I forgot to change the string being printed, but you can imagine this program would do the following:

Hello, World!
[X: (1, 0, 0), Y: (0, 1, 0), Z: (0, 0, 1), O: (0, 389, 0)]
Hello, World!
[X: (1, 0, 0), Y: (0, 1, 0), Z: (0, 0, 1), O: (0, 390, 0)]
Hello, World!
[X: (1, 0, 0), Y: (0, 1, 0), Z: (0, 0, 1), O: (0, 391, 0)]
Hello, World!
[X: (1, 0, 0), Y: (0, 1, 0), Z: (0, 0, 1), O: (0, 392, 0)]
Hello, World!

That is to say, it would first update the transform, then print Hello, World!, then print the transform. Finally, at the end of the loop, it prints Hello, World! again.

Obviously, the input and output ports in the mockup are in the wrong places, and you'd want arguments to be nestled appropriately, possibly even using shapes to denote \<predicate>, (value) or other special types like what Scratch does.

[qaptoR]

@derkork @fire, there is now a mockup of what the flow could look like

@lyuma has brought up fantastic points.

To address them:

• Wiring flow is different from abstracting logic into a function.
• • Functions specifically hide the logic, forcing the user to go and look for the definition if necessary
• • Wiring flow is like taking the text-based loop, and adding a second parallel column of text, by taking advantage of the visual space available
• I do think that wiring flow should be available inside function abstractions
• flow should only be possible from the end of a statement to another statement or logic/loop body where code can be nested, and it should be explicitly clear when going back to the flow outside of a body from only the end of a body
• • eg. statement A goes into a for loop B
• • inside B we go to statement Ba
• • Ba comes back to B when it ends
• • at the end of loop B we go on to statement C

@fire also brought up the idea of there being 'event sheets', which to me seems like a great idea to help organize code. That is to say I think a single VisualScript file should have the capability of having multiple grapheditor sheets.

Discussion: one way that I feel this would come in very handy (especially with blockly style coding) is when logic becomes increasingly nested which can become tedious to read. Not only that, but even when writing text-based code and nesting becomes increasingly deep, abstracting the nested logic into a function itself can be a cumbersome process, as now every time we need to look at what is happening, we have to jump away to read it, and then jump back. Using wiring flow for this instead would mean there is a direct visual link to where the 'set aside' code is being done, as well as a visual link back to the continuation of mainline logic. I think this would be a strong advantage for visual scripting, as well as take great advantage of the capability of scripting visually.

[charlesmlamb]

First of all, I really like the current visual script, it was getting a 9.6-9.8 feature in Godot 4 . .

If you're gonna develop this, make it something else, please just maintain the current stuff, it's getting very good . . .

1. It's a full coding system, no dumbing down . .
2. It's getting, finally, really nice in Godot 4 . .
3. People that have liked it for years, won't like some new replacement
4. I think this is called 'scratch' coding, and it's not as elegant, or useful as the current stuff . .

So, I suggest if anything, make it a new feature, and, at least keep the current visual script system . . .

[derkork]

I would agree on @charlesmlamb's take here.

First order of business should be making the current system work as a GDExtension with Godot 4. I am currently on this but it is progressing a lot slower than I would like, mainly because the new GDExtension system is very new and needs a lot of tweaks here and there to support all the functionality and engine extension points that the visual scripting needs.

After this has been done, a next step could be incorporating other kinds of visual scripting, e.g. some of the suggestions raised here and maybe also some stuff like state machines and behaviour trees which can tremendously help in rapid prototyping.

Another approach could be to make multiple extensions that use different approaches to visual scripting and then everyone can choose the approach that works best for them (or even combine them).

[3DLAB0]

Working with other horizontal node based visual scripting languages [Bolt, Blueprints, Blender Nodes, Cinema Nodes, etc] I found myself trying to separate operations or data, from the flow that will execute the operations. There are some node based systems with a vertical design, and I think the way they try to tidy the logic is very helpfull.

• Unity's Visual Effect Graph: https://docs.unity3d.com/Packages/com.unity.visualeffectgraph@7.1/manual/Systems.html

• Bolt 2: https://ludiq.io/blog/bolt-2

Reading some of the commits on the closed issue https://github.com/godotengine/godot-proposals/issues/1159 tring to have a more motherboard feeling mixing it with the vertical flow idea here is my approach for a mock-up thinking in this concept.

I think simplification is welcome and i will push the concept of playing with boxes of data, and make it colorful and have icons in order to find quickly the node desired. Regarding this I don´t know how to feel regarding the naming on each variable type inside the nodes (bool, float, vec3, etc). Most other visual scripting language assume that if there is a color code for variable types, then the color means the type.

I think also that Godot has a minor readability problem regarding variables color code by type, cause float, int, strings and bools, are too close on it's color and it's not clear the difference between them only looking at it's color can cause confusion. Here is another mock-up trying to simplify components.

Groups should be something useful, but also "signal connectors" in witch you can create a connection but not show the line conection in order to not have multiple lines crossing your graph. Ej. using delta value from _process. Line conexion "Signal" conextion. [This can be also used storing variables and reusing that data, but in a fancier way.]

The proposal don´t cover the color usage or shape style so other designs are welcome.

[charlesmlamb]

First of all, very cool, also at first design . .

1. Visual script in Godot, atm looks, also works really great almost for pro teams, tinkering it could wreck it, at the very least, I think it'd require experimentation . .
2. I have also been thinking, that being able to set the logic flow, to either vertical/horizontal might make graphs easier to read, however I'd only use it for the logic, since those are 'bigger' decisions, and, etc . . Perhaps a toggle, for the logic boxes, to either be horizontal, or vertical, I think could make current visual script 80 % into the suggestion . . .
3. For making scripts readable, making 'new functions', or 'new modules' (making a group of nodes into a single box), I think is more than enough, the problem is nobody, also beginners, don't use the 'new functions' enough, it's super - powerful . . .
4. These changes would take a ton of time, to update, it's basically rewiring all of the boxes, interface, going over the entire visual script, and right now, as someone else smartly said, it's more important to make visual script, some form of downloadable, or, that's semi - easy to install, also to work on serious bugs . . I don't think right now is the best time, to just massively overhaul the visual look, or the UI functionality, of the entire system, it'd prob. take a year, of work . .

That being said, I like everything I see here, however, Godot 4 visual script was finally getting useful, for pro work, it was a quite delicate process, took the coders years to get to this point, risking that for some new idea, I hope they keep what they have now, however, these are long-term customization ideas, and, I'd at least like to see how they work . . . Super - ideas, doing that much work on the visual side alone, I think it'd get in way of fixing serious bugs, do hope to see this, it at least looks nice, my very is the final user experience won't be as good, as the present one . . . . ? :-O

Note, the very colorful look, or saturated, I think prefer the more muted, or 'pro' look, of current visual script . . .

If I could suggest anything, maybe for customization perhaps, add ability to change contrast, of boxes, or saturation, so it looks more ' vibrant ', however, I don't know if this is a good idea . . . . :-(

[TackerTacker]

Who is this VS language for, is probably one of the first questions we would need to answer IMO

There are very different answers to problems depending on who it is aimed at.

Maybe we should also come up with requirements we want a new VS language to fulfill, basically like a wish list what an optimal solution would provide and then figure out how to get as close as possible to that wish list.

(edit) I was under the impression this is more of a proposal for a new VS language and not a change to the existing one since it is completely different. That might have been wrong?!

[nathanfranke]

See also https://github.com/godotengine/godot-visual-script/issues/27

[uwosi]

That's rather inconvenient to use in bigger projects in comparison to coding. Godot 4 also just got rid of the visual scripting system, so I can't see the reason to request a very similar feature going with the same approach that failed for the previous implementation.

By the way, GDevelop has a much more pleasant block-based visual scripting that's pretty close to the actual programming and it has already been proposed here on GitHub #27.

[charlesmlamb]

I think, these are good suggestions . . Perhaps starting a topic, about several visual script extensions now, since it's possible, and, then finding the best one's . .

However, I do think the current is best, in that it is useful to beginners, but, can also be used for pro work . . And, that what was in Godot 4 was perhaps the ' Godot ' visual script, and, also it fits gdscript, sort-of it's the same stuff . . That also makes it fast, easier to integrate, etc . .

However, I think working on perhaps several visual script languages now, is more possible . . There prob. just has to be different github, or, somehow topics for it . . Also, right now I think it's about making use of the years of work, already added to current system, and, that works as extension, of visual script in 3.5, where it is still being worked on, etc . .

Last, I think maybe the coders here have a super - challenges right now, to just get the system already there working, so we can have visual script back, in the fast way, ie. keeping the current system, for now . . . :-O

[3DLAB0]

There are different approaches to non-textbasedcode. And people will feel more comfortable with different styles. If vs goes to an extension, it's sure it will be multiple vs extensions with different arrangements.

This is issue is "Re-implement VisualScripting using 'block and wire'". Imposing one vs arrangement over the others as the official, if now vs is going to an extension, sounds weird to me.

I will suggest not having "Godot's Visual Scripting" as a name, I think we can structure the project better, naming better the project, so that Godot's Visual Scripting not imply that other arrangemnts are not valid and not seen as "official visual scripting". Creating a Godot's "Blocks and Wire Visual Scripting" , "Sheets Style Visual Scripting", "Scratch Visual Scripting", ... as different projects. Other issue could be making all these styles based on a common under base structure, to not duplicate work.

With this in mind I think the best approach is having an usable "Blocks and Wire Visual Scripting", that is the one that Godot was using.

Maybe in the future, another style is desired as the official one, so this will also cover the Blocks and Wire Visual Scripting style inside Godot.

Regarding Blocks and Wire Visual Scripting:

I would love customization similar as how much blender inferface is not that much hardcoded and there are multiple settings to change type colors, roundness of boxes, curving of lines, ..., and if there is the ability to change flow from horizontal to vertical as an option, would be amazing to me, as @charlesmlamb described. At the end this is a personal thought that is being shared in order to see how much people resonate with it.

Trying to be more practical some ideas I think are needed are:

• [] Use scripts as nodes, allow vs script to output and input data, and that way reuse logic and create more individual blocking logic. Similar to groups but with reuse as focus.
• [] Reroutes.

[charlesmlamb]

My thoughts exactly, I think even Juan said, he wanted to add 'scratch' some time ago, in some poll . . .

One advantages right now, since there isn't ' one ' visual script language, is one could start thinking about having several extensions, the big problem is someone has to code that stuff . . And, scattering effort over several languages, effectively means we get nothing, or, it'll take forever . . For now, I think it's better to just focus on the current one, not getting even scattered, however, I think having early debates, also thinking what could be done, getting advice from coders, then looking at what's possible, I hear good things about some of the other systems, however, I think for now, simply talking about it, and, not making any plans, is prob. a minimum . . Making these coding languages, I have an idea it might not be as easy, as at least asking for them . . . However, I think it's fun to debate, and, having several extensions, for even different coding systems, might be quite cool, a ton of people say this is quite good, esp. for beginners, I think it's called ' scratch ', not sure . . .

1. I think simply adding the years of work already done, as simply the best priority, doesn't make sense, people know the system, ton of people want it back, and, it's so good, it could be used by small teams, perhaps even (pro) studios . . Getting that back, or wasting time, not getting that back, also the coders that have made it, understand it, it makes sense to do that first . .
2. To not stress, over new systems, simply think about, have early ideas, pick a few one's, then keep them on list of, maybe, or, if there are enough volunteer coders, that then 100 % can code, design etc . .
3. I think we could make a list of potential, or one_day other coding systems, keeping it as early debate, and, keeping it fun, or early ideas, at best . .

These things are possible right now, in a sense, make some different extensions, however, I think the team that started this page prob. want to work on what was being finished, in Godot 4, a very pro, advanced visual script, and, having a more simple system, in Godot 3.4, and I think that's simply the best thing, that could happen . . . After that, or if other people want to develop a separate extension, that might make some sense . .

[tomwjerry]

I think everyone is talking about different things. We need to try to figure out what the future Visual Scripting system should look like, having a discussion about it (as we do right now). We need a good forum to do this, either GitHub discussions (git admin can enable this), Godot discussion forums (sadly not used much for such discussions), or something else. Right now I see four or five different issues just to discuss how Visual Scripting should carry on forward and sadly it tends to become messy pretty fast.

I found these discussions very interesting and would really like to collect them into one place so you can get a great overview over what alternatives there are.

[TackerTacker]

Yes, I would also be interested in discussing a future VS system and I think it shouldn't just be a discussion about which of the existing systems we should pick, because we will never find a consensus about that since everyone simply prefers 1 system and will be dissatisfied with anything but that system. No, I think it should be a discussion about the advantages and disadvantages of these different systems in an effort to create a tailor made system that specifically fits Godot. I could imagine that it would also be easier to find developers interested in working on a tailor made Godot VS language instead of copying an existing one.

These discussions should probably be disconnected from the efforts to maintain/extend/port the current system though, which I agree is a sensible thing to do since it already exists.

[fire]

I recommend making one thread for each singular self consistent visual language. https://github.com/godotengine/godot-visual-script/discussions/landing

Mixing incompatible ui element is confusing.

[lyuma]

@fire if you have admin, would it be possible to enable Discussions for this GitHub repository? https://github.com/godotengine/godot-visual-script/discussions gives 404

[charlesmlamb]

I think it'd be nice to think, or early brain-storm possible visual script systems, that we might one day want . . Also, for the coders to simply start thinking, a tiny bit, about one-day, maybe that'd be nice, beyond that, I think all focus should be on finishing the work, started in Godot 4, it only makes sense, it was getting to be an almost pro feature, and, trying to implement some new system will take much longer, it'll be both difficult, and, esp. blood-sweat, perhaps tears for the coders, it's semi - easy to ask for something, actually setting a few years aside, to make something, I think the coders should have almost final say, esp. if it's a difficult, or advanced system to implement, or code with flair . . In the end, should the coders walk away, or not want to work on something, it doesn't really matter, then we're never gonna get it . .

I wish this page had a reddit, where people could talk, etc, and if something was good enough, it could be posted here, perhaps a Facebook, I think this is better made to be work, or code only, have a very different place, to debate this stuff, and, a link in one of the topics here, reddit is super - good for that stuff, maybe there's a volunteer here, who could start the page, and, perhaps moderate it, leaving the coders time to work, on the basically point, of this code github, or so . . . .

We need to think about what works for the coders, if they leave, the entire purpose of this just doesn't work, etc, and, how to constructively, or sensibly ask for stuff, so it adds to the engine, but, also the work, that's either difficult, or challenging, for the actual coders, etc . . . I think, at best one should speculate about other systems, and, leave it to the coders, also, to review, get an idea of what it takes, bef. approving any suggestions, esp. massive changes, or, throwing years of work away, etc . .

I think, positive, the idea that people even want more visual script coding, is a good sign, visual script is popular, people want it back, also, that the community needs this feature, for some titles, otherwise there'd be few requests . . I do hope we get the one they made in Godot 4, to begin with, as someone who wants to make pro stuff, as much as I possibly can, the system was almost ideal, it also works for beginners . . All the other suggestions, I think I'd leave for a more cool, or well - made visual script in another engine, esp. having a full, or advanced coding system appeals to pro users, so, that's why I wish for, as at least one person, 10 / 10 feature in Godot 4, let's get that finished, and, start as minimum new github, for any other style, or type of visual coding . . . .

Last, if people want to use say scratch, instead of waiting a few years, bef. it is ready, it might even make more sense, to just use an engine that has that, for some time . . It'll take years, bef. anything is working in Godot, the engine runs on volunteers, and, now this is no longer part of core, not sure the coders here can even get money, etc . . . .

[fire]

@akien-mga Can you help out, I can see discussions but they don't seem to be public.

[qaptoR]

Wow, thank you to everyone who has contributed to this discussion. After reading everyone's perspective here I concur with some essential things which have been proposed

• Godot can have multiple visual languages now that they are moved to extension status

• Godot should have multiple visual languages because they support more types of coders which is in the spirit of Godot

• The VS languages should be developed foremost for Godot, and not to copy some other paradigm. Similarities and inspiration should be in service of what works for Godot.

• The general community should work on porting the current system first, then branch out onto a few ideas which have established benefits for one interest group or another, eg. a language meant for kids 8-10 who are learning to code.

I seem to recall Juan mentioning in his post about the removal of VS that it was due to how few users find VS easier than GDscript. I concur with that sentiment. I personally have found little reason to use VS over GDs.

This proposal was meant to highlight what I felt were limitations to the present paradigm, and offer suggestions for how to make VS easier for younger coders as well with an emphasis on design that makes transitioning to regular scripting easier.

Now, after this lengthy discussion, I feel that Visual Scripting, above and beyond being useful for artists and non-coder types, should be focused on providing features that are easier to comprehend visually, rather than with code. Such as Color nodes, timing-graphs nodes, gradient nodes, or texture nodes etc.

[charlesmlamb]

I agree, however as someone who wants to make pro, or hard-core stuff, the current VS is, sort-of really good for pro work . . Making it more ' simple ', like Godot 3, I sort-of think Godot 4 has -the- best VS, I've prob. ever seen . . If one wanted a simpler VS, I'd just tell people to use Godot 3 . . Anyway, for me, wanting to do perhaps pro - work, the current full-coding language system, quite advanced, only makes it better . . . I think they should finish Godot 4, then perhaps find other ways, of coding, I hear a ton of people saying, the scratch stuff is very good, I have not tried, however everyone says it's good system . . .

Having VS in Godot 3 means, there's no hurry to make Godot 4 VS, as such . . One can make the same stuff in Godot 3, I'm waiting for the work finish here, to get started on VS spec. for Godot 4, my point is, finish the current system, it's quite advanced, makes it more fun to use, and, maybe there are other good systems, or so . . . :-))) <3

[blurymind]

I will still say that the best one is my experience is the event sheets. If you look at the number of games shipped on steam using visual programming exclusively, it also wins over skratch and the spaghetti nodeness.

Construct2+3 and Clickteam fusion are quite impressively dominating

[tomwjerry]

The biggest issue with event sheets that I see is that the flow becomes linear, from up to down similar to real code. Then of course Event Sheet is good if that kind of flow should be visualized since using nodes would make it more difficult to read. Also, it is how most things are coded, if an event occurs then do this and that in that order. However, an event sheet would miss out on the flowchart-style design that nodes might give. A flowchart design would make it possible for a higher level of abstraction and overview but then not so many implementation details can be put, else it will look messy quite fast.

[dannymate]

I haven't used Godot before so I'm sorry if I don't understand something.

I wasn't really sure if I should create a new issue for this but I was reading through this thread and one use case for Visual Scripting that I haven't seen is to be used as a designer/editor tool. Programmers create larger building blocks for designers to connect together.

I'm the maintainer of a package on Unity (Currently in the process of forking): https://github.com/dannymate/NodeGraphProcessor

What I personally use the tool for is as an editor for a ScriptableObject. There's a button on the ScriptableObject that when pressed opens a graph. It creates a source node based on that ScriptableObject with generated ports. You can then plug nodes into those ports and when saved everything gets compiled into the ScriptableObject. In Godot's case a ScriptableObject would be a Resource.

I can go more in depth if this interests anybody but maybe this is a direction VisualScript could go or as something built on top of it to provide a use case. I could foresee maybe extending from GraphResource instead of resource and adding whatever an attribute is in GDScript for Inputs and Outputs on different variables.

Also if there's anything I can do to help with this as somebody who doesn't know C++ please let me know what I can do!

[AdrianoRegino]

Hi guys, I know there was a lot of discussion already, and I´d like just to leave some research material and maybe put my drop in the cup.

I´ve experience with a lot of VS tools like Cryengine Flowcharts, Unreal kismet and blueprints, most of unity ones and even some related to engineering and industrial automation.

The set of tools that mostly made sense, had performance and was well integrated by far from my point of view was Bolt 2, unfortunately acquired and discontinued by unity, they choose to stay with Bolt 1 because it was ready, but Bolt 1 tech was really old and lacking after all that time, now bolt1 is not receiving any more development and Unity is in a bad situation regarding VS. What's maybe fortunately for other engines.

Bolt 2 had an beautiful design and was VERY easy to read because of the chosen colors and contrasts, code generation offered a useful way of learning and teching writen code plus the best performance in comparison to reflection. For people that love visual scripting, it felt like a real and complete IDE.

Here we still have the design document: https://www.notion.so/Bolt-2-6a85ef4102694be889fb8413ab83aaa7

And here PanthenEye make a useful full-of-gifs, defense of Bolt 2, against a mega corporation incapable of doing what one guy was doing alone. https://forum.unity.com/threads/on-the-road-to-the-next-major-version-of-unity-visual-scripting-lessons-from-bolt-2.1285637/

Gif example "creating a sub group in seconds":

I believe its design deserve some review and consideration.

[AdrianoRegino]

Plus it was an unity extension, making it easier to develop and maintain "like Godot next iteration of VS", it loaded a defined set of namespaces and types, but the user could manually add any other. And for last there was a set of high level nodes, but if you look at the documentation, "which covered mostly those manually developed high end nodes and general functionality" they were just a few. Not too much in terms of development, the rest was auto regenerated on first installation or on demand.

[bigcatrik]

I will still say that the best one is my experience is the event sheets. If you look at the number of games shipped on steam using visual programming exclusively, it also wins over skratch and the spaghetti nodeness.

Construct2+3 and Clickteam fusion are quite impressively dominating

Verge3D uses Blockly and is quite compelling, but as a true non-programmer (never got beyond Basic, try as I may, and even simple GDScript makes my eyes glaze over) I was able to do quite a bit with Construct 3's event system with little trouble.

[eobet]

And here PanthenEye make a useful full-of-gifs, defense of Bolt 2, against a mega corporation incapable of doing what one guy was doing alone. https://forum.unity.com/threads/on-the-road-to-the-next-major-version-of-unity-visual-scripting-lessons-from-bolt-2.1285637/

I just want to note that every single improvement he demonstrates in Bolt 2 there already exists in Unreal Blueprints.

If Visual Script makes a comeback in Godot, I would hope the aim would be to surpass Blueprints.

[blurymind]

Please consider an event sheet approach instead of this. Nodes already tried and failed :(

They were in godot, not enough people used them. I still believe the biggest disadvantage of this is that it can lead to some very confusing presentation of simple logic

[tomwjerry]

Appeared that someone already made another vs scripting plugin? https://github.com/Vahera/godot-orchestrator