Godot: Improvements to Visual Scripting

[swarnimarun]

Why is Blueprint So Good?

I spent some time understanding what makes Blueprint so much better than Visual Scripting and the answer was simple, it's coherent and well compartmentalized,
i.e. we have 5 different interfaces in Blueprint and each serve a clear purpose.

One for level events/components similar to signals in Godot called "Blueprint Level UI", this is where you can just select a Level Event(similar to a signal) and use the information passed through it to influence other actors/objects and there properties.
Watch This: https://youtu.be/9kzbsH8HgVY

Another for Actual Logic based programming called "Blueprint Class UI", this is where you do actual game logic or more complex things like procedural generation and such.
Also you can do anything you want in here it allows for most functions and events to be accessible here but as you already have a "Level Blueprint" so most tend to use it only for more complex stuff. It's like the current Visual Script.
Watch This: https://youtu.be/6RqDo3012YA

Suggestions for Improvements to Visual Scripts

So what changes can Visual Script make to get better,

1. Give VS specific Windows/Modes for specific tasks. Like in Level Mode disable complex functions and allow for more event/signal based actions, and make dragging and dropping nodes from scene tree pop-up signals/property list to access everything it has to offer and have basic built-in functions(sub-trees) to do things like getting the signals from the node. This will relative improve the ease of use of Visual Scripting. I believe separate Interface and Animation Modes will also do well.

2. Make VS look and feel better. Drop-downs should be all you might need as you see in Blueprint, this enables a much quicker work-flow and helps focus. Add better scalability and all the basic details that make a node graph awesome.

3. Add debugging support, like the Blueprint, show some basic effects like turning connections red(not just the node) if there is a error at that specific node + explanation on the screen/node and showing the flow of signals using basic animations to help understand connections and the flow of the system.
   This will help bring in younger(and more creative) audience that wants to learn programming while making games, which will in turn make Godot not only a engine for nerds.

4. Give VS it's own window that pops out of the editor, it feels really cramped in there and if you go to Distraction Free Mode then you can't drag-n-drop things.

5. Better docs and tutorials on the topic of Visual Scripting, I believe most people don't use it because it lacks quite a bit on the tutorial side. It took me more an hour figure everything out about it from Custom Nodes to Available Nodes, and I am usually pretty good with this sort of stuff, that tells a lot about the docs.

Hope fully there will be some useful things to take away from all this.

As a side note I will be making some tutorials on Visual Scripting on things like Custom Nodes and all. Probably will also improve the docs.

[insomniacUNDERSCORElemon]

IMO one of the best things about UE4's blueprints is the comprehensive search system. It searches not only node names, but also node DESCRIPTIONS (which Godot's VS nodes don't even have). I was able make a few alterations (including rapid fire, explosion animation+sound on physics hit or complete movement loss) to the FPS demo without having used it before and without a tutorial. Godot's VS implementation is far from that, for example things being data driven (rather than dedicated nodes) means that you cannot search for the node to detect keypresses.

For point 2 (look+feel), I'd add that the line rendering could be used to express data flow (even outside of flow animation). The main flow could be bigger with arrows (>>>) on it, inputs could be what they are now except with a slightly larger end for the origin. Smarter routed cable rendering (aside from the exaggerated S that is common with VS) could also help the feel.

For 3 (debugging) I'd add it's also important to have ability to show what values are assigned to variables. This could be a specific 'watch' action, or a mode that shows values as they are assigned/retrieved.

For 4 (window view), I'd like to point out that this would be incredibly useful for those with multiple monitors. You could test the game with one monitor and have the VS debugging on the other monitor.

---

I think the best way for organization would be a 'code collapse box' that could be used in different ways:

1. A commented area that can contain nodes, similar to what UE4's blueprints use. You could move or collapse this, and the node would be moved or hidden with it.

2. You could edit this node box in its own view. Isolated from anything else, so you don't have to worry about it.

3. You could turn it into a custom node, allowing you to control how it is displayed, names+comments+descriptions+variables+constants+dropdown options+what is needed/optional etc. This could be saved in the project/in a user library for re-use or exported/copied to the clipboard as data (JSON or XML) so it could be pasted to the net (and pasted back into Godot by other users) or uploaded to the Godot asset library.

4. Custom nodes would also be the basis of higher-level 'default nodes' (even not-very-high-level stuff like keypresses) even though it wouldn't actually be 'custom'. In reality it'd be the same as the current way being data-driven, and users could break it open to see how it works (although they'd have to make a new instance to edit it, so they wouldn't be able to break default nodes).

Note is that points 3 and 4 would also necessitate that the node format allows nesting and has instancing. Although Godot's internal format would store them differently, so that could be an alternate sharing method if for some reason the other options didn't work (file length?).

[swarnimarun]

Yeh all those things will be nice addition and I love the code-collapse option.
And the data-driven part is also true I would love to see visual scripting being made a lot more descriptive and simpler to understand even without tutorials or previous knowledge of the engine's API.

A definitive example of this is searching Math in the Available Nodes Box, you get Math Constant not operators which was what most people would look for.

I discovered that differentiation of modes also has another advantage, it allows for scripts that are generated by Blueprint, to be of varied types. Although I believe it can wait longer.

The first priority should be give better searchable and usable nodes and improve the interface.

[Linko-3D]

I agree with what have been said above and especially a big improvement on the search tool is needed, for example in the available nodes search bar we should be able to type the classes of GDScript, like "mouse motion" and it should display me a node corresponding to the "InputEventMouseMotion" or the node that contain this setting and should set it up automatically when it's dragged. I was unable to find it to make a VS FPS controller so I gave up.

Also the nodes should be paralleled, instead of using the done output of a condition. The nodes should be automatically read at the same time from parent to children. Also the parent node should automatically use the optimal process, if it's a physic node it uses a physic process, if it's an input it uses an input process, if it's a variable incrementation it uses a delta time process without connecting a process function node to it.
The paralleled nodes should look like this: https://cdn2.unrealengine.com/blog/blueprints-974x797-1486521661.png As you can see each node group starts with an input and they are separated from each other and commented, everything is comprehensive for a non-programmer. The Input has also a built-in boolean condition to see if it's true without having to use a condition node. If 100 % of those nodes need to check if the condition is false or true then the boolean should be implemented directly in the node.

[swarnimarun]

@Linko-3D The thing is Godot doesn't has a node like that you will have to create custom node to something like that I made a video tutorial on it Custom Node Godot.
The thing is Blueprints already has all the functions for the purpose but Godot doesn't, I believe Godot should add more creative and input nodes for ease of use but currently it's what it is.
And also the ability to create methods as groups from the nodes on-screen.

[PJB3005]

Yeah, Visual Script is awfully lacking compared to UE4 BP, which absolutely nailed it. Of course it definitely can be improved, but it's gonna be a lot of work.

The two big features VS needs to get even close to BP are this:

• Nodes being more opaque. I don't want to see a "CallInstance node which calls foo on a node of type bar". I want to see "Call foo on bar", like that, in the editor and the search. Sure we can keep using these "low level" nodes internally and maybe expose them in the property editor, but keep it down please. This is how BP does it.
• The Search. Seriously the search. With BP you right click and it will give you every node combination that's even remotely interesting for this context. In most cases this is done via releasing a wire you're dragging, in which case it only shows nodes relevant to said wire type. You're dragging an Actor-type wire? Yeah you release left mouse button, type in any of the names in the AActor documentation and you'll immediately get exactly what you wanted. It's insanely fast to work with (and I'd wager it'd be so much faster than even GDScript, though that's partially because GDScript's editor features are just awful by modern standards).

Then there's just so much minor QoL things you definitely want. For example, in BP, if you have a multiply node (which, by the way, is fully typed so you have separate nodes for float * float, float * int, int * int...), you can just leave one of the inputs open and you get an input box in said input to enter a constant immediately. In general coding itself should very rarely touch the properties window, unlike the current system.

A nice similarity between BP and VS is that in UE, each AActor has its own mini scene tree, so we could take the idea of having immediate access to child nodes in the scene tree available in the search too.

Ironically, I would write more here, but my memory is foggy as the computer I'm writing this on is too slow to actually use UE's resource hog of an editor.

[reduz]

As I mentioned many times. I wrote Visual Scripting as a base for others to work with and add to it.
It's meant to be a barebones implementation so it can be improved upon.

Most other areas of Godot have an actual maintainer or person responsible of getting feedback and working on it. Unfortunately, this is not the case with Visual Scripting. Unless someone with more experience with this, or willing to listen to feedback and implement stuff appears, Visual Script will not see many improvements.

[swarnimarun]

@reduz that really is sad, but the thing is most people willing to contribute to Godot need to be good at programming and if you are good at that then working on a visual scripting seems like a waste. Though this is not a universal case. But common enough that it seems VS is suffering from it.

None the less if no one takes up the task in the next few months then I might look into after I have gotten better at C++.

[samvila]

To me, the best use of any visual scripting type of programming in a 3D engine is the one from Armory3D, SOoo much easy to understand and to use, even for new users. Simple and powerful at the same time.

I find the visual scripting from Godot and Unreal way to complex for simple things, is almost like writing code pretty much, while in Armory3D you have a set of nodes that simplifies A LOT the programming.

[reduz]

@swarnimarun, @samvila The problem is that far most users prefer actual programming, so even though I hoped it would, not much of a community has formed around VisualScript as it did around GDScript or Mono. In fact, last time we did a poll, amost 10% of Godot users actually learned programming to use it, which is pretty surprising... but at the same time its very easy in GDScript..

Godot VS allows making custom nodes in GDScript so higher level behaviors can be made, but so far there seems to be zero interest from the community on contributing to it too.

[samvila]

I agree @reduz , there's no much point on using VisualScripting in Godot if you already have Gdscript except for a more friendly introduction to artists. This is how I got introduced to Godot and code programming in general, I was horrible writing code so I was looking for a tool that allowed me to program without having to actually use code and I found Godot's visual scripting which was a very good introduction at that time but as I said it's far from the quality provided by Armory3D in my opinion, just check these screenshots:

http://forums.armory3d.org/uploads/default/optimized/1X/f003983e5b2eee45e40e5244d3d17a591ede589a_1_690x388.jpg

http://forums.armory3d.org/uploads/default/original/1X/5a74abcbe3c9a0b08499a5f13802e78a2e453dbb.jpg

http://forums.armory3d.org/uploads/default/optimized/1X/c2c4f93fa09f67098ba3ccdb3bf8a007d87247ac_1_690x371.gif

Armory3d doesn't copy the same functions at the code programming side but a much more simplified way to handle things, this is amazing for an artists with very little knowledge on programming and a much better introduction to basic programming in general.

[reduz]

@samvila yeah, this is why I meant that it should be possible to write these higher level behaviors for VS, which are more similiar to how tools like Construct and GM work. VS is designed so it can be easily extgended.

Higher level behaviors need a higher level context, which Godot does not provide (because most programmers just prefer writing their own). This context would need to be created, then nodes added to it. The problem is that no one really bothered in working on anything like this, for the reasons I mentioned before.

[PJB3005]

@samvila from my memory of blueprints, while it is very advanced, it's not so different from the Armory3D examples you linked here.

[mrcdk]

While I agree that the visual scripting in Godot needs a lot of love, the examples shown in this thread aren't specially difficult to do with the current VisualScript state.

For example:


and same thing for the close animation.

Granted they need better naming, a better search and probably merge some of the most used nodes like the action+condition one but most of the functionality is already there.

[samvila]

I totally agree @mrcdk , the functionality is all there, is just not really accessible for artists with little knowledge on programming, as you said a better naming and cleaning would be very beneficial. I find the names of the nodes in Godot not very good, also the way to access some of these functions are very obscure some times.

[swarnimarun]

@mrcdk The thing is not the UI and the UX of the Visual Scripting sucks, I can't search for most things properly unless I specify their name, nodes don't have description and it also lacks other important UI features.
@samvila I believe just some minor changes should bring Visual Scripting up to speed as it's powerful already but only lacks the interest.
As for creating more nodes it's easy to do using Custom Nodes. It's just that nobody has picked up the work, to create some basic nodes for the community.

[Linko-3D]

For those who have posted Visual Scripting node setups and have more knowledge than the average, if you have some free time could you write the documentation about Visual Scripting and create some node examples like an FPS Controller (with the lowest amount of nodes) and how to find any classes? Thank you.

I think if the current Visual Scripting gets documented (with an annotation at the top that say that it needs a maintainer to be improved) it will become more popular and visible, even on YouTube more will cover it and we will find more easily a developer willing to improve it after seeing how hard it is to use, especially a developer that knows how Unreal Blueprints work.

[swarnimarun]

@Linko-3D Well I believe the docs do need to be updated, but the problem is it's just too much work.

I created a tutorial series on visual scripting. Will be adding more videos soon.

And also a repo of custom nodes for people like myself to contribute to, which I am planning to put up on the asset page as well once I have enough time and have enough nodes there to effectively help the community grow. Lots of hard work.
https://github.com/swarnimarun/visual-scripting-node-library

And also forked the godot-docs and started working on the custom nodes tutorial but the problem is time and the lack of contributors to the visual scripting in Godot as a whole. And most because of the experienced people backing down from the little work and a little bug hunting.

The experienced programmers would only need to sacrifice a week's work at most for the minor improvements like adding support for description and better search which would improve the system greatly, I could possibly even work on the upgrading visual scripting module but I don't know the Godot engine very well, I lack time(have to study), and my C++ skills are not good enough to make it work so quick.

[samvila]

Hi,

Here are a few mockups I created on how would be improved the visual scripting in Godot in my opinion:

Basically the point here is to bring functions to the users in a much friendly and understandable way, I always found the naming on Armory3D very good, especially for artists of people who starts with programming, for example: InstanceSet doesn't ring any bell for a basic user, but a node call 'Scale object' is much more efficient and clean in my opinion.

Aside of the naming and the categories I'm also showing some other areas of visual scripting in Godot that would benefit from cleaning up a few things such as sorting elements by alphabetical order or move the titles of the nodes outside the lines to be more readable.

About the categories of the nodes, to be honest I would just replicate the ones from Armory3D pretty much.

[PJB3005]

Yeah, that's the general consent. #18867 is doing that already.

For built in function this already exists so you don't need the property editor.

Also that second image seems like a rendering bug? It definitely shouldn't look like that.

[swarnimarun]

Yeah true many of those changes are needed but the one for Input is not actually a need in Godot for all actions are usually able to use multiple of them at once.
It might be possible to add Input.get_key, .get_mouse and get_joypad but that's not going to use Actions which I believe to be a better solution overall.

And having a whole tab like that is a really good idea. I am putting that on my todo list.

But I am not getting what you are trying to say with the sprite node.

Finally adding windows to the input variable should not be much of a problem either. Fire might just add it too. If not then I will look into it, once he's done.

[Linko-3D]

In Armory3D every names that starts by "On" are automatically checked every frame like On Keyboard, On Mouse, On Volume Trigger. This saves the function node and the condition:

Also Armory3D (and BGE) uses the ability of Blender to create an animation of almost every settings, so very few nodes need to exist, everything is done with the "Play Action" node. With it you can turn On and Off a light (with interpolation and make it blink with a noise modifier), open and close a door, change a material color,

[swarnimarun]

I would like to suggest the idea of a singular canvas with multiple functions. Like animation-nodes has multiple loops if we are taking blender reference. And also be able to create multiple canvas for a single script like partial scripts.

@Linko-3D
And as far as "On"/every frame executing nodes are concerned it won't be a major problem implementing although I would suggest to have options of using a different setup instead to go against it for if implemented then it will likely break all ties with the current Blueprints thinking. As I believe Blueprints is the more popular approach and also more optimised.

So let's just say that combining multiple approaches might be the best way for progressing for Godot's VS system. This will probably also simplify the confusing system that is currently there in Godot.
As Unreal and Blender tutorials would both start working with Godot, means more resources to learn.

Sample image/mockup:

[Elmapul]

i think construct model is better than vs, i didnt tested Blue Prints yet , but VS use too much horizontal and vertical space, you lose too much time conection nodes that will only go to one direction, and you have to manage horizontal/vertical space.

contruct and clickteam fusion on the other hand, have an faster workflow.

i'm trying to implement something like their system, but i'm strugling with an bug.

[zaniar]

@Elmapul
We sould not go into "what is better than Visual Scripting" discussion here. This issue is about how we can improve Visual Scripting.
There is an issue that discussing about Event List (the one used by Construct). You should go there instead.

[eon-s]

Something that can also be done to quickly improve usability: make VS node elements behave like inspector properties.

With this I mean to be able to edit curves, see textures, have sliders, dropdown for enums, etc. to click more and type less in the VS nodes.

[HeadClot]

Hey Just thought I would chime in on this.

The ability to comment blocks of visual script would be awesome. It would greatly contribute to organization of our visual script.

[eon-s]

@HeadClot that already exists, is the Comment node.

[fire]

@swarnimarun Can you review the newest master? Currently 451e5fd0511bc2c17a66fc73a0de9a5169109517

[swarnimarun]

@fire yep on that. Being tearing apart stuff in Godot since the last week, so it seems better but I have yet to use Visual Scripting properly.
I think we need some features for the Visual Scripting to be easier and also a lot of extra nodes to help make the whole thing simpler. Cause the UI is finally almost at the point where I feel it's usable.

[Jummit]

Stuff I want in VS:

• Better searching behavior (just show us all the things!)
• Reroute graph connections
• Enhance member variable editor
• Constructors for non-basic classes
• Better custom nodes
• Drag and drop consistency
• Text based saving for version controll
• Zooming with the mouse wheel goddammit!
• Make long dropdowns searchable (this applies to other engine features as well)
• Shortcuts for making code into functions
• Double click function nodes to edit them
• Pull out from an input port to create a variable of the correct type

[fire]

• Constructors for non-basic classes

This is important because you can't code things without this.

In the google summer of code there's a proposal for work on:

1. Allow visual script zooming
2. unify the visual script graph
3. add merging and unmerging functions

[Jummit]

More stuff!

Inheritance issues:

• parent methods don't get displayed
• no methods get displayed
• no members

• base type gets long

  Node io:

• change input type of switch

• change output of function call
• return of functions are always "any"
• make functions not have output if no return exists

• a Get Local Variable node should find other Set Local Variable nodes with the same variable name and set it's type to that

  UI:

• nodes should be selected when added

• search doesn't work with spaces
• grid snapping options should be the same in any script
• grid snapping should be 10 by default
• functions should stay open when changing scripts
• editing variable is always black

• ability to hide windows in the script editor

  Other:

• conditions should be configurable

• make custom nodes resource based, or convert resource to custom node

[Calinou]

If you plan to open proposals for this, please remember to open one proposal per feature.

---

Feature and improvement proposals for the Godot Engine are now being discussed and reviewed in a dedicated Godot Improvement Proposals (GIP) (godotengine/godot-proposals) issue tracker. The GIP tracker has a detailed issue template designed so that proposals include all the relevant information to start a productive discussion and help the community assess the validity of the proposal for the engine.

The main (godotengine/godot) tracker is now solely dedicated to bug reports and Pull Requests, enabling contributors to have a better focus on bug fixing work. Therefore, we are now closing all older feature proposals on the main issue tracker.

If you are interested in this feature proposal, please open a new proposal on the GIP tracker following the given issue template (after checking that it doesn't exist already). Be sure to reference this closed issue if it includes any relevant discussion (which you are also encouraged to summarize in the new proposal). Thanks in advance!