GDScript – Custom scripting language to be used with the Godot game engine | Hacker News Reader

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

gdscript.com

28 pointsdoodlesdev22 comments

The official GDScript language documentation is here:

https://docs.godotengine.org/en/stable/tutorials/scripting/g...

Registering gdscript.com and boasting about its search ranking is just gross.

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.

On the About page.

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.

Why is boasting about this gross?

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.

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

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/

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

>The resulting webstuff was 50MB without audio.

That sounds about right for a full engine build before compression. When optimizing for size with Godot you rip out the parts of the engine you don't need. From what I remember some of these are not that hard to remove like 3D support. It still will be more than what it would take just doing it from javascript so you would want to make sure Godot is actually bringing value to the project.

There is no free lunch in technology. Strict reference counting is always more expensive than GC. Theoretically, compiled languages with extensive lifetime analysis and reference counting elision could produce better performance (think Rust borrow checker and lifetime annotations but you don't do the heavy lifting) but this is yet to be done and no language has this today (Swift is slower than top tier GC languages at this).

My word choice of "predictable performance" was deliberate.

I am grateful they left it at "inspired by python", as I find python with its libraries and all its warts strangely complex and indigestible. Then, from a tooling and ecosystem perspective, wildly frustrating and unfriendly to work with. So I'm glad they took the chance and made something that's tailored to their use case and gives them the space to diverge and optimise where and when it makes sense.

Also C# is available as a scripting language for Godot, which makes a lot more sense than python from a performance perspective.

Isn’t python just too slow for a game engine? Not that people don’t write games in Python but that it would be a major shortcoming for the kinds of things you can do. So you write a language that looks like Python but runs quite a bit differently and you don’t make it actually compatible with Python because reimplementing the whole manage would be tons of work and have conflicting requirements with writing a game engine.

Because games have real-time constraints.

I’ve noticed that the language is quite specialized to the engine’s memory model.

It’s not uncommon to see your typical engine have a script VM with some API calls into C++ and call it a day. GDScript’s syntax and semantics are a lot more integrated with how Godot does things. You start to see this when creating new Node/Resource types and stuff like the $ operator.

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

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)

(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)

How does GDScript compare with Starlark?

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.

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

Starlark lang spec:

https://github.com/bazelbuild/starlark/blob/master/spec.md

Google implementations:

https://github.com/google/starlark-go/

https://github.com/bazelbuild/bazel/tree/master/src/main/jav...

Rust Google implementation taken over by Meta:

https://github.com/facebookexperimental/starlark-rust

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.

Reply on news.ycombinator.com