[Rapzid]

Here is a discussion from the proposal repo I found with the topic of improving C# support: https://github.com/godotengine/godot-proposals/discussions/4... .

One of the first comments was quick to point out that in a poll from back then 81% of users used GDScript primarily. They followed up with saying:

> As far as I know, the only reason why Godot got C# support is because of Microsoft's grant (and of course neikeq enthusiasm ).

It's my impression poking around that a lot of the community, at least at the time, had a hard time imagining that for Godot to gain serious mainstream adoption as THE OSS game engine, the project would need to focus on the what the development makeup would be at that future time and how they can attract those crowds. So, the user makeup of now may not look like the makeup of then.

Further down though somebody points out:

> Most people using Godot will make toy projects. That is the same for all other engines and developer tools as a whole. C# is crucial in serious projects, at least in 3D which is where I spend most of my time. Having first-class support for it (both in terms of tutorials in the documentation as well as in the engine) will go a long way towards making better-performing games for developers making serious projects.

This post has been timely as I've been checking out Godot going through a massive 12 hour tutorial but using C# instead of GDScript; because of course. The entire time my mind kept wandering back to this quote I've seen posted various places:

> C# is faster, but requires some expensive marshalling when talking to Godot.

I kept thinking "but why?! C# has excellent interop support and should be able to map directly over Godot's types. That seems like it's going to be a serious limitation long term..".

EDIT: That said, I'm very impressed with Godot in general and a lot of the C# integration. They are making pretty good use of source generators making a lot of string magic replaceable with type-checked property accesses. Signal creation and exporting properties to Editor members works this way; cool! I think they will end up working through the worst of these interop perf issues.

[Nition]

There was a time when Unity leaned heavily on UnityScript. The manual defaulted to it, the sample projects all used it, most tutorials used it and so did most of the asset store.

As Unity continued to change more from a hobbiest game engine to one used by professionals, things changed and C# became the default.

[Rapzid]

Easily room for both though.

Maintaining two API binding layers is perfectly feasible with the attention and resources Godot is attracting.

Unlike with Unity interested parties can jump in and lend a hand. You'll have two groups(perhaps overlapping) maintaining the compiled and script bindings.

Maybe GDScript could just get the concept of a struct and the differences minimized over time too.

[johnnyanmac]

From what I'm reading here and elsewhere, we'd need to do some fundamental mucking into the c++ layer as well, given some data oriented hostile practices.

But yes, I think it'd be best long term to treat GDScript ad C# the way Unity treated GameObjects and DOTS. DOTS's goal wasn't to kill gameobjects, and in fact a lot of work went into bridging between the two with hybrid packages. I guess we'll see if that kind of initiative gets some momentum (and I'd love to help out if so!)

[trinovantes]

That poll seems highly biased

How many people have tried godot/gdscript, hated it, and never came back? They're not the people who are answering the survey

[Rapzid]

Yeah it's def biased towards existing users in many ways.

Not a terrible thing if you want to concentrate on their needs, but not the best questions for filtering ideas for expanding adoption (perhaps).

[tacotacotaco]

How many users that are happy with gdscript are taking time to read vote in a GitHub polling posted about c# issues?

[johnnyanmac]

Doomscrolling is a thing even in gamedev, I suppose.