I have yet to see a "Visual" programming environment that is even close to as efficient as normal programming. I may well be in a minority on this one, but surely time spent on this would better be spent in other areas like improving C# interoperability etc?
I know the intention does not appear to be to replace actual programming, but I think their use-case is weak and put in because it was someone's pet project. Not trying to be ultra-critical, but just think this is wasted resources, which could be better spent elsewhere.
Interested to see what people think about this.
EDIT: Should have phrased this better. So to be clear, I am asking what people think about the relative merits of Visual Scripting and not what part of the project has a higher priority.
Visual languages have been very successful in other tools (material/shader languages in 3D tools, Blueprints in Unreal Engine has been very successfully used by game designers). I assume that Godot was influenced by this.
Have you ever used a visual language in ernest? I've used Max/MSP and Max4live, which are successfully used by many non-programmer musicians and artist. I don't think many of these people would be successful with (or even bother to use) a textual programming language and I think many designers who love Unreal Engine's Blueprints would similarly not fare so well with textual languages. My experience using Max was that it was a breath of fresh air, in many ways superior to my day-to-day experiences with "real" programming languages (eg for exploratory problem solving, it was amazing, and for games where you likely need to make many little tweaks until it feels right, I can see this being a major advantage). Sadly, Max is rather limited in terms of data structures (can't even have nested lists!), but that's a shortcoming in Max and not in visual programming tools.
So, in summary, I disagree: I don't think its wasted resources at all and think its a great idea, especially to get more non-programmer users[1] and welcome more stuff like this.
[1] From what I've been reading, lots of non-programmer designer/artists are making games with Game Maker and Blueprints and such tools. The more you can do without "real" programming, the better, IMHO.
> Not trying to be ultra-critical, but just think this is wasted resources, which could be better spent elsewhere.
This is an open-source project. Priorities are defined by what the developers need for their own projects, and if there's any time left by what they want to spend their spare time on.
I for one am glad that someone decided to contribute a C interface that is friendly to most languages with C/FFI capabilities to allow people to more easily integrate whatever language they want, rather than providing tighter integration with a single language that is a second class citizen on all the platforms I care about.
If you think C# integration is more important, go ahead and contribute to it.
They have just recently managed to get enough money through Patreon to pay for their main developer to work full-time on the engine, and they are planning to let patrons vote on which features get worked on for the next release. So if you don't have the time or drive to contribute good C# integration, you could donate and vote for C# integration to be picked up by the core developer(s).
This really was not the main thrust of my question. It is completely obvious that the developers, or anyone else contributing can work on any aspect they choose. I am far more interested in a discussion about the merits of a Visual Scripting approach.
I should probably have worded my comment better and have added a small addendum.
> I for one am glad that someone decided to contribute a C interface that is friendly to most languages with C/FFI capabilities to allow people to more easily integrate whatever language they want, rather than providing tighter integration with a single language that is a second class citizen on all the platforms I care about.
Do you have a link to the C/FFI interface you mentioned?
There are visual languages that basically do "functions as boxes", lines as calls". These are useless.
There are visual languages that look the same as above, but lines are actually dataflow instead of function calls / control flow and the boxes are not opaque functions but introspectable data flow descriptions themselves. These offer some unique benefits, like transitive optimization and code elimination, that operate at a higher level than even full program optimization can achieve. (The latter being Simulink, for example.)
Then there are state charts (which are the big cousin of cumbersome non-hierarchical state diagrams as most people know them). These are, to me, practically a silver bullet regarding real-time systems. I went into automotive software development being very skeptical of Stateflow (coming from a classic C and Java background), but it has transformed the way I work with real time systems (even if not using it). It requires a huge upfront investment in analysis and thinking things through very thoroughly, which is why it is not particularly suited for systems with very volatile requirements, but it leaves you basically at state "done" after the design phase.
That's an interesting observation, in that games are often real-time systems. Makes sense to me as I work in audio DSP where you've got to have your buffer processed in time or you wreck the hapless user's mix.
Where do you see Godot relative to this? I know I was interested in Unreal Engine's blueprints, but unconvinced (also, I was working with my coder brother, who hated blueprints on sight). I've also been exploring the open synth hardware Axoloti, which likewise uses a node-based system for its design.
Regarding visual editing, those tools are of direct interest to any signal processing work(which for games means audio, visual effects, and in some cases asset dependency resolution). They don't work well once your task is too fine-grained. Graphs of finite state are also extremely useful for game AI and concurrently scripted logic, so tools that formalize those concepts and give them visual UI are also commonplace.
In audio work, a FSM is a good starting place to conceptualize processes like key state tracking and envelope triggers. Games have more shifting requirements so the design process of the FSM is given much more emphasis.
Welp, now I'll HAVE to choose MIT when my own opensourcing gets underway. They say they didn't have much audio DSP code under MIT license they could use. I was leaning to MIT anyhow, but if they need specifically that…
> There are visual languages that look the same as above, but lines are actually dataflow instead of function calls / control flow and the boxes are not opaque functions but introspectable data flow descriptions themselves. These offer some unique benefits...
I've only had a brief (few months) experience with Max/MSP, although I've played around with other visual languages too (SynthMaker and others) and have been interested in the topic of both visual and dataflow languages for a long time. So, with that bit of context, I completely agree with your observation!
Since you are still in beta, I figure you could use some feedback, so here are a couple of things I noticed that were unexpected. (I'm using Firefox 55 on Linux so some problems may be related to that.)
* After loading the editor, I got a dialog that says "A new version of Construct 3 is available! You are using r58, and r58 is ready to use." which is quite confusing. Also, the text in the dialog can't be selected, so I had to use the dev tools to copy the text. At least clicking "Update" didn't send me into an infinite loop.
* When opening one of the featured projects (I tried Glokar), there is no way to cancel the download. (I was getting very low download speeds, maybe because I'm in China. The GFW throttles a lot of random traffic.)
* In a box that says "Add action... Add..." I would expect the whole box to be clickable, not just the text.
* When clicking on an action like "Go to Mission Objective" I would expect a link that lets you look at "Mission Objective". Yes, it's in the project panel, but maybe I didn't see it and I don't know where it is because I'm looking at someone else's project. Same for all other kinds of cross-referenced objects.
* I found the Beginner's Guide much too late, because it was below the fold for me and the list of demos captured my scrolling.
* Double-clicking empty space to add an object is absolutely undiscoverable. I guess it's fine if you are reading a guide anyway, but I just wanted to jump in and try out things.
* The tiled background editor should show the tile as it actually tiles, otherwise you won't know how it will look. Also, there is no obvious "I'm done" button.
* When you have multiple identical sprites but decide that one of them should be different, there is no obvious way to turn it into its own type so that it can be modified independently. (Short of deleting and recreating it from a clone of the original sprite.)
* None of the preview options seemed to do anything.
That's about when I lost interest.
The concept of your visual editor seems overall quite good, although I'd want keybindings for everything.
Cool project. I think what they were talking about is demonstrated here. For example, in Construct when you want to add an action to an event you click the add button then a wizard pops up to help you assign it. If you know how to program that is annoying because you know how to express yourself faster with text. If you don't know how to express yourself it provides the scaffolding to help you succeed. I think they are lamenting that for experts they haven't seen a visual language that is faster / more expressive. I don't think they would argue that this isn't easier for beginners.
Visual scripting are a really powerful tool. I have never used Godot, but in UE4 you have 3 different styles of visual scripting, and each is a powerful tool in its own style
there are blueprints, that are really easy to use, and are really powerful. just decorate any function in c++ with UFUNCTION() and bam! you have a blueprint callable function.
besides, there are things that just work better in blueprint, like latent actions (in c++ you would have to code timers and stuff, in BP is just action1()->delay(0.5)->action2() ) and curve driven stuff is easier in blueprints
there are animation blueprints: in these you get 'animation data' and you have nodes that help you mix different sources of animation, transform, blend, or simulate rigidbody on certain bones, is like a functional programming where you have this `animationstate` type that you operate with in every node. It also has a graphic state machine where you can describe the animation output in each state, and the rules of transition (for example, transition from idle to run if velocity>5.
also you have materials, is also like another functional programmming, where you grab inputs and put it in material outputs, again like functional programming, you sample textures, pan the samples, mix with colors and do a lot of stuff.
These uses (mostly animation and shaders) are mostly for people without technical inclinations, I would recommend you to try UE4 or godot and see how well visual scripting fits the project.
> I have yet to see a "Visual" programming environment that is even close to as efficient as normal programming. I may well be in a minority on this one, but surely time spent on this would better be spent in other areas like improving C# interoperability etc?
Visual programming languages are not designed for experienced programmers, who would rather type it out. It's designed for those who don't have a programming background, but still might need to wire up some logic on occasion. It's not necessarily meant to be efficient, just user-friendly to someone with no programming experience. If this language makes it easier to write tutorials or get into making games for people coming from an art or design background instead of a programming background, I'm all for it.
IMO visual scripting languages are less about efficiency, more about accessibility. Given a few simple rules and easy to discover widgets, just about anyone can make stuff happen. If anyone can make stuff happen, your going to increase your potential userbase significantly.
It always amazes me when I see people (who would otherwise be freaked out about learning a programming language) having great fun making stuff out of what a seasoned developer might consider archaic gui-driven logic editors. And in comparison to more "pro" development systems with "proper" programming languages, they can churn stuff out by the bucketload with relative ease.
Visual scripting as an aid to designers has been a thing for a long time in commercial game engines. For example Unreal Engine has had visual scripting to aid level design and shader creation for quite a long time.
It's definitely less efficient than text if you're already an experienced programmer but its also more discoverable and intuitive to understand for a lot of people that aren't. It's also nice to play with in a way that pedantic text syntax isn't. They're also really nice for processes where you can inspect the results so far at each stage (shaders, procedural texture generation, solid modelling).
It's not really about raw programming efficiency but efficiency to get the job done, it empowers people other than dedicated programmers to do their jobs without having to sit around waiting for a programmer to do something for them which is very important in terms of iterating on concepts.
>I have yet to see a "Visual" programming environment that is even close to as efficient as normal programming.
There are more than just programmers on modern game projects. I imagine visual scripting is an enormous boon to teams because a designer or someone who makes rules isn't blocked on a programmer implementing those rules. The non-programmer can get the basics down in the visual scripting tool, then the programmer can finish it and tighten it up. I'd love a tool like this in web development that let PM/BAs get started writing test cases they could hand off to me, for example. (I'm aware that tools like this do exist, was trying to be illustrative)
I would have to argue though that something like Unreal Engines blueprints really is like programming with a "lego block twist". The learning curve was steep for a few days but really after that, it's not all that much different then programming by hand. I will say it is a bit easier and it's amazing how fast you can get things done in it.
I'm not sure of a total "non-programmer" being super successful learning blueprints if they can't learn basic programming, but I would say it's a bit easier.
It doesn't have to be easier, it has to be more approachable. The most important part of programming is problem solving no matter how you're doing it, visual, imperative, functional, etc. Some interfaces are much more friendly to different people than others. Text programming often puts off non-programmers instantly, and they are able to reason about visual programming languages much easier than they would text-based ones without putting more time into them.
People here got the idea totally wrong so far. You can see from "WHY VISUAL SCRIPTING?" section in https://godotengine.org/article/godot-getting-more-languages that it's mainly a tool for programmers to let artists in their teams do simple programming stuff, such as homegrown editor plugins.
I think there's merit to visual scripting, some people are more comfortable with it than code. The nice thing about Godot's visual language is that it's basically just a visual representation of functions already in GDScript.
Also, with the GDNative thing, you can plug in any programming language you want (it's a C API, and there's already bindings for C++, D, C#, Python, Nim, and it's trivial to add more languages).
https://godotengine.org/article/godot-getting-more-languages
I have yet to see a "Visual" programming environment that is even close to as efficient as normal programming. I may well be in a minority on this one, but surely time spent on this would better be spent in other areas like improving C# interoperability etc?
I know the intention does not appear to be to replace actual programming, but I think their use-case is weak and put in because it was someone's pet project. Not trying to be ultra-critical, but just think this is wasted resources, which could be better spent elsewhere.
Interested to see what people think about this.
EDIT: Should have phrased this better. So to be clear, I am asking what people think about the relative merits of Visual Scripting and not what part of the project has a higher priority.