• General Chat

  • Visual scripting being removed / beta very close

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.

      Yeah, I'm not saying visual scripting as a concept can't work. Just that the implementation, as is, was basically useless. Even Blueprints is not perfect, and even simple things that would be 4 or 5 lines of GDScript would be a full 4K screen worth of spaghetti.

      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. 🙂

        duane That's kind of a circular argument when it comes to visual scripting. Most people are asking for it because they find type written script to be too daunting, and you would probably need to go to c++ to really integrate it.

            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.

              fire7side

              You could say that about gdscript as well. We touched on that issue in another discussion. 🙂

                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.

                    Tomcat If, for example, you decide to bake a bun

                    No, I would buy a bun or pay someone to sell me dough. 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. Given that 0.5% of godot users are using visualscript, I doubt that they're footing the bill for more work on it, but if someone with big bucks and a visual orientation comes along, they could change a lot of minds -- I'm not holding my breath. 🙂

                    On the other hand, if people strongly interested in visualscript, band together, they might get more accomplished on their own.

                        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. 🤑

                            So what does cooking and programming have in common ?

                            Certainly the breaking down into tasks ("If you want an apple pie from scratch you must first create the universe !"), if it is a multi course meal then also setting of milestones ("What's smelling ? Gosh, I forgot the roast !"), testing ("Get your fingers out of the dessert !"), customer delivery (everyone's holding their breath), eventually bug search (yeuch). Possibly dealing with some internal friction ("But I want spaghetti !"). And, in rare cases, utter failure ("The salmon mousse !").

                            So, yeah, some analogy can't be totally rejected :-)

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

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

                                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".

                                  cybereality Visual scripting is not easier than coding, it's actually harder.

                                  It's not easier to coding — yep, but it's easier to change. @DaveTheCoder said exactly the right thing.

                                    cybereality Yeah, my experience with it is that it's harder, but that might be because I learned text script first. It always ends up looking like text script because you have drop down boxes with text choices. The trouble with it is it's so unsightly when it's done. It's so much easier to read text code. The visual scripting for the unreal engine seemed unsightly at first, but after I played with it for a while, I started to at least not hate it. I think I like it better than c++, but I wouldn't say I like it better than gdscript.

                                      Yeah, Blueprints is alright. Most people don't know how to use it, especially beginners have one large screen with like a million nodes and connections. But you can use events and functions and macros to make things clean. If visual scripting in Godot worked like Blueprints, that would be a different discussion. The problem is that it didn't work.

                                      10 days later

                                      I'm not sad that visual scripting is being removed, but I am sad that it was implemented in such a way that it basically was completely useless to newcomers to game development, thus rendering its entire existence moot in the first place.

                                      If the Godot developers could have made it more like Unreal's Blueprint system, I've no doubt it would have taken off and helped bring in a lot of new users. I'm hoping someone can develop a plugin that makes the system much more approachable and friendly like Blueprints. In my time with UE4 some time ago, I used Blueprints and C++ together and it made life a lot easier for several tasks, however the same couldn't really be said for visual scripting in Godot because as others have said, it was basically just GDScript in a visual form and thus pointless to use. Blueprint is NOT C++ in a visual form, and could actually be immensely useful and easier to use in several cases over C++. That's what I (and many others, it seems) was hoping visual scripting in Godot would be like, and not at all what was delivered.

                                      Yeah, I think it was good that it was removed. However, the reason for the removal was a mistake. I'm not sure if making the right choice for the wrong reasons is any better than making an incorrect choice.

                                      If you have no developers for even just maintaining it then removing it is the right call.

                                      Same way blender game engine got removed. Irony is that once it was threatened to be removed only then did some developers start to appear and now it's staying around as the UPBGE project. One can hope that VisualScript as an Extension might get some new wind under it's wings then too.

                                      Well, yes. That's why I say it was the right decision. But if you watch the video (or have seen Juan's tweets) the explanation for why people didn't use it totally missed the mark.

                                      But that was the main reason they removed it, nobody willing to maintain it/take charge of it. Everything else is just further excuses for it.