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 the polish it needed, and how much is because gdscript is a superior approach.
While looking into new engines recently I bailed on Unreal because all the docs and tutorials push towards Blueprint. I'd happily use C++ over Blueprint but everything is pushing Blueprint hard to the point I just moved on. Been looking at Godot lately and I really like it and if I need something more than GDScript provides there are bindings to GDNative. I think for some people Visual scripting is probably nice but for me it's an inscrutable mess of flow charts that's way more difficult to use, debug, build understanding of quickly, etc.
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
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.
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)
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 from what I recall it definitely overdid it on the inheritance (which, to be fair, was still fairly new back then).
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.
Engineers wants C++, scripters and artists wants Visual Scripting. Seems like an obvious choice to make everyone happy instead of trying to find a middle ground where nobody is?
I think Godot shows there's a clear subset of people (generally indie developers) who are fine with the middle ground of a proper scripting language instead of either extreme. It's why languages like Lua are still fairly popular when the option to use it exists.
The problem is that at least until very recently, That subset of people have not been Epic's target market. UE had been targeting larger studios, and in that space, UnrealScript was largely a hindurance.
This is it for me. GDscript allows for quick prototyping and structural changes without fuss. If I really need it I could outsource some GDExtension (formerly GDNative) development.
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 cases, things have to be doable through mouse interaction exclusively.
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.
I've been a C++ developer for 20 years, and when I was playing around with UE4 back when it was first released, I found both options to be extremely clunky.
There's a lot to be said for C#, at the very least. I know a ton of not-very-technical people who have learned enough C# to write simple Unity games.
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 the polish it needed, and how much is because gdscript is a superior approach.