Hacker News Reader

Comment by Dudester230602 | Hacker News Reader

I hope they will drop the funny little language in favour of first-class C# support.

No way! The funny little language rules! It's a competitive advantage for Godot.

GDScript integrates so nicely with the Node/Resource refcount model. It fills the same niche that Unreal's Blueprints do, which is great! When you've found something performance-critical, it's not difficult to convert a GDScript node into a GDNative one.

I feel like a lot of the "GDScript, ick!" comments tend to assume that the scripting language is trying to be Lua/C#/Python tacked onto a C++ codebase. It's a lot more tightly-integrated with the runtime, and it makes organizing things a lot better in the long run.

The funny thing is that if you are looking for some GDScript call into the engine it oftern supports exactly the functionality you need for your use case even though other more common use cases are not supported.

It shows that the developers making it are also the ones using it for themselves.

The Rust bindings (crates gdnative for 3.0 and gdext for 4.0) also are pretty great. I've only used them a bit so far but once I got the hang of it it works well. They don't seem to teeth badly with Rust's ownership semantics like some attempts at wrapping GTK struggled with.

I haven't used Rust professionally, but have often wondered if Rust's RAII [1] meshes decently with the lifetime of a RefCounted in Godot. [2]

While Godot's profiling has a lot of room for improvement, I appreciate how intuitive memory usage is from both a design and technical standpoint.

[1] https://doc.rust-lang.org/rust-by-example/scope/raii.html

[2] https://docs.godotengine.org/en/stable/classes/class_refcoun...

It’s not that long ago when people were saying:

“Weird how Unity uses Microsoft’s enterprise Java clone. Why can’t they use C++ like real game engines? Nobody will develop a proper game on this language.”

Only those that having been around for the history of game development.

Once upon a time the same was told about Basic, C and Pascal, all serious game development was Assembly.

Then the same was told about C++, all serious game development was in C.

Then the same was told about Java, and a couple of folks not paying attention got millionaires.

Then ...

Yes, this.

So many devs get caught up on which language is used. I have my pet languages that I prefer too, but at the end of the day a game engine is about creating games. So long as the language offered is reasonably usable and one can deliver a fun and engaging experience with it, the language bindings don't matter much. Everything I've read about GDScript indicates that it fills the need, is fun to use, and generally gets out of the way so devs can focus on creating fun and engaging experiences.

The only reason I see having C# support is critical is if a Dev is porting from another engine (i.e Unity) midway through development or if the dev/studio has lots of boilerplate code or libraries already written for prior titles. If starting from scratch, I don't see a good reason to stick with it.

I really hope Rust is the next iteration of this story. At least for the deep engine/rendering code. You can have a scripting layer on top of that for designer iteration.

Sure but the problem with gdscript is not that it's an abstraction or a high level language. It's that it's a weird dsl that isn't even really good at making games. I don't mind DSLs when they actually enhance the domain they are created for, but in this case having a game engine language not having interfaces or traits is weird...

One can still hope.

Godot 4.0 has C# support. They're working on getting it up and moving for iOS and Android but it already works on Desktop

I think the emphasis is on "first-class" support. I don't think they'll be able to really pull over Unity devs until C# mobile is nicely supported.

I know every time I personally go to take a peek I see that C# support is still a good bit behind and decide to let it keep baking. I'm still very excited for it, though.

Partial support, there is nothing for game consoles and mobiles.

Seconding that Godot C# support is pretty alright and in motion, but also GDScript actually is rather nice for game jamming and quick prototyping.

That would kill unity and make godot the preferred engine over night for large indie communities.

I don't think that will happen until Godot has an asset store with as much content as Unity.

Not as hard as you think. just a few assets ported will be enough. - 3d player controller - dialogue system - vr kits - animation system in the style of mechanim

Those are what the vast majority of indies buy beyond 3d assets where they can get elsewhere.

I don't see why there cannot be both? GDScript is perfectly useful.

I prefer it. I'm not wasting a single second in C# until I have to.

For me it's not whether it's useful, it's whether the tradeoffs are worth it. I assume GDScript has some unique features that make it especially useful in Godot development, but the disadvantage is that the skills aren't transferrable to any other platform or environment. At least C# and C++ are applicable outside of the engines that use them.

The skills are transferrable enough. It's Python with a little syntactic sugar for Godot-specific things.

It's an easy language to pick up for beginners and powerful enough for experienced devs. Kind of the sweet spot for game dev, IMO.

I get what you're saying, but a good chunk of transferable skills are not language-specific. Programming in a video game environment is going to impress some knowledge upon you that is generally useful, regardless of the language you use.

Because as is C# is very noticeably a second class citizen. Something like Godot 4.0/4.1 missing C# support for android/ios/web shows that perfectly imo.

Their funny little language is really close to Python so it's tapping into a huge base of Python developers.

Is there any background for why they chose to roll their own language, rather than harness Python or another, popular language?

There is indeed a section about that in the docs.

https://docs.godotengine.org/en/stable/about/faq.html#what-w...

I prototype Godot games with a small team that is less technical. They are able to handle (some) GDScript but not C#. I realize my use case is non-professional but I think it's good that a more accessible language is the default option.

Agreed, having C# be the default would also better incentivize former Unity devs to jump ship. Not to mention that learning C# has value outside of Godot, whereas GDScript is not exactly transferable knowledge.

Why do you want them to drop it? Why is it not enough that you can completely ignore it and write your games in C#?

Reply on news.ycombinator.com