Godot 4.0 will discontinue visual scripting(godotengine.org)
godotengine.org
Godot 4.0 will discontinue visual scripting
https://godotengine.org/article/godot-4-will-discontinue-visual-scripting
112 comments
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.
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 think a lot of people assume that they won't like a custom language (I did too) but the reality is when you start using GDScript it just isn't such an issue.
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.
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.
> 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.
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).
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).
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
There are one or two things that are harder to find but they are few and far between
Yet the default Godot download is a 'standard edition' without Mono support?
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?
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?
After looking around the web, it seems the version that contains the .NET (mono) is about twice the size. It looks like the Godot team maintains two package versions simply to avoid bloat if you do not require that functionality.
Godot's system for exporting games/apps/projects as binaries is that the same codebase/build system that generates the editor binary (the Godot "tools") can be built with the "tools" parts omitted, and the resulting non-tools release binary is bundled up with your project scripts/resources as the binary API for your exported game.
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.
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.
I wholeheartedly agree, its one of the things I like the least about Godot. That being said, I used Unity for about 8 years, 2 years ago I switched to Godot and never looked back. I think I tried Unity again once, for a few hours, then went back again. Its also worth noting that I prefer ECS as a programming style, which of course Unity uses and Godot doesn't, and yet still I'm using Godot.
It really is that good of an engine. I have my issues, plenty of them even, but for the most part its a joy.
It really is that good of an engine. I have my issues, plenty of them even, but for the most part its a joy.
[deleted]
Bevy is in Rust, made by a former Godot contributor.
Apparently they want to make Bevy more like Godot with a full GUI editor, rather than a framework, which for me personally is a real shame. There aren't that many really good modern game frameworks, and Bevy is the only one that uses Rust natively (Amethyst is shut down, Raylib and SDL don't count as they have bindings for literally everything, I wouldnt be suprised to find a COBOL binding for raylib). Otherwise, its fantastic and would highly recommend.
>I wouldnt be suprised to find a COBOL binding for raylib
I was curious and found this
https://github.com/Martinfx/Cobol/tree/master/OpenCobol/Game...
I was curious and found this
https://github.com/Martinfx/Cobol/tree/master/OpenCobol/Game...
> 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
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.
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.
I have never encountered such a person. Someone who was learning to program who referenced the 'metaverse' as a motivator for learning. I have found that the most common impetus is still gaming.
Glad to hear you had a similar experience. For me the 90s PC hardware era was somewhat of a let-down. On the home-computer graphics and sound were first class citizens. They were integral to the experience and even though you had to do it in assembly I found it logical and easy. Moreover, when you got it to work, it worked - always and everywhere. After all every device of a particular model was the same.
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!
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!
>Today it's probably the 'metaverse' that converts consumers into programmer
Anecdotally, it seems more kids are converted to programming through Minecraft or Roblox now
Anecdotally, it seems more kids are converted to programming through Minecraft or Roblox now
Metaverse like that Facebook VR game, or?
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
[2] https://godotengine.org/article/introducing-gd-extensions
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
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
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
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.
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
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
I'd be starting a new game from scratch since my last few game dev forays have been Unity so not having mobile support at launch is a non-factor for me (and mind you I dunno how crazy making cross compat games between PC and mobile even is so I may not care for a good while).
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!
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!
> The only thing I miss are static typing and refactoring tools.
... and a way to measure coverage of GdScript code.
... and a way to measure coverage of GdScript code.
> because there are no generic collections.
Not true, in Godot 4 you can do `Array[Node]` to have a typed array of nodes, replace Node with your type of choice.
Not true, in Godot 4 you can do `Array[Node]` to have a typed array of nodes, replace Node with your type of choice.
Wow, I completely missed that one! [1]
Thanks for pointing that out. You just improved my life :)
[1] https://godotengine.org/article/gdscript-progress-report-fea...
Thanks for pointing that out. You just improved my life :)
[1] https://godotengine.org/article/gdscript-progress-report-fea...
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.
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.
Visual scripting is very good for expressing high-level logic, especially when there’s some kind of delay involved: this happens, then when it’s done, one or more other things happen.
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.
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.
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.
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.
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.
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.
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
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
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.
> 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.
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.
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.
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.
Epic is working on verse script now. Even they realized visual scripting is not the best way to do development. It's very limiting. I was much happier with UE when it had unrealscript. I still do game development on the old engines, but I don't like doing anything with the new engines that force you into c++ or blueprints. Code is simply more expressive than flow charts.
If Unreal got proper scripting language support, I'd seriously consider giving it another go. I'd rather they go the Unity approach than the Godot approach and use a real-world language (C# is used outside Unity of course, GDScript is only used in Godot, though it does have bindings), but I'll take what I can get, clearly as I use Godot rather than Unity.
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
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
I wonder if building a custom language is a simpler way to optimize stuff later on?
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 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#.
I'm sure it is, no doubt its easier to pick an existing language than build a whole new one.
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.
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.
There are scripting languages integrations for Unreal done in form of plugins. For example: https://angelscript.hazelight.se/
I guess the problem with plugins is that you can only ever get a small subset of the community. For example, if I wanted to figure out how to create a new object instance in Unreal, I'd have to look pretty hard for Angelscript specific examples. Whereas if its native, presumably it'd reach a lot more people and the community would be larger for it (not always the case, but a fairly safe assumption)
I really liked unrealscript.
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.
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 found its use of inheritance very confusing; could be quite hard to figure out what something does exactly because it could be in one of the 6 parent classes. The experience turned me off from OOP for many years (later nuanced to just inheritance rather than all of OOP).
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).
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).
That is just Unreal Engine in general, UnrealScript just exposed the C++ classes. But UE's C++ classes have very deep hierarchies even in UE5 and many classes have tons of methods.
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.
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.
Where did you read about verse? Last I heard about it was Carlos talking about it in a video a few years ago. I haven't heard anything since.
They seem to be designing it to launch with their special Fortnite version of the Unreal Editor which is supposed to launch sometime this year.
It’s not text but there’s a podcast with Simon Peyton Jones (Haskell person) talking about his new job at Epic working on verse. Starts around 50s in:
https://podcasts.apple.com/us/podcast/the-haskell-interlude/...
https://podcasts.apple.com/us/podcast/the-haskell-interlude/...
I still find it perplexing that Unreal ditched Unreal Script in favor of Blueprints and full C++.
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?
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.
The problem is that at least until very recently, That subset of people have not been Epic's target market. UE had been targeting larger studios, and in that space, UnrealScript was largely a hindurance.
This is it for me. GDscript allows for quick prototyping and structural changes without fuss. If I really need it I could outsource some GDExtension (formerly GDNative) development.
The error is believing engineers can't draw and artists can't code. Skill is not a zero sum game.
I'm working with media artists and the very best way to make them flee is to tell them that they have to use the keyboard. Yes, there's the occasional geek but the overwhelming majority really doesn't like it - I'm not even talking about coding (I saw people get up and leave when showing code stuff in art contexts), just for instance having to use some keyboard shortcuts to do something is already too much in many cases, things have to be doable through mouse interaction exclusively.
every AAA game artist I've ever worked with uses extensive keyboard shortcuts in Photoshop, Maya, 3DSMax, Blender, Zbrush, etc... Tons.
> AAA game artist
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.
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.
In the context of game engines, the former are much more relevant than the latter.
I've been a C++ developer for 20 years, and when I was playing around with UE4 back when it was first released, I found both options to be extremely clunky.
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.
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.
I wonder how much it is because Godot a type of developer who is probably more at home in code.
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
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
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.
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.
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)
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)
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.
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.
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 [2] https://enso.org/docs/syntax
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
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
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
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.
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.
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.
Yep, I've been on the other end, developing such a tool, with similar findings.
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.
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.
You can put IDs in the nodes and order by ID, but you still have to be a little careful in how you do that or people can add/delete the same node and create lots of changes too.
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.
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.
Yep, in my case it was a storytelling tool for visual novel games, so there wasn't much data to pass around, most nodes were either modal interactions or affecting changes upon the game world. It's also a pretty constrained domain so a lot of the bookkeeping could be done internally rather than needing to be exposed to the narrative designer. A lot of the problems you mention just didn't need to exist.
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.
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.
I agree with that, a few specialized types that are understood by all your nodes can be really helpful in a more limited domain. And it's definitely better suited to relatively simple things where it gives you a sort of high-level flowchart and the nitty-gritty details can happen within the nodes themselves.
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.
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.
> Ive only poked at godot, is there a reason that GDscript is so dominant?
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.
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.
GDScript is adequate. The only real benefit it has is integration with Godot itself, but I can't imagine anyone preferring to use it as a general purpose language.
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.
If they want visual editing they should look into old Game Maker or Construct 3 for how to do newbie friendly visual scripting.
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.
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!
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 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.
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.
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.
Moving it to an extension seems like the sane thing to do!
That way:
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...
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...
How do visual scripting systems like Unreal Blueprints handle version control and merging of changes from multiple people?
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.
With Godot's VisualScript, it's not handled at all. The files are saved as a binary format and cannot be merged, even manually.
Does this mean they are also removing the VisualShader as well? Or purely the scripting part?
It seems likely that enough people use VisualShader to justify its existance. It is also common to define shaders visually, for instance in Blender.
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.
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.
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.”
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.
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.
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.
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.
> 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_...
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.
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 a dead end for serious branching logic, which most game logic will collide with on the cpu.
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.
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.
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.
It's inferior to real programming in every other way though. Writing code to generate node graphs (eg. for Blender materials) is particularly hellacious.
> 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.
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.
I said "writing code to generate node graphs". If you have some example of nice code for this I'd like to see it. Everything I've seen is opaque (unclear what the node graph will look like), basically write-once, and has trouble getting the placement of the nodes correct enough even to not overlap, let alone look nice.
(Also it doesn't eliminate type errors, sockets have a type after all.)
(Also it doesn't eliminate type errors, sockets have a type after all.)
> (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.
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.
Isn't that what you call a type error?
> Isn't that what you call a type error?
Obviously no, since you can't connect incompatible outputs with inputs at first place.
Obviously no, since you can't connect incompatible outputs with inputs at first place.
On the contrary, it is the foundation of programming, how digital circuit design applications work.
If anything they make quite clear when people write spaghetti code, instead of proper modules.
If anything they make quite clear when people write spaghetti code, instead of proper modules.
Apparently AAA studios haven't got the memo.
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).
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).
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.
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"
this is a fair comparison of GDScript, C# and Visual Script, and the conclusion was "visual script is good for no one"
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.
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.
> 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.
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.
This is clearly what I was saying, missing out the "internal" glibc symbols issue due to the static libstdc++ (I have not got into the details of those symbols, they may be benign since lazy binding is the default), and I would rather favor a "less worse" than "best" terminology to be fair, since it is still causing issues with games, the major users of the binary-only distribution.
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".
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".
huh, i wonder it is possible to just do visual editor on top of gdscript instead similar to https://developers.google.com/blockly/
[deleted]
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
Once Godot 4 drops and GDExtension starts getting traction, that seems like a perfect use case for a plugin.
Well written! Thanks for the team!
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.