6 ms·

GDScript – Custom scripting language to be used with the Godot game engine

28 points by doodlesdev 3y ago

jrockway 3y ago
How does GDScript compare with Starlark?
- klodolph 3y ago
  Starlark is actually a lot like Python, in the sense that you can write code in Starlark and feed it to a Python interpreter and get the same result, at least much of the time. GDScript is very different. It has some similarities with Python, kind of like how C# and Java have some similarities.
- 1letterunixname 3y ago
  Starlark is a Python-ish subset intended for declarative-looking-but-still-procedural software configuration management in Bazel and Buck2. GDScript is their own take for the GODOT game engine. It looks like Python, but it's different. There are many usability advantages, like learning curve, by modeling off a commonly used language rather than dreaming up a completely new one. Here's a list of Python-like languages: https://blog.matt-rickard.com/p/the-python-family-of-languages https://blog.matt-rickard.com/p/the-python-family-of-languag... Starlark lang spec: https://github.com/bazelbuild/starlark/blob/master/spec.md https://github.com/bazelbuild/starlark/blob/master/spec.md Google implementations: https://github.com/google/starlark-go/ https://github.com/google/starlark-go/ https://github.com/bazelbuild/bazel/tree/master/src/main/java/net/starlark/java https://github.com/bazelbuild/bazel/tree/master/src/main/jav... Rust Google implementation taken over by Meta: https://github.com/facebookexperimental/starlark-rust https://github.com/facebookexperimental/starlark-rust https://developers.facebook.com/blog/post/2021/04/08/rust-starlark-library/ https://developers.facebook.com/blog/post/2021/04/08/rust-st... These are in the embeddable languages category like Lua and dialects of other languages with implementations such as mruby, daScript, emacs LISP, and ECL. And there were game-specific ones like QuakeC and Squirrel. Those were usually in the past because other embedded languages weren't available, but now hundreds of games use/d Lua because it doesn't make sense to build a language and runtime from scratch in most cases. Scriptability (or format documentation at least in the case of Doom-engine games) is key to implementing mods officially instead of as invasive game hacks like Super Dune 2.
v3ss0n 3y ago
Why not just use python, why reinventing the wheel necessary? From most developer experience GD script isn't faster. Also that website is not official Godot website. It's a domain grab of a someone learning Godot.
- netruk44 3y ago
  The Godot FAQ [0] has a response to that. It seems like they tried to do Python, but it was too hard to embed. The FAQ goes into more detail about the specifics of what they needed in a language. [0]: https://docs.godotengine.org/en/stable/about/faq.html#what-were-the-motivations-behind-creating-gdscript https://docs.godotengine.org/en/stable/about/faq.html#what-w...
- charcircuit 3y ago
  GDScript doesn't have a GC which is a plus for people who want predictable performance. It also avoids bloating the runtime. If someone is making a HTML5 game they will not want to distribute a big WASM blob of the python runtime. If people want to use python instead of GDScript they are free to do so. https://godot-python-extension.readthedocs.io/en/latest/ https://godot-python-extension.readthedocs.io/en/latest/
  - rezmason 3y ago
    I think you're right, and want to offer some additional perspective. I made a very, very simple game in Godot 4 with my friend this fall. To build for the web target, I ported our C# to GDScript, and it wasn't so bad. The resulting webstuff was 50MB without audio. I ported it again to JS, and it's 50KB without audio. Maybe 150K with audio. About the size of two favicons. Yes, the game is very very simple ( https://rezmason.net/fluid https://rezmason.net/fluid , still refining it), but the difference between 50K and 50MB is still significant. If we had used some kind of Python to WASM toolchain, I don't know what size the project would be, but probably more than 50MB. With C# in the mix, and mono, or whatever, it would be even larger. One of the reasons we explored Godot this year was to try other ways of producing things. GDScript helps maintain Godot's distinction from its competitors, and I'll reach for it whenever I need to make #ThatKindOfThing.
xnxn 3y ago
The official GDScript language documentation is here: https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html https://docs.godotengine.org/en/stable/tutorials/scripting/g... Registering gdscript.com and boasting about its search ranking is just gross.
- serial_dev 3y ago
  Where is the boasting? Did I miss it? It is confusing that gdscript.com is not the official domain of the language, rather of a language enthusiast, but quite honestly, that one is on the Godot team.
  - xnxn 3y ago
    On the About page.
    - serial_dev 3y ago
      Oh, see what you mean now. > My side hustles have been online affiliate marketing and web development. Currently, this website is on page 1 of search engines for it’s keyword. I still think the main issue is that the Godot team didn't buy the domain, if they did none of this would have happened. With that said, the site looks kind of like a language's official site, so it can be quite confusing for people wanting to learn GDScript, who aren't familiar with the official docs.
    - janderland 3y ago
      Why is boasting about this gross?
stevefan1999 3y ago
I still didn't like it since it doesn't have JIT nor AOT to speed up code. That's why Godot C# is even faster than GDScript at many scenarios
- connicpu 3y ago
  For parts of the game's logic where pure performance is paramount you can even drop down and write a gdextension in C++ or Rust (or a couple other languages that people maintain bindings for, or write new bindings for another language that can compile to a dylib/so/dll)
- neonsunset 3y ago
  (It’s faster at all scenarios, it may seem like you can compare the languages until you learn that reference counting is always more expensive than GC and interpreted languages are unconditionally slower (by a lot) than compiled ones)

28 points by doodlesdev 3y ago

jrockway 3y ago

How does GDScript compare with Starlark?

klodolph 3y ago
Starlark is actually a lot like Python, in the sense that you can write code in Starlark and feed it to a Python interpreter and get the same result, at least much of the time. GDScript is very different. It has some similarities with Python, kind of like how C# and Java have some similarities.
1letterunixname 3y ago
Starlark is a Python-ish subset intended for declarative-looking-but-still-procedural software configuration management in Bazel and Buck2. GDScript is their own take for the GODOT game engine. It looks like Python, but it's different. There are many usability advantages, like learning curve, by modeling off a commonly used language rather than dreaming up a completely new one. Here's a list of Python-like languages: https://blog.matt-rickard.com/p/the-python-family-of-languages https://blog.matt-rickard.com/p/the-python-family-of-languag... Starlark lang spec: https://github.com/bazelbuild/starlark/blob/master/spec.md https://github.com/bazelbuild/starlark/blob/master/spec.md Google implementations: https://github.com/google/starlark-go/ https://github.com/google/starlark-go/ https://github.com/bazelbuild/bazel/tree/master/src/main/java/net/starlark/java https://github.com/bazelbuild/bazel/tree/master/src/main/jav... Rust Google implementation taken over by Meta: https://github.com/facebookexperimental/starlark-rust https://github.com/facebookexperimental/starlark-rust https://developers.facebook.com/blog/post/2021/04/08/rust-starlark-library/ https://developers.facebook.com/blog/post/2021/04/08/rust-st... These are in the embeddable languages category like Lua and dialects of other languages with implementations such as mruby, daScript, emacs LISP, and ECL. And there were game-specific ones like QuakeC and Squirrel. Those were usually in the past because other embedded languages weren't available, but now hundreds of games use/d Lua because it doesn't make sense to build a language and runtime from scratch in most cases. Scriptability (or format documentation at least in the case of Doom-engine games) is key to implementing mods officially instead of as invasive game hacks like Super Dune 2.

v3ss0n 3y ago

Why not just use python, why reinventing the wheel necessary? From most developer experience GD script isn't faster. Also that website is not official Godot website. It's a domain grab of a someone learning Godot.

netruk44 3y ago
The Godot FAQ [0] has a response to that. It seems like they tried to do Python, but it was too hard to embed. The FAQ goes into more detail about the specifics of what they needed in a language. [0]: https://docs.godotengine.org/en/stable/about/faq.html#what-were-the-motivations-behind-creating-gdscript https://docs.godotengine.org/en/stable/about/faq.html#what-w...
charcircuit 3y ago
GDScript doesn't have a GC which is a plus for people who want predictable performance. It also avoids bloating the runtime. If someone is making a HTML5 game they will not want to distribute a big WASM blob of the python runtime. If people want to use python instead of GDScript they are free to do so. https://godot-python-extension.readthedocs.io/en/latest/ https://godot-python-extension.readthedocs.io/en/latest/
- rezmason 3y ago
  I think you're right, and want to offer some additional perspective. I made a very, very simple game in Godot 4 with my friend this fall. To build for the web target, I ported our C# to GDScript, and it wasn't so bad. The resulting webstuff was 50MB without audio. I ported it again to JS, and it's 50KB without audio. Maybe 150K with audio. About the size of two favicons. Yes, the game is very very simple ( https://rezmason.net/fluid https://rezmason.net/fluid , still refining it), but the difference between 50K and 50MB is still significant. If we had used some kind of Python to WASM toolchain, I don't know what size the project would be, but probably more than 50MB. With C# in the mix, and mono, or whatever, it would be even larger. One of the reasons we explored Godot this year was to try other ways of producing things. GDScript helps maintain Godot's distinction from its competitors, and I'll reach for it whenever I need to make #ThatKindOfThing.

xnxn 3y ago

The official GDScript language documentation is here: https://docs.godotengine.org/en/stable/tutorials/scripting/gdscript/gdscript_basics.html https://docs.godotengine.org/en/stable/tutorials/scripting/g... Registering gdscript.com and boasting about its search ranking is just gross.

serial_dev 3y ago
Where is the boasting? Did I miss it? It is confusing that gdscript.com is not the official domain of the language, rather of a language enthusiast, but quite honestly, that one is on the Godot team.
- xnxn 3y ago
  On the About page.
  - serial_dev 3y ago
    Oh, see what you mean now. > My side hustles have been online affiliate marketing and web development. Currently, this website is on page 1 of search engines for it’s keyword. I still think the main issue is that the Godot team didn't buy the domain, if they did none of this would have happened. With that said, the site looks kind of like a language's official site, so it can be quite confusing for people wanting to learn GDScript, who aren't familiar with the official docs.
  - janderland 3y ago
    Why is boasting about this gross?

stevefan1999 3y ago

I still didn't like it since it doesn't have JIT nor AOT to speed up code. That's why Godot C# is even faster than GDScript at many scenarios

connicpu 3y ago
For parts of the game's logic where pure performance is paramount you can even drop down and write a gdextension in C++ or Rust (or a couple other languages that people maintain bindings for, or write new bindings for another language that can compile to a dylib/so/dll)
neonsunset 3y ago
(It’s faster at all scenarios, it may seem like you can compare the languages until you learn that reference counting is always more expensive than GC and interpreted languages are unconditionally slower (by a lot) than compiled ones)