undefined | Better HN

0 pointshn87884y ago0 comments

It was a little of both, but it's not really a valid complaint any more. When Godot first open sourced, it didn't have features like culling meshes that the player couldn't see, and the lighting implementation was pretty basic. The default language in the engine is basically python, so it could cause a performance bottleneck. Now it has a lot of the 3D performance features it was missing, and it has first-class C# support if the default language is causing a bottleneck.

0 comments

ImprobableTruth4y ago

I tried Godot again like ~8 months ago and the C# support was still awful to the point that I'd consider 'first-class C# support' an outright lie. It might be 'officially supported', but it's in 'late alpha' since 2018 and is very obviously a second-class citizen, which should be clear just from the bad state of the C# docs. Community resources for C# are also much more sparse (subpar support probably contributes to this).

It doesn't seem like they've made much progress in Godot 3.3 - seems like a grant ran out so they had to let their C# dev go, so I don't expect any major changes for the foreseeable future.

Keep in mind that I'm obviously quite soured by the experienced - Godot might still be the right choice for anyone who is considering. I'd just recommend anyone to factor the very rough C# support into their choice, especially for anyone planning to use it for a more involved project.

lewispollard4y ago

I've been using C# in Godot for all of my latest projects of the last ~year and have had absolutely no issues at all. Most of the docs these days have a "GDScript/C#" tab selection, and the intellisense support is so good that I rarely even have to check.

Now, I did already know the Godot API quite well when I started using C# so that contributes. But I haven't found it to be a second-class citizen at all, and in fact allows me to use features that I wouldn't have been able to in GDScript (native event handling, offloading to native data structures for computation rather than using the Godot API for them, nuget packages, and so on). I can also use eg Jetbrains DotTrace to profile code in much more detail than GDScript, and edit and launch my game code from an IDE without ever opening the editor.

You can also opt to use the dotnet-core compiler instead of the bundled Mono one these days which allows you to use some more modern features.

The only clunky thing I've found is that trying to use a native C# data type in a Godot Node object causes marshalling errors, but I'm pretty sure that would apply to nearly any Mono game engine and that Unity has similar issues (having to wrap things in MonoBehaviours etc- it's been a while so this may be inaccurate). The simple workaround is just to use the Godot API for things that are in the scene tree, and native types when you need to compute stuff with better performance.

I'm curious as to what actually felt rough to you in C#?

datavirtue4y ago

Yeah, no idea why C# was introduced other than to appeal to people with zero game dev experience who might be lured in by thinking their knowledge of C# is going to matter.

Also, the async/threading model breaks it's chains and requires developers to know about the internal implementation. That to me is a serious WTF.

ido4y ago

Isn't it obviously to lure unity users?

lewispollard4y ago

> Also, the async/threading model breaks it's chains and requires developers to know about the internal implementation. That to me is a serious WTF.

You're going to have to know that stuff for any game engine that isn't just a pure C# framework. Unity is no exception afaik, you have to use the Unity API Job system to be able to run threads safely. I use async/await in Godot C# all the time. Threading requires using the Godot API, sure, that's natural, since threading can be a mess in video games.

krapp4y ago

GDScript isn't basically Python. It uses significant whitespace, but that's about as far as the similarities go.

follower4y ago

The Godot docs[0] describe the relationship as:

"It uses a syntax similar to Python (blocks are indent-based and many keywords are similar)."

And[1]:

"If you've ever written anything in a language like Python before then you'll feel right at home."

So it's more than just whitespace.

I seem to recall it being acknowledged that Python was a big influence on GDScript's design and in a number of cases "How does Python handle this?" drove some of the design decisions.

[0] https://docs.godotengine.org/en/stable/getting_started/scrip...

[1] https://docs.godotengine.org/en/stable/about/faq.html#what-i...

alpaca1284y ago

You are not wrong, but the original point was that GDScript is slow because its syntax is similar to Python's and Python is slow. That just doesn't make any sense.

> The default language in the engine is basically python, so it could cause a performance bottleneck.

2 more replies

keyle4y ago

I use both GDScript and python professionally. Yes there are a lot of differences but overall if you know Python, learning GDScript is _very_ easy.

publicola19904y ago

But why did they chose to invent GDScript and not chose to use/embed python itself? Using a newly invented special purpose language is something that often discourages me from considering a tool/framework.

pansa24y ago

See “What were the motivations behind creating GDScript?”:

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

j / k navigate · click thread line to collapse

0 comments

ImprobableTruth4y ago

It doesn't seem like they've made much progress in Godot 3.3 - seems like a grant ran out so they had to let their C# dev go, so I don't expect any major changes for the foreseeable future.

lewispollard4y ago

You can also opt to use the dotnet-core compiler instead of the bundled Mono one these days which allows you to use some more modern features.

I'm curious as to what actually felt rough to you in C#?

datavirtue4y ago

Yeah, no idea why C# was introduced other than to appeal to people with zero game dev experience who might be lured in by thinking their knowledge of C# is going to matter.

Also, the async/threading model breaks it's chains and requires developers to know about the internal implementation. That to me is a serious WTF.

ido4y ago

Isn't it obviously to lure unity users?

lewispollard4y ago

> Also, the async/threading model breaks it's chains and requires developers to know about the internal implementation. That to me is a serious WTF.

krapp4y ago

GDScript isn't basically Python. It uses significant whitespace, but that's about as far as the similarities go.

follower4y ago

The Godot docs[0] describe the relationship as:

"It uses a syntax similar to Python (blocks are indent-based and many keywords are similar)."

And[1]:

"If you've ever written anything in a language like Python before then you'll feel right at home."

So it's more than just whitespace.

I seem to recall it being acknowledged that Python was a big influence on GDScript's design and in a number of cases "How does Python handle this?" drove some of the design decisions.

[0] https://docs.godotengine.org/en/stable/getting_started/scrip...

[1] https://docs.godotengine.org/en/stable/about/faq.html#what-i...

alpaca1284y ago

You are not wrong, but the original point was that GDScript is slow because its syntax is similar to Python's and Python is slow. That just doesn't make any sense.

> The default language in the engine is basically python, so it could cause a performance bottleneck.

2 more replies

keyle4y ago

I use both GDScript and python professionally. Yes there are a lot of differences but overall if you know Python, learning GDScript is _very_ easy.

publicola19904y ago

pansa24y ago

See “What were the motivations behind creating GDScript?”:

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

j / k navigate · click thread line to collapse