12 ms·

Godot 4.0 will discontinue visual scripting

303 points by arduinomancer 4y ago

crispyalmond 4y ago
Does this mean they are also removing the VisualShader as well? Or purely the scripting part?
- gridspy 4y ago
  It seems likely that enough people use VisualShader to justify its existance. It is also common to define shaders visually, for instance in Blender.
  - sudosysgen 4y ago
    Composition based approaches also apply particularly well to shaders, since their main drawback being lack of control flow is not a big issue for shaders.
  - prox 4y ago
    Shaders are also far more I/O dependent, with direct feedback visually of the result, there is little abstraction like in programming where the visual feedback isn’t (always) direct.
- LVB 4y ago
  FTA: “To be clear, this refers to the VisualScript scripting language, and not to visual shaders. Visual shaders are working well and appreciated by many users, so they're not going anywhere.”
viraptor 4y ago
Refreshingly clear upfront explanation with data backing it and with alternative paths explained. (even if you can dispute the self-selection in the poll) I like their communication.
scrame 4y ago
Seems like implicitly it's better to take notes from current users than actual users, since your first effort might not be what the potential users expect. Ive only poked at godot, is there a reason that GDscript is so dominant? ETA: is the IDE based around it, or other things aren't well supported, or is visual scripting something that just doesn't fit godot's model
- kroltan 4y ago
  Visual scripting works reasonably well for very high level scripting, but even then it is very "verbose and space inefficient". Writing actual game logic requires a lot of moving stuff around even for small changes. It is also hard to share in our text-first world, so helping or getting community help on it ends up in attachment hell or trading screenshots, both of which are not ideal. As the blog post says, it can probably work better in something like Unreal because the engine already has a lot of things that Godot (and Unity and other similar engines, for that matter) simply does not aim to support. Just as an example, Unreal has a centralized concept of "health" and "dying", so they can provide default libraries to handle the minutia of such things (can health go negative? is "dead" a recoverable state? etc) As for why GDScript specifically is the most popular choice, it's both due to community and due to the engine's design itself. Being literally made for the engine, Godot and GDScript have ver closely tied semantics, which are a (a little) bit more boilerplate-y to handle with GDNative-based alternatives. And since it's such less hassle (and until recently was near the only option), most of the community has built learning materials and libraries optimized for that use.
  - Natsu 4y ago
    I've worked with that kind of programming before in another product and it works much better if you have a lot of useful high-level primitives, it's easy to make your own primitives in a standardized way, and you can easily convert all or part of it to/from a text representation like YAML, which itself should be how the engine stores it in your project so it can be in source control.
    - kroltan 4y ago
phire 4y ago
Reading between the lines: It seems like one of the primary reasons why Blueprints are well-loved in Unreal Engine, is that the only mainstream alternative is full-on c++ (and it's not an easy c++ codebase to work with). But without that pressure of limited choice, blueprint visual scripting seems to have a hard time gaining ground in godot. I do wonder how much of this is because godot's visual scripting never got the polish it needed, and how much is because gdscript is a superior approach.
- gmjosack 4y ago
  While looking into new engines recently I bailed on Unreal because all the docs and tutorials push towards Blueprint. I'd happily use C++ over Blueprint but everything is pushing Blueprint hard to the point I just moved on. Been looking at Godot lately and I really like it and if I need something more than GDScript provides there are bindings to GDNative. I think for some people Visual scripting is probably nice but for me it's an inscrutable mess of flow charts that's way more difficult to use, debug, build understanding of quickly, etc.
- adastra22 4y ago
  I wonder how much it is because Godot a type of developer who is probably more at home in code.
- hgs3 4y ago
  I still find it perplexing that Unreal ditched Unreal Script in favor of Blueprints and full C++.
  - subb 4y ago
    Engineers wants C++, scripters and artists wants Visual Scripting. Seems like an obvious choice to make everyone happy instead of trying to find a middle ground where nobody is?
    - adnzzzzZ 4y ago
      I think Godot shows there's a clear subset of people (generally indie developers) who are fine with the middle ground of a proper scripting language instead of either extreme. It's why languages like Lua are still fairly popular when the option to use it exists.
hresvelgr 4y ago
I am not surprised by this and I'm glad they chose to discontinue it. It was never very good and even to a complete beginner it's nowhere near as easy to use as GDScript. This should free up some development budget for more important features. Visual scripting has never been very good for general purpose programming in my opinion. They don't really represent continuity in an intuitive way and it gets worse when you're dealing with function with many parameters. Shader graphs are probably the one exception to this because they provide a pseudo debugging facility where you get to see how materials change after different operations.
- vvanders 4y ago
  You see it surface in SCADA/PLCs in the form of Ladder programming and Function Block Diagrams. That said from what I understand industry is trending towards more text based approaches lately. As an ex-gamedev it was interesting to see the overlap there when getting into a bit more serious automation stuff. Edit/deploy live, visual representation of state(which is where ladder excels) and other things we used to do a lot of in game dev was present, but on physical running hardware connected to other sensors/endpoints.
- mrtksn 4y ago
  I haven't used the Godot one but they have something similar in Blender and I find this type of programming really hard to reason on. An algorithm is supposed to be a sequel of instructions and it is easy to follow in code(you go from top to bottom) but it's hard to follow when represented as if it is a set of pipes going through boxes. Also, the boxes often require specific type that is not compatible with the output from the previous box and you need to create an algorithm for type conversion and that appears as prominent as the actual algorithm that you are trying to create(in code, you can hide the type conversion complexity behind a function, for example) and as a result it's really hard to get "the gist" of the algo when represented in this visual style.
  - arduinomancer 4y ago
    Hmm most visual scripting languages I’ve used let you abstract things You would just move the conversion logic to its own re-usable block and place that in your algorithm Then if you say double click the conversion block you can see the logic inside it
cpeterso 4y ago
How do visual scripting systems like Unreal Blueprints handle version control and merging of changes from multiple people?
- cma 4y ago
  They implemented a built in visual diff tool that diffs the graphs and properties side by side and integrates with any of the supported source control plugins. Merging has to be done manually though, so most teams use source control locks like for art assets. There are several ways to split blueprints into more files to result in less locks.
- aaronfranke 4y ago
  With Godot's VisualScript, it's not handled at all. The files are saved as a binary format and cannot be merged, even manually.
zubspace 4y ago
I am really looking forward to Godot 4. GDScript improved a lot. I'm mostly excited about callables (function pointers), easier signal handling in combination with await (former yields) and an improved tweening system. The scripting environment inside of the editor with inbuilt documentation, code completion and debugger is really an achievement. The only thing I miss are static typing and refactoring tools. You can use type hints, but you need to fall back to dynamic typing at some places for example because there are no generic collections. Therefore I'm quite excited about the dotnet6 branch being merged into main a few days ago [1]. This is a huge step and will probably make some unity developers consider Godot for their next game. Also there's GDExtension, the successor of GDNative, which will make it easier to integrate C++ code [2]. I could never imagine myself using Visual Scripting, because you can express yourself so much easier in Code. [1] https://github.com/godotengine/godot/pull/64089 https://github.com/godotengine/godot/pull/64089 [2] https://godotengine.org/article/introducing-gd-extensions https://godotengine.org/article/introducing-gd-extensions
- JamesBaxter 4y ago
  Trying to get my Godot project to a stable enough place that I can try early dotnet6 builds. It’s been quite fun abstracting as much game logic as possible into testable class libraries so I’m hoping it won’t be a bad migration for me. Really looking forward to seeing if dependency injection will be easier
  - runevault 4y ago
    Is dotnet 6 support slated to release with godot 4 or will it be a post-initial release timeframe? Last I heard it wasn't ready yet but I have not been looking too closely. Having latest dotnet would get me interested in trying godot again over downloading Unity onto my new laptop when I get back to gamedev.
    - JamesBaxter 4y ago
      It’s been merged into master [0] I think that means it’s coming with 4. One of my minor concerns is that exporting to iOS/Android might not be coming straight away but I’ll have to play with it to find out! [0] https://github.com/godotengine/godot/pull/64089 https://github.com/godotengine/godot/pull/64089
matesz 4y ago
For newcommers to this subject, I really recommend watching this video [1]. It compares C++ vs Blueprints in UE. The author behind it has lot of game programming overview videos. I'm not that much into video watching since it's much harder to jump between sections than in textual content, but still these are really really good. Also, maybe in a little bit different space is enso.org - visual real time etl. People behind it have just received series A funding. You can design pipeline using visual editor (built in rust btw., however it doesn't work that well yet imo) and custom built programming language [2]. I think you can even go from textual representation to visual and back, not 100% on that one though. [1] https://www.youtube.com/watch?v=VMZftEVDuCE https://www.youtube.com/watch?v=VMZftEVDuCE [2] https://enso.org/docs/syntax https://enso.org/docs/syntax
sirwhinesalot 4y ago
The sort of graph based editing they used sucks for coding anything beyond a pile of data transformations (which is why it works well in Enso or for Blender pipelines). If they want visual editing they should look into old Game Maker or Construct 3 for how to do newbie friendly visual scripting.
- prox 4y ago
  That’s why it wise to put it into a GDExtension, maybe one day we will see some experiments with some drag and drop functionality. Although for me the scenetree is already visual enough.
  - sirwhinesalot 4y ago
    I agree, GDScript is pretty darn good, all the visual editing facilities (besides the scripting) are great, so the loss of visual scripting is not a major one. Let us see what the community comes up with!
born-jre 4y ago
huh, i wonder it is possible to just do visual editor on top of gdscript instead similar to https://developers.google.com/blockly/ https://developers.google.com/blockly/
- deleted 4y ago
  [deleted]
bodge5000 4y ago
A little off topic, and I know it'll never happen (though it is a common, if very minor, issue people have with Godot), but in that header image it looks like they accidentally found a better logo for Godot. It's still got the classic shape, and the centre circle looks less like the centre of a cog and more like an eye, but its also a lot cleaner than we've currently got. Anyway, back on topic, yeh I think this is for the best. I never really saw it used, and the few times I tried myself it seemed less intuative than just programming. Also much harder to express in documentation. Also for beginners, its not a great lesson to learn, visual scripting is uncommon in the wider industry outside of game dev, and where it does exist is very specific to its own software
- yardshop 4y ago
  That center circle is actually the sun approaching the horizon, because they are "sunsetting" Visual Scripting.
  - bodge5000 4y ago
    yeh I get thats what they were going for, I just thought it looked nice as an unlikely potential new logo
cm2187 4y ago
There are lots of initiatives for "no code", Microsoft's power suite, Alteryx, Office's power pivot, etc. I love the idea that non technical users could do more and create active programs. But my experience is that the population who will not learn code (and I am not talking about learning c++, more like SQL and python/VBA) is also the population who will not want to learn a complex software with its internal logic and create complex workflows. Whereas the population who would be happy to do so, is also the population who would pick up a scripting language easily. So in the end the user base for those tools is pretty narrow.
- OkayPhysicist 4y ago
  They have a small user base, but a much larger customer base. The non-technical people who recognize the utility of programming but can't be assed think that their underlings will be all over those "no"-code solutions.
- danschuller 4y ago
  For me, I think there's an element of "discoverability" that most programming languages doesn't have. With a visual scripting language you can literally see the nodes you can use and drag them on a canvas with a reasonable chance of making something happen. Programming languages, even if you start up with some kind repl you cannot naturally guess the primitives, you are forced to read a tutorial or manual, that's quite a lot friction to onboard someone. (Same kind of things applies to a GUI vs a shell)
qikInNdOutReply 4y ago
Visual scripting is a dead end. Much preferable would be to have a IDE to display code visually in metaphors. Like i create a input set, and then can watch the input traverse the state-pachinko machine until it comes to rest again. Make it easier to see cause and effect of a single moment, visually displayed, without loosing the underlying code and class structure.
- throw_m239339 4y ago
  > Visual scripting is a dead end. Tell that to the Blender team and their "everything nodes" project... When done right it allows artists and non programmers to write programs. https://docs.blender.org/manual/en/latest/modeling/geometry_nodes/introduction.html https://docs.blender.org/manual/en/latest/modeling/geometry_... Another popular project is animation nodes https://www.youtube.com/watch?v=UB8R_xPpaSc https://www.youtube.com/watch?v=UB8R_xPpaSc These are alternatives to Python in Blender. So no, it's not a dead end, it depends on how it is implemented. Node based programming is essentially functional programming. But for it to be useful one needs both low level nodes along side higher level nodes that are immediately useful for artists.
  - edflsafoiewq 4y ago
    Nodes let non-programmers access some of the power of being able to program. It's inferior to real programming in every other way though. Writing code to generate node graphs (eg. for Blender materials) is particularly hellacious.
    - throw_m239339 4y ago
      > It's inferior to real programming in every other way though. Writing code to generate node graphs (eg. for Blender materials) is particularly hellacious. Programming is programming, there is no such thing as "real programming". Visual programming is an alternative to textual programming, we're discussing whether it's good or not, but let's not imply that visual programming is not programming, it is programming. > Writing code to generate node graphs (eg. for Blender materials) is particularly hellacious No, it isn't hellacious. Node based programming languages eliminates a few things non programmers don't want to deal with: syntax errors and type errors.
KronisLV 4y ago
Moving it to an extension seems like the sane thing to do! That way: 1.) the functionality wouldn't be gone forever with no way for anyone to use it 2.) the community could maintain it and fix and eventual incompatibilities with the main engine 3.) the engine developers could focus their efforts elsewhere, better spending their limited resources 4.) the quality of the plugin would be proportional to the size of the community; if people care, it'd survive; if not, then no effort wasted Of course, personally I'm in the camp of people who want to use a general purpose language like C# for game programming due to its wider ecosystem, about which I've written here: https://news.ycombinator.com/item?id=32274504 https://news.ycombinator.com/item?id=32274504 That said, it most definitely takes effort to support it as well, so if it was to be dropped in the future eventually, in favor of only supporting C++ or GDScript as first party languages, I'd be understanding, similarly to how one might want to have 3rd party bindings for Rust or Lua or Python or whatever without the engine developers having to care about it too much. I think something like that actually happened to Boo in Unity: https://blog.unity.com/technology/documentation-unity-scripting-languages-and-you https://blog.unity.com/technology/documentation-unity-script... That said, having any visual scripting capabilities is pretty cool, like for use cases such as dialogue trees, state machines, shader graphs etc. People generally seemed to think rather highly of plugins like Dialogic for Godot: https://github.com/coppolaemilio/dialogic/blob/main/addons/dialogic/Documentation/Content/Welcome.md https://github.com/coppolaemilio/dialogic/blob/main/addons/d...
weinzierl 4y ago
> Godot ended up allowing a lot of its users to be a tool to learn programming instead. This, so much. After careful deliberation I chose Godot and GDScript as a follow-up after Scratch for my kid to learn programming. Godot and GDScript are great, because: - Easy enough to pick up after Scratch. GDScript is easy to learn yet powerful enough to teach most relevant programming concepts and it even is able to make real world applications. - Graphics and Sound! Nothing is more motivating for children than something that moves, blinks and makes noise. That's how I got into programming in the 80s and it still works the same - technology changed a lot but humans are still humans. - With Godot it is easy to make a mobil app. I cannot stress enough how important that is. The primary computing device for kids today is the mobile phone. If the thing you make isn't there it doesn't exist. - GDScript is quite similar to Python - in syntax and spirit. It will make learning Python as the next language a lot easier. - GDScript just makes sense and is free from legacy cruft. You don't have to constantly hand-wave away things you can only explain with a lot of historical context, which children totally lack. - Games! The only thing more fun than playing games is making your own. - Godot is not a toy (like Scratch) but is used for real world apps! Not even games only but also serious apps with 10k+ users, like the Tesla app for example. Kids love to do serious grown-ups stuff. Funnily, even after spending quite some time with Godot recently, this article is the first time I heard about Godot's visual scripting. If I had known about it, I might have used it to ease the transition from Scratch.
- bluescrn 4y ago
  As a long-time Unity user increasingly interested in alternatives, I find the choice of a non-standard language to be very offputting, moreso than the thought of returning to the pain of C++ to work with UE. Established languages generally have high-quality tools for debugging, refactoring, and more, as well as loads of libraries and code examples available, and books/tutorials/documentation. IMHO, one of Unity's best moves was to focus on C# and discontinue support for their own custom language.
  - Antshockey 4y ago
    Godots support for C# is excellent out of the box to be honest. I've not found anything I can't do in C#. There are one or two things that are harder to find but they are few and far between
spywaregorilla 4y ago
Most people are missing the big point I think which is their point 2 > Even though the visual scripting part was good enough, Godot lacked high level components to make use of it. Engines like Unreal, Game Maker or Construct offer high level game features packaged together with the visual scripting solution. This is what makes it useful. Godot is an extremely general purpose game engine where it's easy to make those features yourself, but they don't come packaged out of the box. As such, visual scripting by itself was of little use. This is it. what makes unreal blueprints great is that it's mostly just engine API calls. This is pleasant to do and generally helps you learn the engine in a discoverable way. Want to walk around? Character movement component. Want to play with audio? Audio component. etc. etc. My current project is about 90/10 bp/cpp. It's not right to think of it as no code. You're going to need to think an awful lot about class inheritance, interfaces, event replication, etc. It's very much code and the swarms of noobies that want to try it without understanding code fundamentals all give up pretty quick.
meltyness 4y ago
Huge Godot fan! Built a prototype of a VR app, myself, ran it wirelessly -- and the whole process was very, very smooth. Love it! Isn't this a bit of a problem for people with dyslexia? I'm sure a compatibility layer could be built -- or since you can script Godot with C++ or Python, that some workaround could be found. I feel like asking here would jilt my response, but I know someone who has dyslexia, and it greatly hampers, at the very least, their motivation to deal with any type of software. Furthermore, it looks like their motivation for removing it is simply usage-rate... wouldn't that suggest maybe that the problem isn't Visual Script, but possibly that the market demanding it couldn't figure it out? To that, there is an explanation of how to use NativeScript at https://docs.godotengine.org https://docs.godotengine.org but there's a barrier that you have to take the 3-hour tutorial geared towards GDScript (not VisualScript) in order to get an introduction to the Godot Engine state machine hierarchy, so there's no real pathway to using it for the target market without the barrier of regular coding.
- aaronfranke 4y ago
  The problem is that there are no contributors interested in improving VisualScript, so it has stagnated. If interested contributors show up, they are still welcome to work on VisualScript in the form of a GDExtension. If nobody offers to do the work for free, the three options are to remove it from the engine, let it stagnate and stay unusable, or pay core contributors to work on VisualScript. The latter of which takes away time and money from other things they could be working on.
slipwalker 4y ago
https://youtu.be/jAAkD827ubc?t=379 https://youtu.be/jAAkD827ubc?t=379 this is a fair comparison of GDScript, C# and Visual Script, and the conclusion was "visual script is good for no one"
sylware 4y ago
godot has a c++ toxicity issue to solve for elf/linux game binaries, I did report to them the issue, and indeed, they reasonably cannot do anything, only the gcc devs (glibc devs should be safe now) can do something (or godot would have to move to good and plain C, or similar). Game binaries should be a set of elf binaries statically loading (elf dt_needed) only libdl, namely with only dlopen/dlsym(tls safe)/dlclose symbols (with the oldest version as possible, probably 2.2.5) in the elf dynsym section except the other symbols from those very distributed binaries. The pb is the static gcc libstdc++ (and to a lesser extent the gcc static libgcc) does not libdl anything from the C runtime, or even worse could link to glibc internal symbols. All those very symbols, will end up in the elf dynsym section of the distributed binaries with the versions from the glibc used at link time. Namely, if a user wants to run on a older glibc distro those binaries, since glibc devs have a versioning frenzy, it won't even load (and the reasons are often more planned obsolescence than anything else). Some must not forget that static linking won't do unless a full elf loader is in linked in, since xcb/(wayland is static)/libasound(pulseaudio,pipewire,jack,whatever is hidden behind the alsa api)/libxkbcommon(-x11)/vulkan/(GL) libs will have to be loaded from system. Godot, as mitigation, pushes the devs to link with a very, VERY old, glibc (a decade?). It provides "containers" for "building" with an old glibc, and for the devs not using those containers, the documentation is clear about the age of the glibc to link with. The reality is gcc c++ was never meant for binary-only distribution, just never.
- account42 4y ago
  > Game binaries should be a set of elf binaries statically loading (elf dt_needed) only libdl, namely with only dlopen/dlsym(tls safe)/dlclose symbols (with the oldest version as possible, probably 2.2.5) in the elf dynsym section except the other symbols from those very distributed binaries. That is not a requirement at all. There is nothing wrong with linking against libc or other glibc libraries as long as you compile agianst the oldest version you want to support. Picking random version of glibc symbols makes no sense as they have absolutely no guarantee of being ABI-compatible, hence the different symbol versions. But if you WANT to dynamically load everying in glibc for whatever reason you can always create your own stub that provides those symbols and thunks the calls through function pointers that you can fill on startup with whaever logic you want and then statically link that stub so that all libc/whatever calls use your stub instead. > Godot, as mitigation, pushes the devs to link with a very, VERY old, glibc (a decade?). It provides "containers" for "building" with an old glibc, and for the devs not using those containers, the documentation is clear about the age of the glibc to link with. That is the best solution. Note that this does not mean that the users will be using an old unpatched glibc, just that the old interfaces will be used, which are still maintained in newer glibc versions.
oifjsidjf 4y ago
One of the reason why I used Blueprints a lot in UE4 (despite being totaly at home and liking C++) is that iteration was much faster. Recompiling C++ was ok-ish with hot-reload, but each time I changed/added some header file or class/struct member I had to recompile the entire thing which meant restarting the entire Unreal Editor. During this wait time I often went online which broke my flow or productivity.
dunno7456 4y ago
Well written! Thanks for the team!
alexalx666 4y ago
its a shame they don't have more support for quickly building non-game UIs in their wonderful editor. Last time trying to create a simple app felt like dragging IB connects in XCode 5 years ago but less intuitive
- krapp 4y ago
  Once Godot 4 drops and GDExtension starts getting traction, that seems like a perfect use case for a plugin.
Hfmwodb 4y ago
Context: I’ve used Godot 3 and I have a fair bit of experience in several programming languages. I think this is a terrible idea, even though understand why they would want to drop support for it. I personally prefer typing out the logic, but I’ve seen some of these “let’s make a video game without writing code” videos, and it makes me sad that they don’t think it’s worth focusing on. I think this is going to make budding game developers choose some other engine (where they will become more comfortable and they’ll mostly stick to).
dkersten 4y ago
Godot’s visual scripting was very much an afterthought anyway. It was an alternative syntax for GDScript really, rather than something designed with a use case in mind. Visual scripting can be great, if it’s specifically designed to tackle certain tasks (eg why visual shaders tend to work great, or high level visual scripting). As an alternative to textual syntax, it’s not very good.

303 points by arduinomancer 4y ago

crispyalmond 4y ago

Does this mean they are also removing the VisualShader as well? Or purely the scripting part?

gridspy 4y ago
It seems likely that enough people use VisualShader to justify its existance. It is also common to define shaders visually, for instance in Blender.
- sudosysgen 4y ago
  Composition based approaches also apply particularly well to shaders, since their main drawback being lack of control flow is not a big issue for shaders.
- prox 4y ago
  Shaders are also far more I/O dependent, with direct feedback visually of the result, there is little abstraction like in programming where the visual feedback isn’t (always) direct.
LVB 4y ago
FTA: “To be clear, this refers to the VisualScript scripting language, and not to visual shaders. Visual shaders are working well and appreciated by many users, so they're not going anywhere.”

viraptor 4y ago

Refreshingly clear upfront explanation with data backing it and with alternative paths explained. (even if you can dispute the self-selection in the poll) I like their communication.

scrame 4y ago

Seems like implicitly it's better to take notes from current users than actual users, since your first effort might not be what the potential users expect. Ive only poked at godot, is there a reason that GDscript is so dominant? ETA: is the IDE based around it, or other things aren't well supported, or is visual scripting something that just doesn't fit godot's model

kroltan 4y ago
Visual scripting works reasonably well for very high level scripting, but even then it is very "verbose and space inefficient". Writing actual game logic requires a lot of moving stuff around even for small changes. It is also hard to share in our text-first world, so helping or getting community help on it ends up in attachment hell or trading screenshots, both of which are not ideal. As the blog post says, it can probably work better in something like Unreal because the engine already has a lot of things that Godot (and Unity and other similar engines, for that matter) simply does not aim to support. Just as an example, Unreal has a centralized concept of "health" and "dying", so they can provide default libraries to handle the minutia of such things (can health go negative? is "dead" a recoverable state? etc) As for why GDScript specifically is the most popular choice, it's both due to community and due to the engine's design itself. Being literally made for the engine, Godot and GDScript have ver closely tied semantics, which are a (a little) bit more boilerplate-y to handle with GDNative-based alternatives. And since it's such less hassle (and until recently was near the only option), most of the community has built learning materials and libraries optimized for that use.
- Natsu 4y ago
  I've worked with that kind of programming before in another product and it works much better if you have a lot of useful high-level primitives, it's easy to make your own primitives in a standardized way, and you can easily convert all or part of it to/from a text representation like YAML, which itself should be how the engine stores it in your project so it can be in source control.
  - kroltan 4y ago

phire 4y ago

Reading between the lines: It seems like one of the primary reasons why Blueprints are well-loved in Unreal Engine, is that the only mainstream alternative is full-on c++ (and it's not an easy c++ codebase to work with). But without that pressure of limited choice, blueprint visual scripting seems to have a hard time gaining ground in godot. I do wonder how much of this is because godot's visual scripting never got the polish it needed, and how much is because gdscript is a superior approach.

gmjosack 4y ago
While looking into new engines recently I bailed on Unreal because all the docs and tutorials push towards Blueprint. I'd happily use C++ over Blueprint but everything is pushing Blueprint hard to the point I just moved on. Been looking at Godot lately and I really like it and if I need something more than GDScript provides there are bindings to GDNative. I think for some people Visual scripting is probably nice but for me it's an inscrutable mess of flow charts that's way more difficult to use, debug, build understanding of quickly, etc.
adastra22 4y ago
I wonder how much it is because Godot a type of developer who is probably more at home in code.
hgs3 4y ago
I still find it perplexing that Unreal ditched Unreal Script in favor of Blueprints and full C++.
- subb 4y ago
  Engineers wants C++, scripters and artists wants Visual Scripting. Seems like an obvious choice to make everyone happy instead of trying to find a middle ground where nobody is?
  - adnzzzzZ 4y ago
    I think Godot shows there's a clear subset of people (generally indie developers) who are fine with the middle ground of a proper scripting language instead of either extreme. It's why languages like Lua are still fairly popular when the option to use it exists.

hresvelgr 4y ago

I am not surprised by this and I'm glad they chose to discontinue it. It was never very good and even to a complete beginner it's nowhere near as easy to use as GDScript. This should free up some development budget for more important features. Visual scripting has never been very good for general purpose programming in my opinion. They don't really represent continuity in an intuitive way and it gets worse when you're dealing with function with many parameters. Shader graphs are probably the one exception to this because they provide a pseudo debugging facility where you get to see how materials change after different operations.

vvanders 4y ago
You see it surface in SCADA/PLCs in the form of Ladder programming and Function Block Diagrams. That said from what I understand industry is trending towards more text based approaches lately. As an ex-gamedev it was interesting to see the overlap there when getting into a bit more serious automation stuff. Edit/deploy live, visual representation of state(which is where ladder excels) and other things we used to do a lot of in game dev was present, but on physical running hardware connected to other sensors/endpoints.
mrtksn 4y ago
I haven't used the Godot one but they have something similar in Blender and I find this type of programming really hard to reason on. An algorithm is supposed to be a sequel of instructions and it is easy to follow in code(you go from top to bottom) but it's hard to follow when represented as if it is a set of pipes going through boxes. Also, the boxes often require specific type that is not compatible with the output from the previous box and you need to create an algorithm for type conversion and that appears as prominent as the actual algorithm that you are trying to create(in code, you can hide the type conversion complexity behind a function, for example) and as a result it's really hard to get "the gist" of the algo when represented in this visual style.
- arduinomancer 4y ago
  Hmm most visual scripting languages I’ve used let you abstract things You would just move the conversion logic to its own re-usable block and place that in your algorithm Then if you say double click the conversion block you can see the logic inside it

cpeterso 4y ago

How do visual scripting systems like Unreal Blueprints handle version control and merging of changes from multiple people?

cma 4y ago
They implemented a built in visual diff tool that diffs the graphs and properties side by side and integrates with any of the supported source control plugins. Merging has to be done manually though, so most teams use source control locks like for art assets. There are several ways to split blueprints into more files to result in less locks.
aaronfranke 4y ago
With Godot's VisualScript, it's not handled at all. The files are saved as a binary format and cannot be merged, even manually.

zubspace 4y ago

I am really looking forward to Godot 4. GDScript improved a lot. I'm mostly excited about callables (function pointers), easier signal handling in combination with await (former yields) and an improved tweening system. The scripting environment inside of the editor with inbuilt documentation, code completion and debugger is really an achievement. The only thing I miss are static typing and refactoring tools. You can use type hints, but you need to fall back to dynamic typing at some places for example because there are no generic collections. Therefore I'm quite excited about the dotnet6 branch being merged into main a few days ago [1]. This is a huge step and will probably make some unity developers consider Godot for their next game. Also there's GDExtension, the successor of GDNative, which will make it easier to integrate C++ code [2]. I could never imagine myself using Visual Scripting, because you can express yourself so much easier in Code. [1] https://github.com/godotengine/godot/pull/64089 https://github.com/godotengine/godot/pull/64089 [2] https://godotengine.org/article/introducing-gd-extensions https://godotengine.org/article/introducing-gd-extensions

JamesBaxter 4y ago
Trying to get my Godot project to a stable enough place that I can try early dotnet6 builds. It’s been quite fun abstracting as much game logic as possible into testable class libraries so I’m hoping it won’t be a bad migration for me. Really looking forward to seeing if dependency injection will be easier
- runevault 4y ago
  Is dotnet 6 support slated to release with godot 4 or will it be a post-initial release timeframe? Last I heard it wasn't ready yet but I have not been looking too closely. Having latest dotnet would get me interested in trying godot again over downloading Unity onto my new laptop when I get back to gamedev.
  - JamesBaxter 4y ago
    It’s been merged into master [0] I think that means it’s coming with 4. One of my minor concerns is that exporting to iOS/Android might not be coming straight away but I’ll have to play with it to find out! [0] https://github.com/godotengine/godot/pull/64089 https://github.com/godotengine/godot/pull/64089

matesz 4y ago

For newcommers to this subject, I really recommend watching this video [1]. It compares C++ vs Blueprints in UE. The author behind it has lot of game programming overview videos. I'm not that much into video watching since it's much harder to jump between sections than in textual content, but still these are really really good. Also, maybe in a little bit different space is enso.org - visual real time etl. People behind it have just received series A funding. You can design pipeline using visual editor (built in rust btw., however it doesn't work that well yet imo) and custom built programming language [2]. I think you can even go from textual representation to visual and back, not 100% on that one though. [1] https://www.youtube.com/watch?v=VMZftEVDuCE https://www.youtube.com/watch?v=VMZftEVDuCE [2] https://enso.org/docs/syntax https://enso.org/docs/syntax

sirwhinesalot 4y ago

The sort of graph based editing they used sucks for coding anything beyond a pile of data transformations (which is why it works well in Enso or for Blender pipelines). If they want visual editing they should look into old Game Maker or Construct 3 for how to do newbie friendly visual scripting.

prox 4y ago
That’s why it wise to put it into a GDExtension, maybe one day we will see some experiments with some drag and drop functionality. Although for me the scenetree is already visual enough.
- sirwhinesalot 4y ago
  I agree, GDScript is pretty darn good, all the visual editing facilities (besides the scripting) are great, so the loss of visual scripting is not a major one. Let us see what the community comes up with!

born-jre 4y ago

huh, i wonder it is possible to just do visual editor on top of gdscript instead similar to https://developers.google.com/blockly/ https://developers.google.com/blockly/

deleted 4y ago
[deleted]

bodge5000 4y ago

A little off topic, and I know it'll never happen (though it is a common, if very minor, issue people have with Godot), but in that header image it looks like they accidentally found a better logo for Godot. It's still got the classic shape, and the centre circle looks less like the centre of a cog and more like an eye, but its also a lot cleaner than we've currently got. Anyway, back on topic, yeh I think this is for the best. I never really saw it used, and the few times I tried myself it seemed less intuative than just programming. Also much harder to express in documentation. Also for beginners, its not a great lesson to learn, visual scripting is uncommon in the wider industry outside of game dev, and where it does exist is very specific to its own software

yardshop 4y ago
That center circle is actually the sun approaching the horizon, because they are "sunsetting" Visual Scripting.
- bodge5000 4y ago
  yeh I get thats what they were going for, I just thought it looked nice as an unlikely potential new logo

cm2187 4y ago

There are lots of initiatives for "no code", Microsoft's power suite, Alteryx, Office's power pivot, etc. I love the idea that non technical users could do more and create active programs. But my experience is that the population who will not learn code (and I am not talking about learning c++, more like SQL and python/VBA) is also the population who will not want to learn a complex software with its internal logic and create complex workflows. Whereas the population who would be happy to do so, is also the population who would pick up a scripting language easily. So in the end the user base for those tools is pretty narrow.

OkayPhysicist 4y ago
They have a small user base, but a much larger customer base. The non-technical people who recognize the utility of programming but can't be assed think that their underlings will be all over those "no"-code solutions.
danschuller 4y ago
For me, I think there's an element of "discoverability" that most programming languages doesn't have. With a visual scripting language you can literally see the nodes you can use and drag them on a canvas with a reasonable chance of making something happen. Programming languages, even if you start up with some kind repl you cannot naturally guess the primitives, you are forced to read a tutorial or manual, that's quite a lot friction to onboard someone. (Same kind of things applies to a GUI vs a shell)

qikInNdOutReply 4y ago

Visual scripting is a dead end. Much preferable would be to have a IDE to display code visually in metaphors. Like i create a input set, and then can watch the input traverse the state-pachinko machine until it comes to rest again. Make it easier to see cause and effect of a single moment, visually displayed, without loosing the underlying code and class structure.

throw_m239339 4y ago
> Visual scripting is a dead end. Tell that to the Blender team and their "everything nodes" project... When done right it allows artists and non programmers to write programs. https://docs.blender.org/manual/en/latest/modeling/geometry_nodes/introduction.html https://docs.blender.org/manual/en/latest/modeling/geometry_... Another popular project is animation nodes https://www.youtube.com/watch?v=UB8R_xPpaSc https://www.youtube.com/watch?v=UB8R_xPpaSc These are alternatives to Python in Blender. So no, it's not a dead end, it depends on how it is implemented. Node based programming is essentially functional programming. But for it to be useful one needs both low level nodes along side higher level nodes that are immediately useful for artists.
- edflsafoiewq 4y ago
  Nodes let non-programmers access some of the power of being able to program. It's inferior to real programming in every other way though. Writing code to generate node graphs (eg. for Blender materials) is particularly hellacious.
  - throw_m239339 4y ago
    > It's inferior to real programming in every other way though. Writing code to generate node graphs (eg. for Blender materials) is particularly hellacious. Programming is programming, there is no such thing as "real programming". Visual programming is an alternative to textual programming, we're discussing whether it's good or not, but let's not imply that visual programming is not programming, it is programming. > Writing code to generate node graphs (eg. for Blender materials) is particularly hellacious No, it isn't hellacious. Node based programming languages eliminates a few things non programmers don't want to deal with: syntax errors and type errors.

KronisLV 4y ago

Moving it to an extension seems like the sane thing to do! That way: 1.) the functionality wouldn't be gone forever with no way for anyone to use it 2.) the community could maintain it and fix and eventual incompatibilities with the main engine 3.) the engine developers could focus their efforts elsewhere, better spending their limited resources 4.) the quality of the plugin would be proportional to the size of the community; if people care, it'd survive; if not, then no effort wasted Of course, personally I'm in the camp of people who want to use a general purpose language like C# for game programming due to its wider ecosystem, about which I've written here: https://news.ycombinator.com/item?id=32274504 https://news.ycombinator.com/item?id=32274504 That said, it most definitely takes effort to support it as well, so if it was to be dropped in the future eventually, in favor of only supporting C++ or GDScript as first party languages, I'd be understanding, similarly to how one might want to have 3rd party bindings for Rust or Lua or Python or whatever without the engine developers having to care about it too much. I think something like that actually happened to Boo in Unity: https://blog.unity.com/technology/documentation-unity-scripting-languages-and-you https://blog.unity.com/technology/documentation-unity-script... That said, having any visual scripting capabilities is pretty cool, like for use cases such as dialogue trees, state machines, shader graphs etc. People generally seemed to think rather highly of plugins like Dialogic for Godot: https://github.com/coppolaemilio/dialogic/blob/main/addons/dialogic/Documentation/Content/Welcome.md https://github.com/coppolaemilio/dialogic/blob/main/addons/d...

weinzierl 4y ago

> Godot ended up allowing a lot of its users to be a tool to learn programming instead. This, so much. After careful deliberation I chose Godot and GDScript as a follow-up after Scratch for my kid to learn programming. Godot and GDScript are great, because: - Easy enough to pick up after Scratch. GDScript is easy to learn yet powerful enough to teach most relevant programming concepts and it even is able to make real world applications. - Graphics and Sound! Nothing is more motivating for children than something that moves, blinks and makes noise. That's how I got into programming in the 80s and it still works the same - technology changed a lot but humans are still humans. - With Godot it is easy to make a mobil app. I cannot stress enough how important that is. The primary computing device for kids today is the mobile phone. If the thing you make isn't there it doesn't exist. - GDScript is quite similar to Python - in syntax and spirit. It will make learning Python as the next language a lot easier. - GDScript just makes sense and is free from legacy cruft. You don't have to constantly hand-wave away things you can only explain with a lot of historical context, which children totally lack. - Games! The only thing more fun than playing games is making your own. - Godot is not a toy (like Scratch) but is used for real world apps! Not even games only but also serious apps with 10k+ users, like the Tesla app for example. Kids love to do serious grown-ups stuff. Funnily, even after spending quite some time with Godot recently, this article is the first time I heard about Godot's visual scripting. If I had known about it, I might have used it to ease the transition from Scratch.

bluescrn 4y ago
As a long-time Unity user increasingly interested in alternatives, I find the choice of a non-standard language to be very offputting, moreso than the thought of returning to the pain of C++ to work with UE. Established languages generally have high-quality tools for debugging, refactoring, and more, as well as loads of libraries and code examples available, and books/tutorials/documentation. IMHO, one of Unity's best moves was to focus on C# and discontinue support for their own custom language.
- Antshockey 4y ago
  Godots support for C# is excellent out of the box to be honest. I've not found anything I can't do in C#. There are one or two things that are harder to find but they are few and far between

spywaregorilla 4y ago

Most people are missing the big point I think which is their point 2 > Even though the visual scripting part was good enough, Godot lacked high level components to make use of it. Engines like Unreal, Game Maker or Construct offer high level game features packaged together with the visual scripting solution. This is what makes it useful. Godot is an extremely general purpose game engine where it's easy to make those features yourself, but they don't come packaged out of the box. As such, visual scripting by itself was of little use. This is it. what makes unreal blueprints great is that it's mostly just engine API calls. This is pleasant to do and generally helps you learn the engine in a discoverable way. Want to walk around? Character movement component. Want to play with audio? Audio component. etc. etc. My current project is about 90/10 bp/cpp. It's not right to think of it as no code. You're going to need to think an awful lot about class inheritance, interfaces, event replication, etc. It's very much code and the swarms of noobies that want to try it without understanding code fundamentals all give up pretty quick.

meltyness 4y ago

Huge Godot fan! Built a prototype of a VR app, myself, ran it wirelessly -- and the whole process was very, very smooth. Love it! Isn't this a bit of a problem for people with dyslexia? I'm sure a compatibility layer could be built -- or since you can script Godot with C++ or Python, that some workaround could be found. I feel like asking here would jilt my response, but I know someone who has dyslexia, and it greatly hampers, at the very least, their motivation to deal with any type of software. Furthermore, it looks like their motivation for removing it is simply usage-rate... wouldn't that suggest maybe that the problem isn't Visual Script, but possibly that the market demanding it couldn't figure it out? To that, there is an explanation of how to use NativeScript at https://docs.godotengine.org https://docs.godotengine.org but there's a barrier that you have to take the 3-hour tutorial geared towards GDScript (not VisualScript) in order to get an introduction to the Godot Engine state machine hierarchy, so there's no real pathway to using it for the target market without the barrier of regular coding.

aaronfranke 4y ago
The problem is that there are no contributors interested in improving VisualScript, so it has stagnated. If interested contributors show up, they are still welcome to work on VisualScript in the form of a GDExtension. If nobody offers to do the work for free, the three options are to remove it from the engine, let it stagnate and stay unusable, or pay core contributors to work on VisualScript. The latter of which takes away time and money from other things they could be working on.

slipwalker 4y ago

https://youtu.be/jAAkD827ubc?t=379 https://youtu.be/jAAkD827ubc?t=379 this is a fair comparison of GDScript, C# and Visual Script, and the conclusion was "visual script is good for no one"

sylware 4y ago

godot has a c++ toxicity issue to solve for elf/linux game binaries, I did report to them the issue, and indeed, they reasonably cannot do anything, only the gcc devs (glibc devs should be safe now) can do something (or godot would have to move to good and plain C, or similar). Game binaries should be a set of elf binaries statically loading (elf dt_needed) only libdl, namely with only dlopen/dlsym(tls safe)/dlclose symbols (with the oldest version as possible, probably 2.2.5) in the elf dynsym section except the other symbols from those very distributed binaries. The pb is the static gcc libstdc++ (and to a lesser extent the gcc static libgcc) does not libdl anything from the C runtime, or even worse could link to glibc internal symbols. All those very symbols, will end up in the elf dynsym section of the distributed binaries with the versions from the glibc used at link time. Namely, if a user wants to run on a older glibc distro those binaries, since glibc devs have a versioning frenzy, it won't even load (and the reasons are often more planned obsolescence than anything else). Some must not forget that static linking won't do unless a full elf loader is in linked in, since xcb/(wayland is static)/libasound(pulseaudio,pipewire,jack,whatever is hidden behind the alsa api)/libxkbcommon(-x11)/vulkan/(GL) libs will have to be loaded from system. Godot, as mitigation, pushes the devs to link with a very, VERY old, glibc (a decade?). It provides "containers" for "building" with an old glibc, and for the devs not using those containers, the documentation is clear about the age of the glibc to link with. The reality is gcc c++ was never meant for binary-only distribution, just never.

account42 4y ago
> Game binaries should be a set of elf binaries statically loading (elf dt_needed) only libdl, namely with only dlopen/dlsym(tls safe)/dlclose symbols (with the oldest version as possible, probably 2.2.5) in the elf dynsym section except the other symbols from those very distributed binaries. That is not a requirement at all. There is nothing wrong with linking against libc or other glibc libraries as long as you compile agianst the oldest version you want to support. Picking random version of glibc symbols makes no sense as they have absolutely no guarantee of being ABI-compatible, hence the different symbol versions. But if you WANT to dynamically load everying in glibc for whatever reason you can always create your own stub that provides those symbols and thunks the calls through function pointers that you can fill on startup with whaever logic you want and then statically link that stub so that all libc/whatever calls use your stub instead. > Godot, as mitigation, pushes the devs to link with a very, VERY old, glibc (a decade?). It provides "containers" for "building" with an old glibc, and for the devs not using those containers, the documentation is clear about the age of the glibc to link with. That is the best solution. Note that this does not mean that the users will be using an old unpatched glibc, just that the old interfaces will be used, which are still maintained in newer glibc versions.

oifjsidjf 4y ago

One of the reason why I used Blueprints a lot in UE4 (despite being totaly at home and liking C++) is that iteration was much faster. Recompiling C++ was ok-ish with hot-reload, but each time I changed/added some header file or class/struct member I had to recompile the entire thing which meant restarting the entire Unreal Editor. During this wait time I often went online which broke my flow or productivity.

dunno7456 4y ago

Well written! Thanks for the team!

alexalx666 4y ago

its a shame they don't have more support for quickly building non-game UIs in their wonderful editor. Last time trying to create a simple app felt like dragging IB connects in XCode 5 years ago but less intuitive

krapp 4y ago
Once Godot 4 drops and GDExtension starts getting traction, that seems like a perfect use case for a plugin.

Hfmwodb 4y ago

Context: I’ve used Godot 3 and I have a fair bit of experience in several programming languages. I think this is a terrible idea, even though understand why they would want to drop support for it. I personally prefer typing out the logic, but I’ve seen some of these “let’s make a video game without writing code” videos, and it makes me sad that they don’t think it’s worth focusing on. I think this is going to make budding game developers choose some other engine (where they will become more comfortable and they’ll mostly stick to).

dkersten 4y ago

Godot’s visual scripting was very much an afterthought anyway. It was an alternative syntax for GDScript really, rather than something designed with a use case in mind. Visual scripting can be great, if it’s specifically designed to tackle certain tasks (eg why visual shaders tend to work great, or high level visual scripting). As an alternative to textual syntax, it’s not very good.