Live data from Hacker News

Godot 4.0 will discontinue visual scripting

godotengine.org

91–100 of 113 posts

Re: Godot 4.0 will discontinue visual scripting

#91
post #42

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

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

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

Re: Godot 4.0 will discontinue visual scripting

#92

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

[deleted]

Re: Godot 4.0 will discontinue visual scripting

#93

Earlier quoted context omitted.

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?

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.

Re: Godot 4.0 will discontinue visual scripting

#94

Earlier quoted context omitted.

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.

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

Re: Godot 4.0 will discontinue visual scripting

#95
post #40

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

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.

Re: Godot 4.0 will discontinue visual scripting

#96

Earlier quoted context omitted.

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…

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

Re: Godot 4.0 will discontinue visual scripting

#97

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

>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

Re: Godot 4.0 will discontinue visual scripting

#98

Earlier quoted context omitted.

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

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!

Re: Godot 4.0 will discontinue visual scripting

#100
post #73
post #12

Earlier quoted context omitted.

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.

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.

Post reply on HN