4 ms·

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 web

by 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.
  - deleted 3y ago
    [deleted]
  - charcircuit 3y ago
    >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.
- neonsunset 3y ago
  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).
  - charcircuit 3y ago
    My word choice of "predictable performance" was deliberate.
prollings 3y ago
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.
colechristensen 3y ago
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.
bufio 3y ago
Because games have real-time constraints.
danbolt 3y ago
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.

by v3ss0n 3y ago

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.
- deleted 3y ago
  [deleted]
- charcircuit 3y ago
  >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.
neonsunset 3y ago
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).
- charcircuit 3y ago
  My word choice of "predictable performance" was deliberate.

prollings 3y ago

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.

colechristensen 3y ago

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.

bufio 3y ago

Because games have real-time constraints.

danbolt 3y ago

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.