Godot: Visual script does not simplify the programming process

[brigazvi]

I can not learn to use Godot. I have a bit of programming experience, but probably not enough. I'm just not a code person. And I want to create games.
I know there is a visual script. But it is just the same code only in a messy way. There is no visualization of things. No icons. And much worse, programming is the same programming. There is no simplification.
Do not tell me I just have to go to other areas. In Gdevelop I was not bad at all. It just lacks so many features, and there are built-in bugs, that I keep trying Godot.
Visual programming is supposed to bring things closer to a human language. Make it understandable.
And I have pretty good proof of my claim, from this Gamesfromscratch video:
https://www.youtube.com/watch?v=-vo7jTQE7dc
In the passage he talks about Godot, he says there is no good reason to use Visual Script.

I'd really love it to change.
I like Godot.

[KoBeWi]

Talking about GDevelop, would be really nice to have this in Godot: #17795

I was creating games using similar software (The Games Factory) back in elementary school with absolutely 0 programming knowledge. There's probably nothing more simple than event sheets, when it comes to making games. And if they were in Godot, ability to mix them with standard scripting would create a very powerful tool.

[brigazvi]

Talking about GDevelop, would be really nice to have this in Godot: #17795

I know that. The solution he offers there is more interfaces and less conceptual. He simply arranges things differently. It is still very misunderstood and abstract. This is very far from the way things work in Constract and Gdevelop.
And I really do not care if the interface stays the same (drag and drop). I think that the main problem is conceptual.
Also in this video:
https://www.youtube.com/watch?v=9xGU0Cqv-J4
In the fifth minute he mentions Godot and says he does not put it on the list because it requires a background of programming.

[fire]

How do you suggest improving visual script conceptually?

[brigazvi]

1. Icons. Per function. And they should pass the message wisely.
2. Transferring the mindset to a more humane nature. A person who is not a designer is not really sure what the 'return' thing is. For example. The user simply has to tell the computer that if an X happens, it will work in Y and in human terms. If the player is in the friction with the bomb, the image of the bomb changes to the animation of an explosion, the object of the bomb is deleted, and the player's 'life' variable drops 20 points.
3. Maybe we can make any automations, by default, things that most people do not understand. That not everything will have to be said by the developer.
   Even if the move reduces the developer's options in relation to GDscript, as long as it presents an advantage in other areas it is worthy.
   The situation today is that all online tutorials for Visual Script are finished in comparison to GDScript, which shows how much more short and easy this code is.
   If the visual script will go toward easier to use, even if it will reduce some of the options that a programmer has with code, it will eventually expand the target audience of Godot. And I think this is the goal of a visual script. Give more tools that fit more people.

[nobuyukinyuu]

Perhaps some of this can be achieved by better "helper" blocks in visual scripting that wrap common node types and perform their operations on them in a more visual way. The way common functionality is exposed to visual scripting seems definitely more suited for a use case like "developer needs to make a sanitized interface for someone on the design team to use", but even then, it looks like it exposes a lot of stuff you may not want them to see.

Alternatively, visual scripting might benefit from existing nodes being "marked up" the way things are given attributes in the docs -- something that could behave like the aforementioned wrapper helpers, but with a bit less functionality (ie: they couldn't do custom UI visual nodes); adding icons, grouping by functionality instead of alphabetically, re-arranging/renaming functions on a member-by-member basis, and only exposing the most common functionality unless it needs to be "dug into" (something like giving each member a "priority level" for UI visibility that hid the functionality behind "accordion groups", for example).

It would take a lot of effort to find all the places visual scripting can be best helpful to non-programmers in terms of how to present all nodes' functionality. As it currently exists, it feels even more cumbersome to work with than gdscript for just about everything, even for testing simple functionality.

[fire]

One of the enhancements we're looking at is VS Custom Nodes savable as resources:

https://godotengine.org/article/gsoc-2019-progress-report-1-part-1#visual-scripting

Work of the Super Node or Visual Script-based custom nodes/modules feature for greater reusability and modularity of the Visual Scripting system.

The idea is the community and developers can create a library of custom nodes. @swarnimarun

The tools programmer in the team would create these nodes and less technical developers would use them.

[girng]

Aww, GDevelop has event sheets which is probably what works for the OP. In Godot's VS, you are editing a diagram, connecting / linking / unlinking nodes, etc. Probably a way different experience between the two?

Conventionally, artists created their art and handed it off to the programmer, then the programmer coded their game. Godot is a game engine, and in my opinion not really an art tool. So if something is not working the best way for a designer, is kind of beyond the scope of what the engine should offer. However, if Godot had a lot of art creation abilities, I could see this being a bigger issue.

I think listing improvements that could be made to Visual Scripting is good, but I would not expect event sheets or an overhaul, just my 2 cents

[brigazvi]

Aww, GDevelop has event sheets which is probably what works for the OP. In Godot's VS, you are editing a diagram, connecting / linking / unlinking nodes, etc. Probably a way different experience between the two?

Conventionally, artists created their art and handed it off to the programmer, then the programmer coded their game. Godot is a game engine, and in my opinion not really an art tool. So if something is not working the best _way_ for a _designer_, is kind of beyond the scope of what the engine should offer. However, if Godot had a lot of art creation abilities, I could see this being a bigger issue.

I think listing improvements that could be made to Visual Scripting is good, but I would not expect event sheets or an overhaul, just my 2 cents

You didn't get me right. I'm not trying to get Godot to switch to a similar interface to Gdevelop. I don't think that's the point. For example, GameMaker Studio 2 uses the same drag-and-drop system as Godot but is agreed by everyone as much more recommended for beginners. Maybe he is a better example of inspiration. I don't really know what's going on there. I've only tried Gdevelop. But there is something about Godot in these programs. They are more suitable for non-programmers.
And I can't understand any other purpose for the visual script than giving people who aren't programmers to create the games they want.
Nowadays people just don't use Visual script. No one finds any advantage there.

[therahedwig]

I wanted to chime in on this, I noticed when using the visualshader graph that for example, rotating a texture required manually multiplying the coordinates with a rotation matrix. That type of stuff is way out there for newbies, and kinda annoying for experienced shader writers too(multiplying matrices isn't hard, but is super fiddly).

Looking at the visual script, I, as an experienced programmer, noticed the following:

1. There's a ton of programmer lingo. Either this...
   a. gets rewritten to be more human friendly.
   b. gets tooltips with explanations. Like, if I have 'max', and look up the docs for it, I find a perfectly fine explanation. If that could get stuffed into a tool tip when hovering over the block or over its entry in the functions list, that might go a long way in reducing the opaqueness. This should also go for the categories like 'flow control'.
2. There's a lot of setup work required for fairly simple things. So for example conditional statements. In script these are three lines, in visual script they're split into the condition and the branches. Maybe here it would help if there was a wizard to help people find the node they're looking for. So like one that helps them find the input, or one that helps them formulate that they want to check if three values are all true at once and then outputs the appropriate branching statement. The way how you can are asked for the function of a given node when it is dnd'd into the window is a good example of this.
3. The fact that nodes need to be dnd'd into the visual script window to access them should be encouraged in the UI. Like, a small label somewhere.
4. Similarly, in 'matches' dialog, the unique functions to a given base type should probably be listed first. Right now this ordering starts with the non-unique functions, which is annoying to experienced users, and new users will not be able to see that the available functions are different per node, because the entries look the same at first glance. The node docker already does this, and it is really nice there.

The one thing the visual script editor does do really nice is that when you drag from the output it'll give you a window with a list of possible nodes and explanations, as well as the similar coloring of compatible types. It needs more of that.

Overal, I guess that part of the problem is that VS right now is exactly as dynamic as GDscript, and that means it feels like you're putting together a racing car while all you really needed was a soapbox on wheels, so you'd get overwhelmed by the minutia of how exactly the wheels should attach to the axle, trying to figure out what the simplest method is supposed to look like :D

[codecustard]

I think the main issue is having a larger range of built-in behavior. Something like GDevelop, which seems more tailored to people with less programming experience, has this.... but also something like Unreal Engine tailored for larger scale projects have built-in behavior. No matter how you do it, programming is still programming. It doesn't matter if you're using icons or words.

Visual Script is too vanilla. It's just icon drag and drop version of code. It can remain the way it is to maintain versatility, but to help beginners it needs a larger range of built-in behaviors.

Visual Script to me feels like Blueprints in Unreal Engine. It still feels like you're writing code, but instead of typing words you're dragging icons and connecting stuff.

So, yeah... I don't think it necessarily simplifies anything. What will simplify it is having basic functionality that is used in many games, like a platformer, or a bullet spawner, etc.. Higher level functionality already built-in without requiring you to combine a bunch of nodes together.

I'm not sure if this already exists, but if people can already create this type of functionality for people to download (similar to Game Maker where you could create your own drag and drop functionality) then VS is fine, it just needs time for people to implement this type of stuff.

[brigazvi]

• Visual Script to me feels like Blueprints in Unreal Engine. It still feels like you're writing code, but instead of typing words you're dragging icons and connecting stuff.

I'm not really familiar with the blueprints system, but from what I've seen on the Internet, it's much more recommended than visual script. For example, in the first video I attached above.

[codecustard]

I don't see why it would be more recommended over Visual Script, they're practically identical. The thing is, unreal doesnt have a scripting language. Blueprints is basically it. You could however compare its usefulness against Gdscript.

[brigazvi]

@sparkart
Maybe.
But even so. visual script can make things much more accessible. At Gdevelop I learned to work without any tutorials. At Godot I read and watched so many tutorials and still could not make progress.

[codecustard]

That's the beauty of out of the box functionality. What you're missing from Gdevelop that isnt in Godot is built in behavior. I think that is the key ingredient that you're missing. I don't think Visual Script is useless, but I agree your concerns are valid. I think the question to ask is how can we make this process simpler? For example, if you want to make a platformer game... why dont Godot just ship with a platformer template. You would still run into the issue of needing to interact with the scripting language to adjust things to suit your needs (an open source c++ game would be useless to a beginner trying to adjust it to their needs).

To address your concerns, Godot needs to solve the issue of not shipping with alot of built in behavior that its bloated, but to streamline the ability to add complex behavior without needing to do any programming at all. And when I say programming, I mean anything related to putting together logic, whether its visual nodes, drag and drop, code, event sheets, etc.. the easiest game engine shoukd allow you to create a game by basically providing your own data (assets and variable values). I think that should be the end focus of Godot, low level functionality but also high level that you can make something in 5 minutes.

[KoBeWi]

From my very old experience with The Games Factory (ancient software from Clickteam), it had for example two approaches for making a platformer:

• The easy way: using built-in platformer controller. It was horrible, character could get stuck on ceiling, jumping worked like 32-directional movement and if you wanted to e.g. shoot forward, you had to use some hacks to remedy the direction issues.

• The hard way: implementing the controller yourself, using a set of invisible marker objects and basically "programming" the behavior. Some games did this and it worked really well, but the 10-years-old me didn't understand how this works.

The point is, if you wanted to make any serious game, you had to do it the hard way. The default crappy behavior was only good for useless prototypes or gamedev children playgrounds. If Godot had built-in stuff like this, it would have to be really solid. But even then, 90% of people would create their own behavior anyways and the default one would be used only for prototyping.

It's pretty impossible to make a serious (or at least, unique) game without programming and going beyond what non-programming tools provide for you. And since we can't appease all people and their use cases, it would be the best if there was just a possibility to re-use VisualScript nodes. This way people could share their "platformer controllers" and what-not.

[brigazvi]

@KoBeWi
What is the difference between the behaviors that Godot will default to the behaviors that users share? If so, behaviors that come with the software can be much higher in quality control and prevent the bugs you mentioned above. I'd really like to be a master of programming to create crazy things. but I do not. And I love game design. So I want to believe that software like Constract 3 and Game maker studio 2 can create good games. And I want to have such an open source option.

[KoBeWi]

What is the difference between the behaviors that Godot will default to the behaviors that users share?

If Godot has 100 built-in behaviors, it will bloat™ the engine. I wouldn't underestimate community here. If it's not created officially by developers, it doesn't mean it's bad (and the other way around too; the bugs I mentioned were in commercial software).

Of course this could also fit for the plans with the "official plugin" repository, so we could have these behaviors being high quality, but keep them optional and easily accessible.

[brigazvi]

@redus what you think?

[brigazvi]

I mean, @reduz what you think?

[Skaruts]

@KoBeWi I messed around with The Games Factory back then too, and the 15-16 year old me couldn't make sense of the complex stuff either, but the event sheets were indeed great. Such that I still managed to make a half-assed pacman that actually kinda worked, among other things. :)

I wonder if that's not a kinda-of-forgotten relic of a system that could be being explored more often.

On the topic: I don't use VS. I didn't see the point in it either. I thought it was too much work to just do x=10, let alone the rest of it. But then I'm also inclined to coding, so I'm comparing between the two ways, which may not be a fair comparison.

[Ragnar293]

Hello,

I have the same problem as @brigazvi
My background is in computer graphics and I consider myself a very visual person. I have tried Godot’s visual scripting system many times, but like the previous posters already discussed, it does not actually simplify things as it is meant, but is basically coding 1:1 only you drag blocks around (more convoluted than actual code).
Otherwise I love the Godot way of doing things, the scene nesting and nodal workflow is just pure genius(better than Unreal or Unity). What I also consider a BIG benefit is the program size - compared to for example Unreal or Lumberyard that take insane amounts of disk space and resources. The one thing that is missing for me is the beginner friendly scripting system.

For a long time I have been searching for game engines that I can get into without much coding knowledge. For 2D engines so far I found Conctruct and Gdevelop for being the easiest to understand and get things going fast. For 3D stuff there is not much going around in terms of ease of use. A surprising engine is\was in Blender. The Blender game engine logic bricks are what I am looking for.

I have two suggestions for this problem.

First is to implement something similar to the logic bricks in the Blender game engine. I discovered this only recently. Reason being that paradoxically one of the hardest to use 3D packages that has/had one of the easiest to understand scripting systems. I have looked at a lot of 3D game engines but this is by far the easiest system to understand and really fast to get stuff going. The logic is very similar to Construct and Gdevelop event system. For example (Press W -> and -> add +1 to object coordinate X). With something simple like this you can get a 3D object moving in 3D space.

Explanation video from Gamesfromscratsch channel.
https://www.youtube.com/watch?v=cBhEgQVpv2M

The second suggestion is to make something similar to what a 3D program called Cinema 4D uses to make custom scripts for custom interactive stuff. It’s called Xpresso. First reason I bring it up is because I use Cinema 4D daily(a biased opinion) but the second reason is that Cinema 4D is considered one of the easiest to use 3D programs out there. At first glance Xpresso looks a little daunting and visually is very similar to what Godot already uses but if looked a little closer it’s core system is much simpler. A more understandable visual scripting system for beginners I would say.

Explanation video 1
https://www.youtube.com/watch?v=k-1xzR2XS9Q

Explanation video 2
https://www.youtube.com/watch?v=3vCnuIDGhyM

The truth is probably somewhere in between. But if something similar would be developed or the current Godot visual scripting would be developed similar to the previously mentioned systems then Godot would gain many die hard users. Especially people who are very visual or not so code friendly.

Ragnar

[fire]

Working on a Blocky or Construct like system is different than the current visual script.

https://developers.google.com/blockly

https://www.commonsense.org/education/website/construct-2

What I want to do is debug and make the current Visual Script based on flow graphs better and not create a completely different system.

https://en.wikipedia.org/wiki/Flow-based_programming

A GSOC 2020 project is to add expand and group nodes into grouped nodes with input and output port.

There's also a work proposal for Visual Script formatting. Like make a series of nodes pretty and well laid out.

There are also workflow issues with using visual script. It's very difficult to convert gdscript to visual script.

[Xrayez]

There are also workflow issues with using visual script. It's very difficult to convert gdscript to visual script.

Related feature request godotengine/godot-proposals#1240 (nevermind misleading title).

Also see reduz opinion on this on Twitter:

Unlike Unreal, this is more meant as a complement to programmers, so game designers, level designers, etc. can work more easily.

[andresilvasantos]

I would just like to add that the UI / UX of the Blender node system is superb. Very intuitive, clean and well thought. I've tried Blueprints, Bolt and obviously, Godot VS, which all felt lacking in different ways.

Quickly pointing out things that could be improved in Godot VS that work well in Blender:

• Zoom in / out with mouse wheel (I know this issue has already been addressed, but it's still a major miss for now);

• Minimize nodes (helps to save space for nodes we all know what they do);
  

• Show collapsed hierarchy in node search tree.
  

• Hide the var type label for the input / output of each node. Isn't the color enough? I think the labels just add to the mess.
  

• Cut & Copy / Paste of nodes is not working.

• When we move frames of nodes, the inner nodes should move as well.
• Easily create loops and groups inside a script and call them.
• Allow nodes and groups coloring for a good organization.
  

What do you think?

[fire]

• zoom in and out is still broken
• minimize nodes don't do as much as grouping nodes
• The two hiding / minimizing features make it more confusing I think. Also colour blindness
• I agree that comments should move the nodes inside
• Cut and paste yes!
• Google Summer of Code 2020 is on Grouping and Ungrouping nodes https://github.com/swarnimarun/godot/pull/7

Edited: Fresh out of development. please comment.

[andresilvasantos]

The two hiding / minimizing features make it more confusing I think. Also colour blindness

Oh yes, I forgot about color blindness. But IMO there could be an option to toggle the vars visibility. It's really a waste of space when you can read from the inputs / outputs colors.

I'll build Godot from source and explore the code to see if I can be helpful in any way.

[CodeFreezr]

I love the way how bolt/unity can scan new components and code to offer total generic new units. And also to have two kind of flow-diagrams: a flow graph and a state graph aka visual state machine. This helps a lot.

Blueprint/unreal is awesome in the way how to group nodes/units as a collapse-to-function, -to-macro, -to-node. And also the deeper penetration in the areas of HUD, menu, physical based materials (water / fog), rigging, level / scene states etc. pp. makes blueprint awesome.

So it is not the point to decide coding or piping. It should be a working together. Visual Scripting is a genius way of reuse code. With a good, colorfull grouping understanding of logic is much, much easier, also because you have a second dimension. Code is only from top to down. Visual Pipelines from top to down and(!) left to right.

Because I'm in love with Godot, I really, really would wish to learn from the other visual scripting Ideas and create the best of all.

Here my 5 most wishes:

• Grouping/Collapsing (like blueprint)
• Reflection-Based (like bolt)
• Tooltips, Tooltips, Tooltips
• Inline Tutorials (like unreal)
• Cross-Reference to read, learn, discover all (no one has)

[kreaninw]

I just start using Godot. IMHO, Visual Script really helps. In fact, it's my primary way of coding because I can understand the code in a visual way. I can understand GDScript and even some of C# when I watch the tutorials but unfortunately, I can't replicate that understanding in my project. With Visual Script, it's like I put together many jigsaws into a picture. I can guess the piece I needed for the final image in my mind. Therefore I think Visual Script really does help the programming process a lot (at least for me who's just starting).

My wishes list regarding Visual Script would be:

• Real-time debugging like Bolt. >>> It really helps for someone who doesn't have a solid understanding of coding. There was a lot of time when I totally lost it, for example, the time when I used condition if and switch, although they're very similar, their logic is very different because you can't turn on 2 switches at the same time.

• Infinity zoom out. >>> Most of the time, you will have very long horizontal nodes. It's inconvenient and time-consuming to pan all the way from the first to the last.

• Search for the comment or title. >>> Currently, it's very hard to search for nodes. The comment is not very well implemented as you can't find them using keywords. I think this feature is very important as most of the time not all nodes are presenting in the view. The ability to have a custom title of any node would be a great feature to implement in the future though.

• Focus on wires/connections of the selected node. >>> When you have a lot of wires connected, it will be very hard to track down the logics that are connecting to any node. I think this would help.

• More tutorials. >>> Currently, most Godot tutorials are in GDScript, even in the official Godot Docs. I have to find a way to translate it to Visual Script so I can fully understand it (which is very hard for me).

• Performance >>> This wish might be out of the world, comes out of someone who doesn't know how to code anything properly. From my understanding, the Visual Script nodes are basically logic nodes. Therefore is it possible to make the engine automatically convert the node logic to C++ underlying upon export to gain the performance benefit of C++/GDNative?

[Xrayez]

• Performance >>> This wish might be out of the world, comes out of someone who doesn't know how to code anything properly. From my understanding, the Visual Script nodes are basically logic nodes. Therefore is it possible to make the engine automatically convert the node logic to C++ underlying upon export to gain the performance benefit of C++/GDNative?

Could be in theory converted to GDScript with typed instructions somehow. In either case, not really trivial to do, see also https://github.com/godotengine/godot-proposals/issues/1240#issuecomment-662571669.

---

I just start using Godot. IMHO, Visual Script really helps. In fact, it's my primary way of coding because I can understand the code in a visual way. I can understand GDScript and even some of C# when I watch the tutorials but unfortunately, I can't replicate that understanding in my project. With Visual Script, it's like I put together many jigsaws into a picture. I can guess the piece I needed for the final image in my mind. Therefore I think Visual Script really does help the programming process a lot (at least for me who's just starting).

I'd like to share @reduz design vision behind Visual Script further, I've stumbled upon an article: https://godotengine.org/article/godot-getting-more-languages, see "Why Visual Scripting?" (to those who read godotengine/godot-proposals#575, it's exactly the thing I'm talking about the "why" part behind Godot's development, which is only written on the level of articles, and not official documentation...). Emphasis mine:

Another language currently being added to Godot is VisualScript, our take on visual programming. We are using an approach similar on the surface to Unreal's Blueprint, but pretty different under the hood.

As we have seen so far many Godot users and other developers puzzled about Godot adding this functionality, we want to make very clear that it is not our intention to replace GDScript or traditional programming for a visual approach.

To make it clearer, it is not our belief that forcing programmers to write code with visual blocks will result in a more efficient workflow. We know other game engines and solutions try to sell you this point of view, but rest assured that this is not our view or intention. We stand by programming and still believe it's the best.

As a contributor, I wouldn't really want to waste time to write up proposal to enhance the visual scripting the way I see it, not mentioning doing the actual work, because fighting against a particular ideology is almost futile (and likely unnecessary), in most cases.

I'm saying that perhaps the community sees this differently, but then there's unintentional "deceiving" going on. That article is 4 years old, though, so perhaps the vision has changed.

Perhaps if we really go the beginner-friendly route, maybe we just need another language designed exactly for that. But I think it won't be implemented in Godot, though. Quoting groud in https://github.com/godotengine/godot/issues/17795#issuecomment-376498871:

A good idea for a plugin. But officially maintaining two visual scripting systems would be a pain, and for little gain.

The good news is that it's totally possible to create a brand new language via C++ modules in Godot, similar (or even better) to Unreal Blueprints. 😃