Live data from Hacker News

Godot 4.0 will discontinue visual scripting

godotengine.org

61–70 of 113 posts

Re: Godot 4.0 will discontinue visual scripting

#61
post #18

Earlier quoted context omitted.

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…

There are scripting languages integrations for Unreal done in form of plugins. For example: https://angelscript.hazelight.se/

Re: Godot 4.0 will discontinue visual scripting

#62

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.

Apparently AAA studios haven't got the memo.

Re: Godot 4.0 will discontinue visual scripting

#63

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

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.

Re: Godot 4.0 will discontinue visual scripting

#64

Earlier quoted context omitted.

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

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.

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.

Re: Godot 4.0 will discontinue visual scripting

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

Re: Godot 4.0 will discontinue visual scripting

#66

> 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 realize the complexity and give up soon.

Re: Godot 4.0 will discontinue visual scripting

#67

Earlier quoted context omitted.

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

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

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.

Re: Godot 4.0 will discontinue visual scripting

#68

Earlier quoted context omitted.

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

Re: Godot 4.0 will discontinue visual scripting

#69

Earlier quoted context omitted.

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

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.

Post reply on HN