8 ms·

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

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__ 6y ago
> 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!).
- pierrec 6y ago
  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 6y ago
    Indeed, I've had mostly positive experiences with Isadora in the audio/video signal processing visual scripting space.
- afwaller 6y ago
  Yeah redstone in Minecraft is pretty good. Very visual. Few people have made entire CPUs https://youtu.be/ydd6l3iYOZE 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
- danwills 6y ago
  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!)
- Lichtso 6y ago
  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.
- dynamite-ready 6y ago
  The node/noodle system in Blender is really good.
  - tpxl 6y ago
    There's a node system in Blender?
    - imtringued 6y ago
      You can use it to procedurally generate textures in Blender
    - vsareto 6y ago
      Yep, shader nodes https://docs.blender.org/manual/en/latest/render/shader_nodes/index.html https://docs.blender.org/manual/en/latest/render/shader_node...
    - dynamite-ready 6y ago
      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.
- rayalez 6y ago
  Houdini/Nuke nodes and vex. It's for a very specific application (computer graphics), but it's incredibly powerful and works amazingly well.
- rcarmo 6y ago
  Bolt in Unity is _very_ nice. Seriously. Not "code grade" kinds of nice, but plenty good enough for map logic.
andrewstuart 6y ago
Why would any software not use an established scripting language like Python or JavaScript? Isn't it just makework and reinventing the wheel (badly)?
- jfkebwjsbx 6y ago
  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.
- dx87 6y ago
  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 6y ago
  BTW dx87 quoted from this page: https://docs.godotengine.org/en/latest/about/faq.html#doc-faq-what-is-gdscript 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.
ngold 6y ago
Working with unity that also does not have a visual script feature, sorta, I like using c#. It's simple and straight forward.
- Tossrock 6y ago
  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.

mhh__ 6y ago

> 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!).

pierrec 6y ago
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 6y ago
  Indeed, I've had mostly positive experiences with Isadora in the audio/video signal processing visual scripting space.
afwaller 6y ago
Yeah redstone in Minecraft is pretty good. Very visual. Few people have made entire CPUs https://youtu.be/ydd6l3iYOZE 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
danwills 6y ago
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!)
Lichtso 6y ago
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.
dynamite-ready 6y ago
The node/noodle system in Blender is really good.
- tpxl 6y ago
  There's a node system in Blender?
  - imtringued 6y ago
    You can use it to procedurally generate textures in Blender
  - vsareto 6y ago
    Yep, shader nodes https://docs.blender.org/manual/en/latest/render/shader_nodes/index.html https://docs.blender.org/manual/en/latest/render/shader_node...
  - dynamite-ready 6y ago
    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.
rayalez 6y ago
Houdini/Nuke nodes and vex. It's for a very specific application (computer graphics), but it's incredibly powerful and works amazingly well.
rcarmo 6y ago
Bolt in Unity is _very_ nice. Seriously. Not "code grade" kinds of nice, but plenty good enough for map logic.

andrewstuart 6y ago

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

jfkebwjsbx 6y ago
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.
dx87 6y ago
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 6y ago
BTW dx87 quoted from this page: https://docs.godotengine.org/en/latest/about/faq.html#doc-faq-what-is-gdscript 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.

ngold 6y ago

Working with unity that also does not have a visual script feature, sorta, I like using c#. It's simple and straight forward.

Tossrock 6y ago
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.