3 ms·

And Godot 4 is coming up as a significant player. Either GDScript or Python or any related interfaces (Swift?) could be the next big language for game developme

And Godot 4 is coming up as a significant player. Either GDScript or Python or any related interfaces (Swift?) could be the next big language for game development.

citizenkeen 4y ago
A coworker joked the other day that GDScript will probably onboard a whole slew of C# developers. 1. Learn GDScript 2. Grow frustrated with duck typing 3. Learn that you can switch to C# and still use Godot Godot 4 having two first class languages is such an odd paradigm.
- Macha 4y ago
  > Godot 4 having two first class languages is such an odd paradigm. Unity used to have 3. Boo (Python inspired), UnityScript (JS inspired) and C#. I'd say for a time UnityScript was even the most popular (back in the days they still called Boo and UnityScript Python and Javascript). But over time they've whittled it down to just C# as the audience switched from hobbyists prioritising accessibility to studios prioritising performance and maintainability. Unreal also used to have UnrealScript, dropped it, but seems to be trying again with Verse.
- andrewmcwatters 4y ago
  I'm amazed at the futility of Godot's labor allocation sometimes. GDScript is a dead end, and they're making their own physics engine? What a waste of time and effort when there are other categories that game developers care more about.
  - follower 4y ago
    > I'm amazed at the futility of Godot's labor allocation sometimes. In terms of C#, they did get funding of $USD24,000 for implementing it: https://godotengine.org/article/introducing-csharp-godot/#acknowledgements https://godotengine.org/article/introducing-csharp-godot/#ac... And while I'm no fan of the language I do see the strategic value in potentially providing a migration path from Unity. > GDScript is a dead end, Do you mean in terms of it being a "single use" language? > and they're making their own physics engine? I think it's significant to note that in both cases--creating a new language & a "new" physics engine--it wasn't necessarily their first choice. As they've noted[0], they first used Lua & tried Python before creating GDScript. And for Godot 3.0 they moved to using the 3rd party Bullet Physics engine[1] but decided for 4.0 to move the focus back to the custom physics engine--in part because Bullet had "a shift of focus...away from game development". And in both cases they're developed the support in a modular fashion so that the defaults can be replaced (e.g. by Rust/Python/Nim and Bullet/Jolt) so everyone can be unhappy...or happy if they replace it by something they like, I guess. :D FWIW I don't think anyone particularly wants to learn a single use language but the number of comments I've seen that go "Ugh, I didn't want to learn or use GDScript but it turns out I like it" is non-zero. And, in my case, I can't argue with the results, even in GDScript for 3.0 the differences between Python & GDScript weren't huge & via the Editor integration it's just so easy to write...for the most part. (There's a reason I've spent so much time writing/using GDScript/FFI-bindings for pre-compiled library binaries--cos I'd rather write GDScript than any compiled language. :) ) With the improvements in gradual typing, optimization & quality-of-life features that come with GDScript for 4.0 it's even better. (As languages go I see Rust & GDScript actually make a nice pairing to move between--in part due to the nice `match`-based features in both.) Also, they did just spend four years developing a Vulkan-based renderer, which does seem like something game developers care about. Do you have any examples of what categories you see game developers caring more about that 4.0 hasn't improved on? Godot as an engine & a project is definitely not without its faults but I don't think "futility" and "waste of time and effort" are particularly fair/generous characterizations of the labor allocation. [0] https://docs.godotengine.org/en/4.0/about/faq.html#what-were-the-motivations-behind-creating-gdscript https://docs.godotengine.org/en/4.0/about/faq.html#what-were... [1] https://godotengine.org/article/godot-30-switches-bullet-3-physics/ https://godotengine.org/article/godot-30-switches-bullet-3-p... (See note on page re: 4.0.)
- follower 4y ago
  > 2. Grow frustrated with duck typing FWIW GDScript has had optional/gradual typing since Godot 3.1[1] with significant improvements implemented for Godot 4.0[2]. Also, I've seen a non-zero number of people who were used to C# comment that to their surprise they actually liked using GDScript. :) So, you know, maybe it's C# that will be the onboarding path for GDScript developers instead. :D [1] <https://godotengine.org/article/optional-typing-gdscript/ https://godotengine.org/article/optional-typing-gdscript/> [2] <https://godotengine.org/article/gdscript-progress-report-feature-complete-40/ https://godotengine.org/article/gdscript-progress-report-fea...>

And Godot 4 is coming up as a significant player. Either GDScript or Python or any related interfaces (Swift?) could be the next big language for game development.

citizenkeen 4y ago

A coworker joked the other day that GDScript will probably onboard a whole slew of C# developers. 1. Learn GDScript 2. Grow frustrated with duck typing 3. Learn that you can switch to C# and still use Godot Godot 4 having two first class languages is such an odd paradigm.

Macha 4y ago
> Godot 4 having two first class languages is such an odd paradigm. Unity used to have 3. Boo (Python inspired), UnityScript (JS inspired) and C#. I'd say for a time UnityScript was even the most popular (back in the days they still called Boo and UnityScript Python and Javascript). But over time they've whittled it down to just C# as the audience switched from hobbyists prioritising accessibility to studios prioritising performance and maintainability. Unreal also used to have UnrealScript, dropped it, but seems to be trying again with Verse.
andrewmcwatters 4y ago
I'm amazed at the futility of Godot's labor allocation sometimes. GDScript is a dead end, and they're making their own physics engine? What a waste of time and effort when there are other categories that game developers care more about.
- follower 4y ago
  > I'm amazed at the futility of Godot's labor allocation sometimes. In terms of C#, they did get funding of $USD24,000 for implementing it: https://godotengine.org/article/introducing-csharp-godot/#acknowledgements https://godotengine.org/article/introducing-csharp-godot/#ac... And while I'm no fan of the language I do see the strategic value in potentially providing a migration path from Unity. > GDScript is a dead end, Do you mean in terms of it being a "single use" language? > and they're making their own physics engine? I think it's significant to note that in both cases--creating a new language & a "new" physics engine--it wasn't necessarily their first choice. As they've noted[0], they first used Lua & tried Python before creating GDScript. And for Godot 3.0 they moved to using the 3rd party Bullet Physics engine[1] but decided for 4.0 to move the focus back to the custom physics engine--in part because Bullet had "a shift of focus...away from game development". And in both cases they're developed the support in a modular fashion so that the defaults can be replaced (e.g. by Rust/Python/Nim and Bullet/Jolt) so everyone can be unhappy...or happy if they replace it by something they like, I guess. :D FWIW I don't think anyone particularly wants to learn a single use language but the number of comments I've seen that go "Ugh, I didn't want to learn or use GDScript but it turns out I like it" is non-zero. And, in my case, I can't argue with the results, even in GDScript for 3.0 the differences between Python & GDScript weren't huge & via the Editor integration it's just so easy to write...for the most part. (There's a reason I've spent so much time writing/using GDScript/FFI-bindings for pre-compiled library binaries--cos I'd rather write GDScript than any compiled language. :) ) With the improvements in gradual typing, optimization & quality-of-life features that come with GDScript for 4.0 it's even better. (As languages go I see Rust & GDScript actually make a nice pairing to move between--in part due to the nice `match`-based features in both.) Also, they did just spend four years developing a Vulkan-based renderer, which does seem like something game developers care about. Do you have any examples of what categories you see game developers caring more about that 4.0 hasn't improved on? Godot as an engine & a project is definitely not without its faults but I don't think "futility" and "waste of time and effort" are particularly fair/generous characterizations of the labor allocation. [0] https://docs.godotengine.org/en/4.0/about/faq.html#what-were-the-motivations-behind-creating-gdscript https://docs.godotengine.org/en/4.0/about/faq.html#what-were... [1] https://godotengine.org/article/godot-30-switches-bullet-3-physics/ https://godotengine.org/article/godot-30-switches-bullet-3-p... (See note on page re: 4.0.)
follower 4y ago
> 2. Grow frustrated with duck typing FWIW GDScript has had optional/gradual typing since Godot 3.1[1] with significant improvements implemented for Godot 4.0[2]. Also, I've seen a non-zero number of people who were used to C# comment that to their surprise they actually liked using GDScript. :) So, you know, maybe it's C# that will be the onboarding path for GDScript developers instead. :D [1] <https://godotengine.org/article/optional-typing-gdscript/ https://godotengine.org/article/optional-typing-gdscript/> [2] <https://godotengine.org/article/gdscript-progress-report-feature-complete-40/ https://godotengine.org/article/gdscript-progress-report-fea...>