[coppolaemilio]

I did a lot of tutorials on my YouTube channel on how to start making GUI applications with Godot. The visual scripting is really bad for now, so I would stick with GDScript (a Python like language) or C#. It is really a great piece of software to make something quick for non-technical people. I really recommend anyone to explore and play with it a bit and I'm sure you'll find a use for this amazing engine.

[mhh__]

> visual scripting is really bad for now

Are there any visual scripting languages that aren't terrible? The system in unreal works but every time I use it I find myself wanting a text editor (I have spent years learning to program well, be that C++ or shaders, just let me do that!).

[Lichtso]

I think the main issue with most general purpose visual programming languages is, that they are still languages. So they are modeled in a way that resembles a text representation and can often be mapped to a sequence of symbols (a language). However, there are far less tools if you leave the explicit text representation (things like compatible editors, version control, etc.) so it comes down to being an over-the-top syntax highlighting at the expense of the before mentioned other tools. So, I think that visual programming would only become a viable alternative if it were to let go of the ideas of textual programming (language based) and become fully graph based.

[pierrec]

If it's general purpose, then I agree that visual languages always seem to be an annoyance. If it's domain-specific, that's another story, since many domains are all about connecting blocks together. The most common use case is audio/video signal processing, where it works well if you're working above a certain level of abstraction.

[throwaway43234]

Indeed, I've had mostly positive experiences with Isadora in the audio/video signal processing visual scripting space.

[danwills]

The 'Vop' (Vex OPerator) context in SideFX Houdini is the best 'node-based' graphical programming environment that I know of - however you're always working at something like a 'shader'-level. It's strength is in automatic use of SIMD and built-in parallelism (would not be a good choice to write an app in though!)

[dynamite-ready]

The node/noodle system in Blender is really good.

[tpxl]

There's a node system in Blender?

[vsareto]

Yep, shader nodes

https://docs.blender.org/manual/en/latest/render/shader_node...

[dynamite-ready]

Yes. The official node system can be used to script materials/shaders, image compositing, and there are a few excellent plugins to make it stretch to procedural modelling.

[imtringued]

You can use it to procedurally generate textures in Blender

[rayalez]

Houdini/Nuke nodes and vex. It's for a very specific application (computer graphics), but it's incredibly powerful and works amazingly well.

[rcarmo]

Bolt in Unity is _very_ nice. Seriously. Not "code grade" kinds of nice, but plenty good enough for map logic.

[afwaller]

Yeah redstone in Minecraft is pretty good. Very visual. Few people have made entire CPUs

https://youtu.be/ydd6l3iYOZE

It is still just connecting blocks though as pierrec says below so it can take a lot of connections to get something done

[andrewstuart]

Why would any software not use an established scripting language like Python or JavaScript? Isn't it just makework and reinventing the wheel (badly)?

[dx87]

They cover that in the documentation.

What were the motivations behind creating GDScript?

In the early days, the engine used the Lua scripting language. Lua is fast, but creating bindings to an object oriented system (by using fallbacks) was complex and slow and took an enormous amount of code. After some experiments with Python, it also proved difficult to embed.

The main reasons for creating a custom scripting language for Godot were:

Poor threading support in most script VMs, and Godot uses threads (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).

Poor class-extending support in most script VMs, and adapting to the way Godot works is highly inefficient (Lua, Python, JavaScript).

Many existing languages have horrible interfaces for binding to C++, resulting in large amount of code, bugs, bottlenecks, and general inefficiency (Lua, Python, Squirrel, JavaScript, etc.) We wanted to focus on a great engine, not a great amount of integrations.

No native vector types (vector3, matrix4, etc.), resulting in highly reduced performance when using custom types (Lua, Python, Squirrel, JavaScript, ActionScript, etc.).

Garbage collector results in stalls or unnecessarily large memory usage (Lua, Python, JavaScript, ActionScript, etc.).

Difficulty to integrate with the code editor for providing code completion, live editing, etc. (all of them). This is well-supported by GDScript.

GDScript was designed to curtail the issues above, and more.

[follower]

BTW dx87 quoted from this page: https://docs.godotengine.org/en/latest/about/faq.html#doc-fa...

An additional aspect is that--in terms of language design--in many cases "do what Python does" was the design principle followed, so that helps reduce the learning curve for those with Python experience and potentially helps avoid language design roadblocks during development of GDScript itself.

It's extremely common for people to be resistant to using GDScript initially but then be: "oh, actually, this is really good".

And there's now additional bindings for other languages (e.g. C++, C#, Rust, Python to various degrees of completeness) via the "GDNative" interface that essentially provides a C API for communicating with Godot & passing objects around.

[jfkebwjsbx]

I can try to guess a few:

- Bloat... Both are extremely heavy dependencies if you want "the real deal" vs a stripped down version that looks like Python or JavaScript.

- Performance too. Python is slow. JavaScript too, unless you use the modern JITs.

- Licensing perhaps?

- Lack of support for that use case?

- Painful interop? No idea.

[imtringued]

If you threw out everything about Python that was unnecessary it would turn out that's more than 90% of Python and therefore it's worth making a python inspired language from scratch. Using python directly would probably make Godot worse.

I personally dislike the python ecosystem and am not missing anything.

[jcelerier]

> Why would any software not use an established scripting language like Python or JavaScript? Isn't it just makework and reinventing the wheel (badly)?

a lot of visual programming environments, like LabVIEW (1986) or Max/MSP (1985), predate Python and JS by at least a good few years :p

[0xdeadbeefbabe]

If they really were languages, then you would have a better point.

[ngold]

Working with unity that also does not have a visual script feature, sorta, I like using c#.

It's simple and straight forward.

[Tossrock]

Unity just bought Bolt, so Bolt visual scripting is included in all Unity licenses for free, now. There's also the vfx graph and the shader graph node editors.