Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Godot 4.0 will discontinue visual scripting

godotengine.org

Post reply on HN
Print view View original

71–80 of 113 posts

Re: Godot 4.0 will discontinue visual scripting

#71

Post by Supermancho »

milansuk wrote: post #66
weinzierl wrote: post #51

> Godot ended up allowing a lot of its users to be a tool to learn programming instead. This, so much. After careful deliberation I chose Godot and GDScript as a follow-up after Scratch for my kid to learn programming. Godot and GDScript are great, because: - Easy enough to pick up after Scratch. GDScript is easy to learn yet powerful enough to teach most relevant programming concepts and it even is able to make real…

> 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 r…

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.

Re: Godot 4.0 will discontinue visual scripting

#72

Post by solardev »

milansuk wrote: post #66
weinzierl wrote: post #51

> Godot ended up allowing a lot of its users to be a tool to learn programming instead. This, so much. After careful deliberation I chose Godot and GDScript as a follow-up after Scratch for my kid to learn programming. Godot and GDScript are great, because: - Easy enough to pick up after Scratch. GDScript is easy to learn yet powerful enough to teach most relevant programming concepts and it even is able to make real…

> 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 r…

Metaverse like that Facebook VR game, or?

Re: Godot 4.0 will discontinue visual scripting

#73

Post by kroltan »

Natsu wrote: post #12
kroltan wrote: post #7

Earlier quoted context omitted.

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 p…

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.

Re: Godot 4.0 will discontinue visual scripting

#74

Post by sylware »

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.

Re: Godot 4.0 will discontinue visual scripting

#75

Post by Antshockey »

bluescrn wrote: post #57
weinzierl wrote: post #51

> Godot ended up allowing a lot of its users to be a tool to learn programming instead. This, so much. After careful deliberation I chose Godot and GDScript as a follow-up after Scratch for my kid to learn programming. Godot and GDScript are great, because: - Easy enough to pick up after Scratch. GDScript is easy to learn yet powerful enough to teach most relevant programming concepts and it even is able to make real…

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 bes…

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

Re: Godot 4.0 will discontinue visual scripting

#76

Post by LVB »

crispyalmond wrote: post #2

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

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.”

Re: Godot 4.0 will discontinue visual scripting

#77

Post by indymike »

bluescrn wrote: post #57
weinzierl wrote: post #51

> Godot ended up allowing a lot of its users to be a tool to learn programming instead. This, so much. After careful deliberation I chose Godot and GDScript as a follow-up after Scratch for my kid to learn programming. Godot and GDScript are great, because: - Easy enough to pick up after Scratch. GDScript is easy to learn yet powerful enough to teach most relevant programming concepts and it even is able to make real…

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 bes…

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

Re: Godot 4.0 will discontinue visual scripting

#78

Post by bluescrn »

Antshockey wrote: post #75
bluescrn wrote: post #57

Earlier quoted context omitted.

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 bes…

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

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?

Re: Godot 4.0 will discontinue visual scripting

#79

Post by runevault »

JamesBaxter wrote: post #29
zubspace wrote: post #21

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…

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

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.

Re: Godot 4.0 will discontinue visual scripting

#80

Post by account42 »

sylware wrote: post #74

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…

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

Post reply on HN