huh, i wonder it is possible to just do visual editor on top of gdscript instead similar to https://developers.google.com/blockly/
[deleted]
Godot 4.0 will discontinue visual scripting
81–90 of 113 posts
Re: Godot 4.0 will discontinue visual scripting
#82One 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.
Re: Godot 4.0 will discontinue visual scripting
#83> 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…
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!
Re: Godot 4.0 will discontinue visual scripting
#84A 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 fo…
That center circle is actually the sun approaching the horizon, because they are "sunsetting" Visual Scripting.
yeh I get thats what they were going for, I just thought it looked nice as an unlikely potential new logo
Re: Godot 4.0 will discontinue visual scripting
#85Earlier quoted context omitted.
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…
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#.
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.
Re: Godot 4.0 will discontinue visual scripting
#86Earlier quoted context omitted.
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/
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)
Re: Godot 4.0 will discontinue visual scripting
#87> 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 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.
Re: Godot 4.0 will discontinue visual scripting
#88Earlier 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…
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.
Re: Godot 4.0 will discontinue visual scripting
#89Visual 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 i…
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.
Re: Godot 4.0 will discontinue visual scripting
#90Seems 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? 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 su…
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.