3 ms·

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

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

KronisLV 4y ago
> Why? 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. That said, Lua is also great!
- Mikeb85 4y ago
  > 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.
  - KronisLV 4y ago
    > 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 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?
    - Mikeb85 4y ago
      > 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...

KronisLV 4y ago

> Why? 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. That said, Lua is also great!

Mikeb85 4y ago
> 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.
- KronisLV 4y ago
  > 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 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?
  - Mikeb85 4y ago
    > 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...