5 ms·

to somehow who's used it extensively - was a DSL really necessary? I find the whole idea of a separate language for just developing interactive media a bit off

by geokon 7y ago

to somehow who's used it extensively - was a DSL really necessary? I find the whole idea of a separate language for just developing interactive media a bit off-putting. It's a huge price to pay over just plugging in an existing mainstream language. no more tutorials, zillions of references a robust toolchain, huge community.. etc. but there must be a good reason for it? It's also why I don't write elisp. only so many hours in a day.. do I want to be futsing around in a language I won't ever use outside of the sandbox? not really... it's not longer just a library of some language X, but an ecosystem I need to sorta sell my soul to

ludamad 7y ago
I find gdscript almost excusable, as it has been similar enough to Python and had a fewer killer features (exported variables are available in editor, as are declared signals, etc). It's still not the ideal design decision and I often wish I was searching snippets of e.g. JavaScript. They do have C# support now!
slezyr 7y ago
There is a list of reasons why they decided to go with DSL. And I like it, it's even easier to use than lua and well integrated. https://docs.godotengine.org/en/3.2/getting_started/scripting/gdscript/gdscript_basics.html https://docs.godotengine.org/en/3.2/getting_started/scriptin...
joeberon 7y ago
It is honestly quite a poor language too. I wrote a simple game in godot and honestly the language works okay and is quite interesting for the game logic, however it is quite poor when it comes to everything less game-like, for example reading and writing to files and string manipulation felt very rudimentary. Worst part is that it feels so much like python due to its syntax yet it is much less expressive
- Decabytes 7y ago
  I wouldn't go so far as calling it a poor language, but I do feel the same way about the language in the same domains as you. I've recently run into issues with this in a project I'm currently working on
BoysenberryPi 7y ago
I find GDScript to be fine and very easy to pick up having never actually read a tutorial on the language. With that being said I'm more of an average programmer and I don't spend my time debating every nuance to a language so your mileage my vary. Godot does officially support C# now and there are plugins for many other languages including Python, Go, and Rust.
vorpalhex 7y ago
There are some good reasons to use DSLs in this case, mainly tied to sandboxing and fussing with traditional API contracts. A DSL isn't attempting to be a general programming language, it's task suited.
- throw_m239339 7y ago
  > There are some good reasons to use DSLs in this case, mainly tied to sandboxing and fussing with traditional API contracts. A DSL isn't attempting to be a general programming language, it's task suited. It's not a DSL, it's a full on programming language. It's like claiming Action Script was a DSL, it wasn't. It means tons of code in that language in order to create custom business logic, it means re-implementing things that were already written in tons of languages and so on and so forth. So a new language makes sense but it's a trade-off. Apparently there is the possibility of using other languages, so let's see if the integration is as robust. https://godotengine.org/article/introducing-csharp-godot https://godotengine.org/article/introducing-csharp-godot
  - HelloNurse 7y ago
    Whether GDScript is a DSL is arguable; a game engine scripting language falls in the interesting middle ground between a special purpose DSL with a limited scope (e.g. awk) and a general-purpose programming language with tacked-on frameworks (e.g. C++ and DirectX). There are important assumptions and specializations (e.g. the engine-managed game loop and attaching scripts to nodes) but also a large variety of use cases (for example both low effort and high performance graphics)
airstrike 7y ago
I, for one, loved mIRC scripting
0xdeadbeefbabe 7y ago
Yes it probably is necessary. They've gone through a few iterations: lua, python, etc. Is anyone else bored of the usage of the word language in computer circles?
- ludamad 7y ago
  Is there a need for a less boring word? :D
  - ilikehurdles 7y ago
    Is a more boring word absolutely necessary?
    - 0xdeadbeefbabe 7y ago
      When you are staying home staying safe?
DeathArrow 7y ago
You can also use C#.
- runevault 7y ago
  You can also use GDNative where you use C++ (or rust with some work)
klodolph 7y ago
As someone who’s gone down the route of working with an extension language— Most language implementations are fairly poor at being used for extension. You can see that a lot of people use Lua for this purpose. Given how terrible Lua is as a language, there must be a compelling reason why people use it, right? It’s easy to use as an extension language. Same thing for JavaScript. There are a few other random languages in this space. Squirrel, AngelScript, and Wren come to mind. It’s not a long list. Making your own language seems pretty appealing at that point. One of the main things you want here is for sandboxed code to stay in the sandbox, and then to be able to destroy the sandbox to get a fresh slate back. V8 and SpiderMonkey do this, as do Lua, Squirrel, AngelScript, and Wren. Most language implementations do not. CPython has tons of global state. Mono, JVM are both huge and make this difficult (you can use Application Domains in .NET but that’s fairly arcane). Criticisms of GDScript apply to these languages too, with the exception of JavaScript, as far as I can tell. I’m leaving out a bunch of projects which for various reasons are even less suitable. Guile, TCL, etc.
jan_Inkepa 7y ago
Game dev here. I've used Godot only a little bit, and Unity a lot. If you're working a lot with a single game engine, it's nice to have a programming language that's tightly coupled to it. When Unity moved away from UnityScript (a javascript lookalike but specialised for their purposes) towards C# they had to e.g. change their notation for Coroutines which made it a lot clunkier, so instead of just "yield WaitForSeconds(2.5)" you now do "yield return new WaitForSeconds(2.5f)" AND change your function signature (add an IEnumerable) AND have to change how you call the function - lots of cruft where previously it was all transparent/implicit. Also, if you're working on your own scripting language you can make it a lot more aware of the particular data and structure of in your own game (games have a lot of data!). I haven't used GDscript/Godot a lot, but I remember the autocomplete being pretty smart and aware of what's going on with your data in a way that would be hard to do with a "commodity" compiler/IDE tool-chain. It's a lot of work for them to do this on their end, but I think it pays off. It doesn't take much time to learn (especially compared to the api/3d scene interface/etc) and overall it feels slick. Most of the niceness is sparing on overhead, it's not a fundamentally alien or goofy language. As a games programmer I have to work with a bazillion programming languages anyway; if I'm working on a single project it's a real luxury to have the language be ergonomically fitted to the engine. There are advantages to using a more general programming language - maybe using Lua would've been a good option, but yeah for here at least I think it's fine (ah, another commenter linked https://docs.godotengine.org/en/3.2/getting_started/scripting/gdscript/gdscript_basics.html https://docs.godotengine.org/en/3.2/getting_started/scriptin..., which talks about this :) ). On the other hand, if programming juggernaut Unity couldn't justify keeping Unityscript alive, maybe Godot is also fated to change eventually...
- Decabytes 7y ago
  I like gdscript and my only gripes are that I use python for work and while gdscript is Python like I find the instances where it doesn't work like Python frustrating. Auto complete works great and it works even better when using typed gdscript, though it's still a new feature, and still has some edge cases that make it a little tricky to use sometimes.
jayd16 7y ago
Yeah seems kind of odd to me that Godot is making the same mistakes Unity once did but is now moving away from. Unity had UnityScript and a C++ engine but is now heavily investing in C#, moving engine parts to C# and focusing on performance in C#. Unity once had a more static and predefined graphics pipeline like Godot, but has now made it more configurable. I'm especially apprehensive about how restrictive the Godot shader language is.
henryfjordan 7y ago
I've made 2 small 3d "games" with Godot using GDScript now. I haven't used Unity or any of the competitors Learning GDScript was natural and might have even helped when you are learning all the principles of Godot at the same time. Programming in Godot was not at all similar to the backend programming I was used to and I had to learn all kinds of gaming specific concepts. If they had used Python, you'd essentially need to learn a whole new Standard Library anyway, so you might as well get the benefits of a domain-specific language anyway.
crocodiletears 7y ago
Godot's scripting language is fine for what it is. Not much bigger than it needs to be. Thankfully, if you want something more there are also C# bindings for the engine, and you can also use C++ for performance-critical elements of the engine relatively trivially.
the_other_b 7y ago
I had this opinion when I first began working with Godot, which regardless of language I've just found incredibly intuitive. I used C#, but kept getting frustrated cause the support isn't at 100% (this is currently expected, I think C# is still declared alpha?). It was pretty easy to fill in the gaps between gdscript documentation vs C#, but certain built in functionality was missing. My main use case for C# was strong typing, and the community support it has either with libraries or just getting answers online. Eventually I caved in and tried gdscript. I can develop MUCH faster, and am still able to use types. You can also still use C# in the project, since the languages can communicate. I think once C# has feature parity with Godot I'll move back to that, but until then, GDscript is great, and really easy to pick up.
- Decabytes 7y ago
  You're right. C# support is not all the way there, but support continues to improve https://godotengine.org/article/csharp-ios-signals-events https://godotengine.org/article/csharp-ios-signals-events and will be better in 4.0 and potentially a 3.2.x release before then.

by geokon 7y ago

ludamad 7y ago

I find gdscript almost excusable, as it has been similar enough to Python and had a fewer killer features (exported variables are available in editor, as are declared signals, etc). It's still not the ideal design decision and I often wish I was searching snippets of e.g. JavaScript. They do have C# support now!

slezyr 7y ago

There is a list of reasons why they decided to go with DSL. And I like it, it's even easier to use than lua and well integrated. https://docs.godotengine.org/en/3.2/getting_started/scripting/gdscript/gdscript_basics.html https://docs.godotengine.org/en/3.2/getting_started/scriptin...

joeberon 7y ago

It is honestly quite a poor language too. I wrote a simple game in godot and honestly the language works okay and is quite interesting for the game logic, however it is quite poor when it comes to everything less game-like, for example reading and writing to files and string manipulation felt very rudimentary. Worst part is that it feels so much like python due to its syntax yet it is much less expressive

Decabytes 7y ago
I wouldn't go so far as calling it a poor language, but I do feel the same way about the language in the same domains as you. I've recently run into issues with this in a project I'm currently working on

BoysenberryPi 7y ago

I find GDScript to be fine and very easy to pick up having never actually read a tutorial on the language. With that being said I'm more of an average programmer and I don't spend my time debating every nuance to a language so your mileage my vary. Godot does officially support C# now and there are plugins for many other languages including Python, Go, and Rust.

vorpalhex 7y ago

There are some good reasons to use DSLs in this case, mainly tied to sandboxing and fussing with traditional API contracts. A DSL isn't attempting to be a general programming language, it's task suited.

throw_m239339 7y ago
> There are some good reasons to use DSLs in this case, mainly tied to sandboxing and fussing with traditional API contracts. A DSL isn't attempting to be a general programming language, it's task suited. It's not a DSL, it's a full on programming language. It's like claiming Action Script was a DSL, it wasn't. It means tons of code in that language in order to create custom business logic, it means re-implementing things that were already written in tons of languages and so on and so forth. So a new language makes sense but it's a trade-off. Apparently there is the possibility of using other languages, so let's see if the integration is as robust. https://godotengine.org/article/introducing-csharp-godot https://godotengine.org/article/introducing-csharp-godot
- HelloNurse 7y ago
  Whether GDScript is a DSL is arguable; a game engine scripting language falls in the interesting middle ground between a special purpose DSL with a limited scope (e.g. awk) and a general-purpose programming language with tacked-on frameworks (e.g. C++ and DirectX). There are important assumptions and specializations (e.g. the engine-managed game loop and attaching scripts to nodes) but also a large variety of use cases (for example both low effort and high performance graphics)

airstrike 7y ago

I, for one, loved mIRC scripting

0xdeadbeefbabe 7y ago

Yes it probably is necessary. They've gone through a few iterations: lua, python, etc. Is anyone else bored of the usage of the word language in computer circles?

ludamad 7y ago
Is there a need for a less boring word? :D
- ilikehurdles 7y ago
  Is a more boring word absolutely necessary?
  - 0xdeadbeefbabe 7y ago
    When you are staying home staying safe?

DeathArrow 7y ago

You can also use C#.

runevault 7y ago
You can also use GDNative where you use C++ (or rust with some work)

klodolph 7y ago

As someone who’s gone down the route of working with an extension language— Most language implementations are fairly poor at being used for extension. You can see that a lot of people use Lua for this purpose. Given how terrible Lua is as a language, there must be a compelling reason why people use it, right? It’s easy to use as an extension language. Same thing for JavaScript. There are a few other random languages in this space. Squirrel, AngelScript, and Wren come to mind. It’s not a long list. Making your own language seems pretty appealing at that point. One of the main things you want here is for sandboxed code to stay in the sandbox, and then to be able to destroy the sandbox to get a fresh slate back. V8 and SpiderMonkey do this, as do Lua, Squirrel, AngelScript, and Wren. Most language implementations do not. CPython has tons of global state. Mono, JVM are both huge and make this difficult (you can use Application Domains in .NET but that’s fairly arcane). Criticisms of GDScript apply to these languages too, with the exception of JavaScript, as far as I can tell. I’m leaving out a bunch of projects which for various reasons are even less suitable. Guile, TCL, etc.

jan_Inkepa 7y ago

Game dev here. I've used Godot only a little bit, and Unity a lot. If you're working a lot with a single game engine, it's nice to have a programming language that's tightly coupled to it. When Unity moved away from UnityScript (a javascript lookalike but specialised for their purposes) towards C# they had to e.g. change their notation for Coroutines which made it a lot clunkier, so instead of just "yield WaitForSeconds(2.5)" you now do "yield return new WaitForSeconds(2.5f)" AND change your function signature (add an IEnumerable) AND have to change how you call the function - lots of cruft where previously it was all transparent/implicit. Also, if you're working on your own scripting language you can make it a lot more aware of the particular data and structure of in your own game (games have a lot of data!). I haven't used GDscript/Godot a lot, but I remember the autocomplete being pretty smart and aware of what's going on with your data in a way that would be hard to do with a "commodity" compiler/IDE tool-chain. It's a lot of work for them to do this on their end, but I think it pays off. It doesn't take much time to learn (especially compared to the api/3d scene interface/etc) and overall it feels slick. Most of the niceness is sparing on overhead, it's not a fundamentally alien or goofy language. As a games programmer I have to work with a bazillion programming languages anyway; if I'm working on a single project it's a real luxury to have the language be ergonomically fitted to the engine. There are advantages to using a more general programming language - maybe using Lua would've been a good option, but yeah for here at least I think it's fine (ah, another commenter linked https://docs.godotengine.org/en/3.2/getting_started/scripting/gdscript/gdscript_basics.html https://docs.godotengine.org/en/3.2/getting_started/scriptin..., which talks about this :) ). On the other hand, if programming juggernaut Unity couldn't justify keeping Unityscript alive, maybe Godot is also fated to change eventually...

Decabytes 7y ago
I like gdscript and my only gripes are that I use python for work and while gdscript is Python like I find the instances where it doesn't work like Python frustrating. Auto complete works great and it works even better when using typed gdscript, though it's still a new feature, and still has some edge cases that make it a little tricky to use sometimes.

jayd16 7y ago

Yeah seems kind of odd to me that Godot is making the same mistakes Unity once did but is now moving away from. Unity had UnityScript and a C++ engine but is now heavily investing in C#, moving engine parts to C# and focusing on performance in C#. Unity once had a more static and predefined graphics pipeline like Godot, but has now made it more configurable. I'm especially apprehensive about how restrictive the Godot shader language is.

henryfjordan 7y ago

I've made 2 small 3d "games" with Godot using GDScript now. I haven't used Unity or any of the competitors Learning GDScript was natural and might have even helped when you are learning all the principles of Godot at the same time. Programming in Godot was not at all similar to the backend programming I was used to and I had to learn all kinds of gaming specific concepts. If they had used Python, you'd essentially need to learn a whole new Standard Library anyway, so you might as well get the benefits of a domain-specific language anyway.

crocodiletears 7y ago

Godot's scripting language is fine for what it is. Not much bigger than it needs to be. Thankfully, if you want something more there are also C# bindings for the engine, and you can also use C++ for performance-critical elements of the engine relatively trivially.

the_other_b 7y ago

I had this opinion when I first began working with Godot, which regardless of language I've just found incredibly intuitive. I used C#, but kept getting frustrated cause the support isn't at 100% (this is currently expected, I think C# is still declared alpha?). It was pretty easy to fill in the gaps between gdscript documentation vs C#, but certain built in functionality was missing. My main use case for C# was strong typing, and the community support it has either with libraries or just getting answers online. Eventually I caved in and tried gdscript. I can develop MUCH faster, and am still able to use types. You can also still use C# in the project, since the languages can communicate. I think once C# has feature parity with Godot I'll move back to that, but until then, GDscript is great, and really easy to pick up.

Decabytes 7y ago
You're right. C# support is not all the way there, but support continues to improve https://godotengine.org/article/csharp-ios-signals-events https://godotengine.org/article/csharp-ios-signals-events and will be better in 4.0 and potentially a 3.2.x release before then.