New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Visual script does not simplify the programming process #38
Comments
Talking about GDevelop, would be really nice to have this in Godot: #27 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. |
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. |
How do you suggest improving visual script conceptually? |
|
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. |
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
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. |
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. |
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:
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 |
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. |
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. |
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. |
@sparkart |
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. |
From my very old experience with The Games Factory (ancient software from Clickteam), it had for example two approaches for making a platformer:
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. |
@KoBeWi |
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. |
@redus what you think? |
I mean, @reduz what you think? |
@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 |
Hello, I have the same problem as @brigazvi 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. 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 Explanation video 2 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 |
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. |
Edited: Fresh out of development. please comment. |
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. |
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:
|
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:
|
I'm not a Godot user, but I want to be. I ended up here after searching online for information about Visual Scripting, and I too think it's too close to actual scripting and it has unfortunately scared me away, as I'm not a programmer. Due to work, I had to learn the Unreal Engine, and they seem to automate some of the programming aspects better. They have some interesting flow control nodes that have built-in behavior ("do once", "do n", "flip flop", "gate" that can be locked an unlocked, etc) and some nice visual things like enums become nice little drop down lists to select from making nodes close to natural language readable. But the biggest feature of them all (for me) is the timeline node. In one extremely powerful node, you can do simple animation and fire off events without having to think about frames or locking something up or anything, and it's all truly visual. It's so incredibly powerful and I use it all the time and I wouldn't want a world without it anymore. Then recently, there's a whole world of specialty nodes for skeletal animation to interact with IK and physics that they added, but that's way above my head for now. I've heard it enables technical artists to do things that they had to ask programmers for in the past. So, I'll check back in a few years and see if there has been any progress. I'm hoping by then that visual scripting in Godot will look less like scripting, more visual, less tedious and more automated. 🙂 |
Godot's equivalent of the timeline node is the Animation and AnimationPlayer, and those are amazingly powerful too. |
I think maybe it should be more similar to Unreal's node system. |
I hope people are still working on this but at the status of this post, I don't think anybody is. The visual scripting part of godot has no benefits and it's very messy and difficult to get into. I've tried using it multiple times but it's because I tried that I put a lot more effort into learning GDScript instead just to escape the mess which is visual scripting in Godot. There are many great examples of other engines and programming languages with visual scripting being a decent tool and sometimes even more convenient than scripting things yourself. if my programming skills would have been better I would have tried to give this a try myself, so I hope somebody will finally give visual scripting in Godot some love. |
One of the GSoC 2022 ideas is about improving visual scripting: godotengine/godot-proposals#4064 |
Tangent (but I'm not sure it's worth opening a separate proposal for) - usability of visual shaders and visual scripting both suffers from the fact you can't open them "full-screen" (or at least like the script editor does, using all the space that's not taken up by tree and inspector) |
i cannot agree with the comments here, the visual shaders are excellent, people have not "got them" or they expect them to make programming easier, which i'm not sure a visual system will ever truely do anyway the problem for me is only a lack of docs... there's not even a reference doc for example on what the individual nodes do i recently have built a visual shader copying a spatial, but i have added vertex code because i wanted ocean waves..... this is far better organised that converting a spatial to script and then adding my jury rigged code to it the process is badly organised of course... however with a visual shader i can solve this organisational problem.... so i thought i'd just share there's a genuine argument of something i can't do with written shaders.... organise things in a modular fashion without copying and pasting the same code blocks everywhere |
^ This issue is more about VisualScript, not VisualShader. Visual shaders are great and people generally don't have problem with them. |
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.
The text was updated successfully, but these errors were encountered: