Looking forward to 4.1 where we hopefully get mobile support for C# .NET 6. Then it will be ahead of Unity at least in terms of C# support given they don't plan to move to it before somewhere 2025.
I haven't worked yet with Godot but once this comes around I will try to target our Unity code-base against Godot to see how it does.
But in any case I am happy that it is such an active project because we need the competition.
I actually started playing around with a 3D project in the latest 3.X version recently. While the 3D renderer in that version isn't excellent, I guess I could also just stick with it, due to how long that version has been around for and due to how stable it is. Migrating projects across major releases down the line can be a pain in any engine, though, as anyone who has tried migrating a project from an older Unity LTS to a newer release will probably attest to as well.
But hey, it's great that Godot has such long support even for the older releases and overall it's a pretty great engine, especially because of how lightweight it is! In addition, their GDScript language is pretty nice, and while I personally prefer C# (which you can use), the performance of GDScript isn't too bad either, as I recently checked: https://blog.kronis.dev/articles/porting-the-godot-lod-plugi...
Do people still have to use primarily their custom programming language for most work? That's my current understanding, is that the engine is primarily exposed to GDScript.
GDScript is the most tightly integrated into the Godot editor, but there are tonnes of language bindings that work just as well and call into the C++ API just the same. C# is officially supported and they just ported it in Godot 4 to use .NET 6 instead of Mono. I've also used the Typescript/Javascript module from a 3rd party in the past and it surprised me how good the dev experience was. I'd wager that most devs who want to use their preferred language with it are also probably people who don't rely too much on GUI tools and won't miss the few features that gdscript gets from being directly inside the editor.
> Do people still have to use primarily their custom programming language for most work? That's my current understanding, is that the engine is primarily exposed to GDScript.
> Seems like such a poor choice.
Why? It's performant for basic gamedev type things, has near zero call overhead, is integrated into the engine and it's incredibly easy to learn. It definitely beats Blueprints or something like Lua. And if you really want C# or something, it has that too.
I think that one of the aspects can be the fact that IDE support isn't quite there yet. Going to using Godot's built in text editor or to an external editor with GDScript plugin from something like JetBrains Rider with IntelliSense feels like a large step backwards.
Then again, many projects out there won't need advanced code analysis or refactoring capabilities, but personally I think that engines supporting C# (and JetBrains having plugins for Godot or Unity) is a great choice to give that additional flexibility to those that need it, as well as access to at least some of that already existing ecosystem with lots of libraries available. Oh, also, the docs having C# examples next to GDScript examples is great!
I don't see anyone writing a linear solver, or their own networking library in GDScript anytime soon, even though there have been some pretty great plugins for Godot in GDScript already, like the terrain plugin or the LOD plugin (which I ported to C#, link to my blog post is in another comment), both of which are portable and work pretty well.
> something like JetBrains Rider with IntelliSense feels like
JetBrains is a billion dollar company that ONLY makes tools lol... Of course they have a leg up.
> I don't see anyone writing a linear solver, or their own networking library in GDScript anytime soon
Wrong tool for the job. That's why GDExtension exists. That's why C# is integrated. Also Godot already has ENet networking integrated into the engine.
GDScript is an alternative to something like Blueprints for basic behaviours that only call engine functions, not a full replacement for real programming languages.
> GDScript is an alternative to something like Blueprints for basic behaviours that only call engine functions, not a full replacement for real programming languages.
Admittedly, that's a pretty blurry line and I'm not sure it's that easy to quantify what a "real" programming language is!
For most games out there, GDScript could indeed be all that's necessary and might be "real" enough to get things done and be a comfy experience. For others, they are more than happy to bring their own IDE and the knowledge, as well as the ecosystem for their more advanced needs!
While having an extension mechanism for the engine is pretty cool (here's an article: https://godotengine.org/article/introducing-gd-extensions) sometimes you want things to be as easy as just adding a script in the editor and opening it in your IDE of choice.
I think it's pretty cool that Godot mostly caters to all parties here!
Edit: I don't disagree with you, just saying that the wording could be improved, though I'm not sure how, exactly. Maybe "general purpose" vs "scripting" languages, rather than "real" languages?
> I don't disagree with you, just saying that the wording could be improved, though I'm not sure how, exactly. Maybe "general purpose" vs "scripting" languages, rather than "real" languages?
Fair enough. I mean, when I use Godot, I use GDSCript... I do like it. It's just not general purpose and I'm ok with that. It accomplishes what you need for most games. And GDExtension or C# are there when you need more...
But in any case I am happy that it is such an active project because we need the competition.