Godot 4.0 will discontinue visual scripting
godotengine.org
godotengine.org
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.
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.
I was curious and found this
https://github.com/Martinfx/Cobol/tree/master/OpenCobol/Game...
One of the huge advantages of GDScript is how deeply in integrates with the engine and handles high level concepts, coupled with the node system you don't need to write that much code. Plus its a simple language (there's no need for 'javascript - the good parts' for gdscript).
The godot approach with GDScript and C++ is very much like Python and C++ - write in the high level scripting language and build C++ components when you need more complexity and performance. The scripting language becomes the user interface of the low level parts.
There are one or two things that are harder to find but they are few and far between
What's the reasoning behind the two separate builds? Is it just about build/download size, or are there potential licensing issues with Mono or something?
The general philosophy for Godot's build/compilation system is that most things are just linked statically, and features and modules can be turned on and off via build flags, so that they can be as portable as possible - indeed it's usually pretty painless and quick to export a game to a binary from the editor on most platforms because of this.
With Mono there are 2 sticking points that make this a bit more difficult - first is that this non-tools binary has to bundle the Mono runtime with it to be portable, this adds a bunch of bloat, and Godot's style has always been to be as light as possible. For mobile apps for example, that extra ~40mb of stuff can be a real problem.
Additionally, the development machine has to have a fairly modern dotnet SDK installed (ideally .NET 6 SDK + dotnet cli these days) as well as the app host targeting packs in order for the mono-enabled editor binary to run at all (as it contains some CLR/native interop code and nuget packages for the editor tools to copy into your project, etc that fails without these things). So the export template (the non-tools godot API binary) with Mono can't be understood by the editor tools without Mono enabled.
Recently direct .NET 6 interop support has replaced the Mono integration in Godot 4, and this might in the future change the above - since it will be able to use the new AOT stuff to publish exported games in a more direct way. It's definitely a stated intention to eventually ship just one engine binary for everything, but it's still a way off happening yet, maybe in Godot 4.1 or 4.2.
As a professional developer, yes, I love seeing popular languages I know. When you build a product that includes a programming language, you find out maintaining and expanding the language is a herculean effort, and so I can understand from just the financial perspective why Unity switched to C#.
As a Dad, what the OP was saying is right - Godot's language, while non-standard is much more approachable for a child than C++ (or most other popular general purpose languages).
It really is that good of an engine. I have my issues, plenty of them even, but for the most part its a joy.
Same for me, but in the 90s. Back then, games push PC hardware forward and made a lot of people code.
Today it's probably the 'metaverse' that converts consumers into programmers. Sadly, many think that programming is cool all the time(thanks Hollywood), don't realize the complexity and give up soon.
On the PC everything was hard and clunky. x86 assembly still doesn't make much sense to me and suffering through all the VGA adapter chaos (bitplanes, yuk) has left lasting damage;-)
Luckily in the 90s there was Linux and I started a studying at the university where we had workstations. Our SGI Indies and O2s were more to my liking.
At least this is how I made it through the 90s without losing the fun of programming. And then came the Internet and www and everything was more exciting then ever!
Anecdotally, it seems more kids are converted to programming through Minecraft or Roblox now
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
[2] https://godotengine.org/article/introducing-gd-extensions
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
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!
Appreciate pointing to it being pulled into master though, increases my likelyhood of trying Godot again as I've been working in dotnet 6 more and more on personal stuff of late!
... and a way to measure coverage of GdScript code.
Not true, in Godot 4 you can do `Array[Node]` to have a typed array of nodes, replace Node with your type of choice.
Thanks for pointing that out. You just improved my life :)
[1] https://godotengine.org/article/gdscript-progress-report-fea...
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.
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.
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.
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
This sort of thing is much clearer and simpler in a visual language than any kind of callback- or await- hell and the pattern is everywhere in gameplay logic.
The big problem with visual languages is that the toolset needs to be excellent to compare with text-based languages (Blueprint nearly is, Godot’s visual scripting isn’t).
Also it’s a completely different programming paradigm and programmers used to text-based languages tend to HATE them. If you think how many programmers are put off LISP because of the brackets, this is more of a culture shock - and the more experienced a programmer you are, the worse it seems to be.
> 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.
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.
those are salaried people who have to do a job and get paid for it each month, the artists I work with are independent artists who do stuff like art installations, etc. on their name. It's really really not the same mindset.
There's a lot to be said for C#, at the very least. I know a ton of not-very-technical people who have learned enough C# to write simple Unity games.
Part of my love was how both object State and networking were first class features of the language.
You could override a function based on "is the current object in the idle or shooting" state TRIVIALLY.
I was also very much a beginner back in the late 90s/early 00s (my only previous experience was BASIC), so I'd probably struggle less now, but from what I recall it definitely overdid it on the inheritance (which, to be fair, was still fairly new back then).
In general UE often feels like its programmers took all the best practices and then ignored every single one of them - which, considering how popular the engine is and for how long it had been around (the codebase started in the early/mid-90s), is a good indicator how much that stuff actually matter in practice.
https://podcasts.apple.com/us/podcast/the-haskell-interlude/...
As it stands, picking up blueprints feels like I have to learn a whole new system which will go to waste if I decide not to stick with Unreal, and C++ seems like it'd be a pain to work with.
Edit: Forgot Godot had C# support. It still doesn't feel as "first-class" as GDScript, but its certainly more closely integrated than bindings, so maybe something to consider. Also, whilst I generally prefer a single language being tied to a single tool (trying to learn Raylib taught me this, where every example you find is in a different language), its nice knowing I can use C# without being locked into Microsoft
For example, Unity uses C# but then you need either all of Mono at runtime or something like IL2CPP to compile to C++. And then eventually that compiler is constantly needing to keep up with language releases and new features. Or in .Net’s case new languages like F#.
For me however, the benefits of an existing language outweigh the costs. If Godot were to use Python for example, you'd gain the full benefit of pip alongside it. If you use C# with Godot, I know you can use Nuget. I'd also personally rather a more performant language than one thats easier to write, but thats personal preference.
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
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.
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)
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 [2] https://enso.org/docs/syntax
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
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.
Though for serialization it really needs to use a flat-ish format where each node is _at least_ on its own separate line, and sorted using some stable ordering, as otherwise there will be lots of spurious diffs in source control.
I think YAML works out pretty good as a serialization format because it doesn't create a lot of overhead unlike, say, XML which is ugly for that.
You also want to have clear standards for how you pass parameters around (some use a dictionary object passed implicitly), standards for types, good ways to do common data conversions, etc.
It's probably better when you have stronger ideas about how things should be done for a given system than as a mess of boxes trying to be a general programming language.
In terms of how it was implemented (C#, for context), every possible node had to be a pure object (no internal mutation) with an asynchronous "run" method. This "run" method receives the game world as a parameter (Basically just a service locator. Services hold the mutable data).
At design time, we would instantiate the nodes and use reflection to display their fields to the designer, using specific widgets if the field was a pointer to another node. The design tool also kept an unique identifier for each node, and sorted by those on serialization. We used an ini-like custom format (hadn't heard of TOML at the time or would have probably gone with that) so that there was no nesting of nodes. Instead, fields that point to other nodes would just be serialized as the target's ID. When deserializing, we would have two passes, one reads the story file into an intermediate representation, so that every node is "known", and another to apply the actual properties (which can include references to out of order nodes).
But yes, as you mention, it is a system very fit for the domain, with some choices that don't make as much sense generally. Which is part of why I see that project as successful, and kind of demonstrates how much work goes into making a good visual scripting tool.
Otherwise you get a lot of low level logic of type conversion or other small details instead of a very high level view of the logic. It also helps if you can box up existing flows into a single black box as it were, since that can help you reuse code.
If you do have complex nodes that let you make it into a simplified flow chart of what the application is doing and that allows you to look inside the nodes which might have a more complex, specialized configuration, those end up being a lot nicer to program in than in something that's trying to be a general programming language with lots of low-level nodes dealing with trivial things like data conversion.
GDScript is excellent. I was a huge skeptic of it at first - in fact, if you dig through my reddit account I wrote a huge screed about why it could never succeed when it was first announced like 5+ years ago. The Godot team totally proved me wrong - GDScript is really really good. It's super productive to work in - you can bang out features super quickly.
If they want visual editing they should look into old Game Maker or Construct 3 for how to do newbie friendly visual scripting.
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 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.
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
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-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/d...
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.
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.
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_...
Another popular project is animation nodes
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.
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.
(Also it doesn't eliminate type errors, sockets have a type after all.)
If you used any significant Node based programming system, then you know you can't randomly plug sockets from different types unless that socket explicitly supports type conversion.
Obviously no, since you can't connect incompatible outputs with inputs at first place.
If anything they make quite clear when people write spaghetti code, instead of proper modules.
Nodes are great for parallel work on the gpu, shaders, animations, ect which is why you see it primarily in artistic tools.
This is treated like it is more controversial than it is, people who've tried to do real branching logic on blueprints/visual code have seen it die.
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).
this is a fair comparison of GDScript, C# and Visual Script, and the conclusion was "visual script is good for no one"
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.
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.
We all know the only way to remove properly this "dirt", is too aim "explicit" (libdl) than "implicit" (elf dynsym section), which it seems to become the "normality" in many areas, like smp locking and high level syntax (was a target for python syntax).
And that would open the road for alternative elf/C runtime... ofc glibc zealots won't like that at all, expect a lot of resistance and "mauvaise foi".