Live data from Hacker News

Godot 4.0 will discontinue visual scripting

godotengine.org

41–50 of 113 posts

Re: Godot 4.0 will discontinue visual scripting

#41

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…

> The only thing I miss are static typing and refactoring tools.

... and a way to measure coverage of GdScript code.

Re: Godot 4.0 will discontinue visual scripting

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

Re: Godot 4.0 will discontinue visual scripting

#43

Earlier quoted context omitted.

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

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.

Re: Godot 4.0 will discontinue visual scripting

#44

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…

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.

Re: Godot 4.0 will discontinue visual scripting

#45
post #18
post #6

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

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

Re: Godot 4.0 will discontinue visual scripting

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

Re: Godot 4.0 will discontinue visual scripting

#47
post #20

Earlier quoted context omitted.

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.

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

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.

Re: Godot 4.0 will discontinue visual scripting

#48
Moving it to an extension seems like the sane thing to do!

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
Of course, personally I'm in the camp of people who want to use a general purpose language like C# for game programming due to its wider ecosystem, about which I've written here: https://news.ycombinator.com/item?id=32274504

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

Re: Godot 4.0 will discontinue visual scripting

#49

Earlier quoted context omitted.

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.

In the context of game engines, the former are much more relevant than the latter.

Re: Godot 4.0 will discontinue visual scripting

#50

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.

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

Post reply on HN