4 ms·

I'd argue it's better than Boo and better than Blueprints. Maybe even JavaScript, because JS has made itself very useful as time has passed but as a small scrip

I'd argue it's better than Boo and better than Blueprints. Maybe even JavaScript, because JS has made itself very useful as time has passed but as a small scripting language embedded in browsers it sucked. It's only benefits are native integration with the client, and guaranteed support in perpetuity, and it's easy to write, and easy to learn, and teach, it almost never surprises you in ugly ways (which is awesome), it comes with a good enough debugger, its library pretty much covers what you need to make your average indie game... But what did the romans... I mean, GDScript, ever do for us?

krapp 3y ago
It's like you believe GDScript is the only language for which any of these features are possible. Other languages are also easy to write, learn and teach. Integration with the client is an implementation, not language, issue. Support is a business issue. Debugger quality is orthogonal, and you can make a game in assembly if you want (Railroad Tycoon.)
- dandellion 3y ago
  Those are your words, not mine. The thread was talking about ditching GDScript in favour of C# and comparing it to other engine scripting languages. You want to go with the conversation on a trip to the mountains, you go alone.
  - krapp 3y ago
    You're being weirdly aggressive here, and you have yet to actually address any specific point I've made in any of my comments, much less defended your own, so I'm going to call it a night.
    - dpig_ 3y ago
      You've been just as weirdly hostile from the jump.
johnnyanmac 3y ago
>its library pretty much covers what you need to make your average indie game Hey, if GDScript could run my idea for a 3D Open hub Action RPG at 60fps with little concerns for performance, I'd have no issue. But alas, my desire for a proper binding or directly tapping into the c++ comes out of necessity, not some pride as a "real game developer". It's not impossible for GDScript to one day become the WebASM of Godot, but we both know that WebASM was, and still is, decades in the making. I imagine it's simply faster to forge a fast path API and let the slow path work for non-performance intensive games.

krapp 3y ago

It's like you believe GDScript is the only language for which any of these features are possible. Other languages are also easy to write, learn and teach. Integration with the client is an implementation, not language, issue. Support is a business issue. Debugger quality is orthogonal, and you can make a game in assembly if you want (Railroad Tycoon.)

dandellion 3y ago
Those are your words, not mine. The thread was talking about ditching GDScript in favour of C# and comparing it to other engine scripting languages. You want to go with the conversation on a trip to the mountains, you go alone.
- krapp 3y ago
  You're being weirdly aggressive here, and you have yet to actually address any specific point I've made in any of my comments, much less defended your own, so I'm going to call it a night.
  - dpig_ 3y ago
    You've been just as weirdly hostile from the jump.

johnnyanmac 3y ago

>its library pretty much covers what you need to make your average indie game Hey, if GDScript could run my idea for a 3D Open hub Action RPG at 60fps with little concerns for performance, I'd have no issue. But alas, my desire for a proper binding or directly tapping into the c++ comes out of necessity, not some pride as a "real game developer". It's not impossible for GDScript to one day become the WebASM of Godot, but we both know that WebASM was, and still is, decades in the making. I imagine it's simply faster to forge a fast path API and let the slow path work for non-performance intensive games.