C# deserves more.

[al1-ce]

C# implementation always lacks features and feasts on bugs. Scripted materials, resetting node stats when using nested tool scripts, buggy collections, cut out export properties, outdated dotnet. C# deserves more attention!

[Steveplays28]

There's a dotnet v6 branch in the Godot repo which is actively being worked on afaik
Collections aren't buggy
Export properties work for all the Godot and C# types in my experience

[al1-ce]

Dotnet6 is a good thing, but til it's out we have nothing.
Collections a lot of time have one thing that's kinda broken, seeing git issues, or at least they had coz I use c# collections where I can and and so can't be a real judge.
With properties there's one exact thing I could name right now, it's custom types and scripts. All of the time they fail at choosing needed one.
I know a lot of this is just a banter but I saw a lot of c# issues which I personally encountered that's still hanging open til this day.

[Steveplays28]

There was a meta issue about this lately, but a lot of open issues are just small things or things that people don't care enough about

[neikeq]

Please, create issues for these individual problems. If they already exist, add links to them so that I know what are those issues that are bothering you. Otherwise, there's little I can take from this.

Regarding outdated dotnet, Godot 4.0 will switch to .NET 6.

[kisg]

One concrete thing I would like to bring-up here as well is the conversion of script languages into full-blown GDExtension modules. We already have 2 proposals where the discussion is ongoing: #3369, #3927 and @touilleMan from Godot-Python fame seems to like the approach as well.

What do you think @neikeq: Would you support a similar solution for C#? I see a lot of benefits, and I would be happy to provide more details, if you are interested.

[azur-wolve]

Another topic regarding C# is support integration within the scripting workspace.

[Xrayez]

According to Godot community poll in 2021, there are around 13% of people that use C# in Godot:

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

Talking about myself: it's quite difficult to maintain C# support even for modules, that's why I don't provide C# builds for Goost, for instance, because I'd rather focus on feature development rather than fighting against the buildsystem, issues like godotengine/build-containers#95 slow down the development pace.

So, I guess it's a matter of allocating enough of funds for C# support to thrive, to be honest. But then think about other major issues or lack of features in Godot (like lack of GLES renderer in Godot 4.0).

[cgbeutler]

I get that. Didn't mean all that to sound critical, as you guys are doing great work. I mostly meant to highlight that small things like that send implicit messages, intended or not.

[kodkuce]

Can someone explain to me what MAUI has to do with Godot, isent it just a UI framework and from what i see it does not even support linux

[neikeq]

@kodkuce We don't really need MAUI, but from what I've seen, mobile support in .NET 6 seems to be tied to the development of .NET MAUI (I suppose they will be released together). Currently, Visual Studio does not include .NET 6 mobile templates (it has the classic ones that are not .NET 6). Only Visual Studio Preview includes these templates.

[beeradmoore]

Hey, .NET mobile developer here. This may not be relevant anymore and I forget where the state of things were in April (MAUI had a rough launch) but I wanted to add some things of the current state of mobile development for anyone who comes across this thread.

VS on both macOS and Windows now support the mobile variants of .NET 6 (and now even .NET 7). They are targeting specifically net6-ios and net6-android. MacOS is net6-maccatalyst and I think Windows is net6-win. These mobile ones are equivalent to using Xamarin.iOS and Xamarin.Android but you now use actual .NET rather than mono.

As for MAUI, its a cross platform UI framework. Great for making an app that has the same UI across platforms but I assume its mostly irrelevant to Godot as I assume Godot is using OpenGL/Metal under the hood? In which case almost the entire thing would be written in platform specific code with MAUI just getting in the way on top.

MAUI updates are released in tandem with .NET updates (as are net6-ios net6-android I think), as they are all dotnet workloads. The equivalent is that before we would use Xamarin.Forms and we would get updates as separate nuget packages as well as different releases of Xamarin.iOS and Xamarin.Android.

[cyraid]

You can't trust those stats, because currently most of the addons and such assume people use original godot editor and not the .net version, seeing as it's safer to use gdscript in plugins as both versions of the editor will have gdscript. Until you have a unified editor that supports .net and gdscript and not biasing gdscript, then another poll could be done. There has also been a lot more converts from Unity since the whole Unity debacle, so having another poll would benefit.

[erayzesen]

I'm using c# with Godot for 2 years . Technically I think C# side is very stable on Godot right now. @neikeq has done a good job.

The problem is starting documantation side.

C # users rate is 13% because documentation support is bad. Even very simple features are not available in the C # code samples in Godot Documentation. If you do not constantly strive or your intuition is bad, you cannot use Godot with C #. This is actually a sad situation. Because a labor is wasted on the C # side and people can't use it.

[GeorgeS2019]

@Ommina you could also check out this GDScript/C# unit test framework. The UI to trigger debugging is familiar for VS2019 users. Please support this framework by providing feedback on how to improve the c# debugging support and the need to upgrade the support for Godot4 .NET6!

[Shadowblitz16]

I'm using c# with Godot for 2 years . Technically I think C# side is very stable on Godot right now. @neikeq has done a good job.

I'm curious, have you tried doing any tool scripts in C#?

From my experience, C# works well enough for runtime stuff, but as soon as you try to interact with the editor, all hell is let loose. Exported variables become unreliable, editor often crashes, among other things.

To be fair, the documentation does imply that tool scripting and C# are not best buddies, but as a first class language, that shouldn't really be the case, should it?

I have found even with gdscript tool scripts are super buggy and don't work anything like what game scripts do.

[azur-wolve]

@Shadowblitz16 which problems have you found using tool scripts?
Not used them extensively, but don't remember had experienced any problems myself.

[Shadowblitz16]

@Shadowblitz16 which problems have you found using tool scripts? Not used them extensively, but don't remember had experienced any problems myself.

onready vars don't load in the right same order, nodes are missing onready and scenes not updating when the script is changed

[azur-wolve]

onready vars don't load in the right same order, nodes are missing onready and scenes not updating when the script is changed

For tool scripts is expected to being reload on-editor after updating them.

What I don't fully undestand yet is what you say about both:

onready vars don't load in the right same order

nodes are missing onready

[GeorgeS2019]

Someone at Godot Reddit has already being using Godot 4 mono for a few weeks with a smiling face. I compiled a few weeks back, it is less stable but usable.

However, from the progress of porting to .NET 6, I look forwards for the .NET 6 branch merging to the main branch BEFORE Godot 4 becomes beta (as stated recently)

[zaksnet]

The best way i'v found so far to work with Godot and C# is to use C# scripts for the root node of your scenes and then GDScript for all subsequent scenes. That way you can have C# as your main language (and you can use a DI container properly) and use GDScript with modules/components. C# is great and in my case necessary but GDScript is also very integrated and provides alot of syntaxic sugar that makes things easier. Other than that i also think its quiet stable at this point (credits to @neikeq !). Looking forward to .NET 6 support💪.

[lewiji]

Been using C# for a couple of years exclusively in Godot, the only gdscript in my project is in (third party) addons (I have my own addon for the project tooling, but even that is in C#). Generally speaking I find support excellent. I use Rider IDE and can debug and profile code no problem, and autocomplete/intellisense works perfectly and often saves me from having to look up the docs.

The recent RC2 build for 3.4.3 fixed mono tool scripts losing their values on reload, that was a big issue but works fine in that version which should be out in stable soon.

As long as I set the editor settings build tool to dotnet CLI rather than msbuild, everything works great for me; I can even bump the language version in the csproj file up to 10 (the default is 7, I think?) and use most modern features without issue, and I only have dotnet sdk 6 installed on my system, so things work fine but I guess there are a few very new features that aren't supported (I wouldn't be able to name them though, I haven't yet found something that didn't work for me).

Outstanding issues that I do have:

• Working with custom Resources written in C# can be a pain, I do it a lot in my game.
  • Exported custom resources aren't scoped in the editor to the resource type, so the dropdown becomes a huge long list of every resource type, and the lack of keyboard shortcuts for that field means I have to scroll all the way down the list to clear or load a resource. My scroll wheel finger is getting tired!!
  • Exporting collections of exported resources can be tricky, but I've found you can use a setter to create and assign custom resources to the exported collection as the array size increases in the editor to ease that process.
  • Loading C# custom resources from disk requires a bit of a workaround with casting or you get invalid cast exceptions, and saving them requires a workaround where you have to load the custom resource script as a CSharpScript resource and assign it to the resource and then cast it (iirc) in order for it to save properly (else it just saves the Resource as a CSharpScript rather than a Resource with your custom type)
• Signals belonging to built in Nodes aren't referenced statically in the API, e.g. instead of something like timer.Connect(Timer.Timeout, ... I have to do timer.Connect("timeout", ... which isn't ideal.
• Unhandled exceptions in tool scripts can CTD the editor... but I can just handle exceptions properly to mitigate that

I can't think of anything else really and all of those can be dealt with and I think are known issues. C# in Godot for me is amazingly productive and very rarely do I encounter anything where the combination of API docs for GDScript and IDE autocomplete can't help me to figure something out. There's also a 3.4 C# API reference here from paulloz: https://paulloz.github.io/godot-csharp-api/ which is helpful

Edit: and not to distastefully dunk on Unity, but given Unity is a C#-first engine, I actually find working with C# in Godot much less restrictive. With Unity it feels like you're using "unity C#" and are constrained by their design choices; with Godot it feels like I'm just using plain C# and interacting with the API and type hierarchy like any other application.

[azur-wolve]

@lewiji you're making me thing that most complains seen around are from people that don't get the correct workflow.

In general it looks that the most problematic thing regarding use other languages is interfacing with Godot types.
There is where the biggest GDScript strength lays (leaving aside Editor integration), so a good combination of GDScript + another language is the way to go.

TL;DR: at the expectation that the upcoming GDExtension could bring some game-changing improvements on the whole matter.

[lewiji]

How do you mean, interfacing with Godot types? I don't have any problems with that in C#, but maybe you mean something different from what I mean.

[lewiji]

Unless you mean something like, "marshaling data types that aren't supported by the godot api through the godot api"

[azur-wolve]

Due to lack of documentation and so, exported and tool stuff, and properties ended up being a bit of a hassle, at least is what read on various Godot Issue threads.
But as not used it yet can't say much about.

[lewiji]

Exported built-in properties work great! No disadvantages at all compared to gdscript, except in the case of exported custom resources, as I outlined. And I hope that sitatuion improves, I use them a lot - but actually the number of godot devs who've never even used custom resources, or don't know they exist, seems very high from talking to people on the discord server.

Tool scripts just had this issue around reloading rebuilt scripts, where context could be lost, but that's been fixed in the latest 3.x code, and will be released as a stable 3.4.x version soon.

Documentation situation can definitely be improved, too, though! Generally I find that IDE autocomplete is good enough to just read the gdscript docs and guess, but I get that for people unfamiliar with the godot API that can be a challenge.

[ultramarinebicycle]

Low C# user share

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.

[lewiji]

The engine has first class support, and imo, developer makin serious projects aren't as interested in tutorials. Documentation can always use more improvement! Though documentation writing is hard.

[azur-wolve]

Agree with better documentation + engine integration; if they want better/serious games made with Godot they should give it a push.

Right now the only feasible language that can allows creating complex games, not being a systems pre-compiled language (C/C++, Rust) but a more high-level one that still shares certain low-level like features is C#.

I would start with better documentation; heard some talking about being lost cause don't know how do certain thing in C# (in the context of coming from GDScript).

Btw the slowness of GDScript isn't the only factor that lets users to switch to more advanced languages. There is also the more advanced features; many times missed in GDScript things like Static Classes, interfaces/traits, nullable vars, coalescing operator, etc.

Various of them can be reproduced on GDScript by using workarounds, but it isn't the same..

[lewiji]

At least part of the problem is that C# is a complicated language, and advanced language features are difficult to understand, and typing is often difficult to wrangle if you're not used to it. So as a beginner dev switching to C# from gdscript without much experience in typed languages can be really tricky, with errors and syntax issues that aren't really godot problems as much as language features being misunderstood.

I know this applies to me; I'm a software engineer, I have a degree and have been in the industry for 10 years, but switching to C# in Godot was hard because I'd never used C# before. The godot api made perfect sense to me, the issue was how to use the language more than anything, and it took me a long time to get comfortable with it.

I'm not sure it's godots responsibility to do that kind of education, but there could be better documentation around common patterns and work flows and code styles for beginners transitioning to C#.

That would probably involve a bunch of godot C# devs actually deciding what those common patterns are, which is tricky, but it'd be nice to have for sure :)

[azur-wolve]

Godot assumes that if you want use C# with it, you already know use it.
While not leaving aside beginners, I would give some push to attract more experienced gamedevs to Godot;
Beginners will do simple games and prototypes for the most part until they acquire experience;
But experienced gamedevs will develop more advanced games, whose will show the true power of Godot unleashed.

The documentation would state how to interoperate between C# and Godot, not teach how to use C#.
To learn C# there are already many good free resources along the web.

[setanarut]

[lewiji]

This issue is about improving C# support in Godot.

If you'd like to see better integration with your languages of choice, and have suggestions to improve the tooling around them, you can start a new discussion for them.

[lewiji]

Godot is developed entirely by volunteers, and that includes the C# support, which is mostly done by one person, @neikeq. Same for the other languages supported by GDNative bindings, and in Godot 4 it's possible that C# and all other bindings will work through the same GDExtension mechanism, though that hasn't been decided yet. Point being, there is no "they" to support languages, and work on one language doesn't preclude work on others, as each is managed by its own volunteer developer(s).

[lewiji]

In case you weren't aware of them:

Rust: https://github.com/godot-rust/godot-rust

Go: https://github.com/godot-go/godot-go

[lewiji]

Official support in C#'s case basically means it has some internal tooling to deal with bundling Mono, can generate a C# project, and has a "build" button in the corner. Still, the work is done mostly by a single volunteer, same as the other language bindings. Ok, it avoids using GDNative and can bind directly as a module, though not much is stopping other language binding developers from doing similar.

There are lots of people happily using other languages in Godot. As you mentioned, those are compiled languages, which means they don't need to mess around with SDKs and runtimes to work, so they don't need as much integrated editor support.

But again, if you do want to see more integrated editor support for your preferred languages, start a discussion about that. This thread is otherwise not contributing much to the discussion of improving C# support in Godot.

[GeorgeS2019]

@hazarek
Do create a separate discussion on Godot Rust => 3 years ago, Godot C# was in similar active as what Godot Rust NOW. It just take time. Rust is better choice than Go, why Godot Rust is more active than Godot Go.

[kodkuce]

I personally would like to see more c# love and polish cuz that would bring more a lot unity people to godot

[njdf18]

We are here to talk about how to improve C# features. Why are you here if you hate it? Throwing it away is not the best way now imo.

[setanarut]

@GeorgeS2019 I mentioned my hatred for C# and Microsoft products. What does it have to do with respect for the Godot community?

[Zireael07]

@hazarek Why mention your feelings for C# if it's irrelevant here?

[kodkuce]

i am used to c# and hate gdscript but i think @hazarek should be allowed to express his opinions.
Tough i am biased i got already 2 times banned in discord accidentally, for expressing my opinions xD

[njdf18]

@kodkuce He/she is allowed to express his opinion, but it is not about the issue.

[setanarut]

@lewiji

thank you for your contribution to this discussion - but it will be ignored.

😂 this man thinks he's a god who decides everything

[njdf18]

Why don't you start a new discussion if you want to talk about another issue?
Your comments are very irritating.

[lewiji]

It doesn't require supernatural powers to understand why your comment will be ignored, just mere common sense.

This is not your personal twitter account. This is the godot improvement proposal discussion about improving c# support. If you thought that your comment about hating c# would cause the volunteers and community around c# in godot to say "you know what, this man's right, let's stop this at once", then you absolutely lack that.

If, however, you wanted to cause a reaction and get a rise out of people, well congratulations, you've trolled us on github, well done. I still believe that your energy would be better served elsewhere, such as contributing to discussions about improving support for languages you don't hate.

[Flavelius]

It would be nice if non-tool godot-inherited c# types were available to the editor regardless of the [Tool] attribute. So that editor scripts can properly deal with resources and nodes (make type checking work correctly). So the [Tool] attribute merely enables the godot callbacks. Similar to how it works in unity.
With the current way of handling resources like magic that only get type checked at runtime there's no good way to even create custom workarounds, because the editor does this magic (/untyped stuff) assigning base resources to resource fields of inherited types, which is not really mimicable in a typesafe manner. Plus it currently allows buggy user input, like assigning anything resource-inherited to specific fields of actually different types (some even creating silent crashes at runtime).

[PoisonousGame]

If Godot doesn't support C#, no company will probably use it. It would only stay with individual developers and very small teams. This is not conducive to Godot's development. Although Godot is becoming more and more popular, there is not a very good work to prove the engine.

[njdf18]

I think company which want to use Godot would look for C++ software engineer even if Godot didn't support C#.
But C# software engineer is very easy to find thanks to Unity haha.

[PoisonousGame]

godot4 c# is slower than godot 3 c#, will it be optimized in the future?

[gxrsprite]

godot4 c# is slower than godot 3 c#, will it be optimized in the future?

I test C# performence under some runtime.
godot3.5 benchmark score is similiar to mono, godot 4 score is faster than godot3.5 but slower than net6, maybe becouse it is debug mode.
excel file:https://wwu.lanzoub.com/i8isi0dr9kfa

[PoisonousGame]

When accessing the godot api with godot4 c#, it is not as efficient as gdscript. slower than 3.5. If you don't access godot api, obviously c# is faster than gdscript. You can test it.

[Calinou]

Please create an issue on https://github.com/godotengine/godot with benchmarks included, so that others can try to reproduce it on their own system.

[neikeq]

When reporting performance regressions between Godot 3.x and 4, please include example projects in addition to your results.

Also, it should have enough information to be able to determine that the regression is in the C# bindings and not in Godot itself. You could include the equivalent GDScript code to compare to. That being said, GDScript has also received many improvements in Godot 4, so it's not that good of a reference point. A better one would be a module written in C++.

[Shadowblitz16]

please implement this.. https://github.com/TheKetrab/godot-csharp-intellisense

[roookeee]

I just wanted to commend the Godot community / maintainers of the C# integration. Working with C# in the Godot 4 beta feels first-class. We have implemented a custom binary network serialization protocol (which makes heavy use of generics magic) as a shared C# library and have no issues whatsoever.

The classic gotchas of storing Godot related properties in a local variable to avoid (expensive) interop when e.g. doing a for loop are obvious if you're coming from Unity and a non-issue (personally speaking), documentation of this gotcha would help though.
The usage of C# events is awesome and seamless, switching to the new trampoline based Callable in the new beta worked without issues as well.

I can't give enough props for how good the engine feels in C# as we were especially looking for a strongly typed language to build our game. NativeAOT will be awesome in the future as well.

Is there any way an individual could contribute to Godot, specifically in regards to the C# integration? How would one go about this?

[Calinou]

if you're coming from Unity and a non-issue (personally speaking), documentation of this gotcha would help though.

Feel free to open a pull request for this 🙂

This caveat should be added in the Performance section of C# basics and Cross-language scripting.

[roookeee]

Took some time but I finally got around to opening a PR for this.

[Clonkex]

I've been using C# for a while in 3.x and the 4.0 betas and I've been loving it! It just works in the vast majority of situations (custom resources being the big exception, as you say). I especially love the fact that using C# has made it easy to use a custom physics engine (Bepu), which is important to me because I need lots of control over the physics for networking and rollback.

My only real complaint is that it's confusing to understand the relationship between nodes and scripts, but that's not specifically a C# issue, only compounded by C#: You create a node and attach a script, but at runtime the node is actually just an instance of the script's contained class? I mean, it makes sense if you describe it like that (the editor-facing node is a container for the properties that will be applied to the instance of the script's contained class at runtime) but it's confusing to understand as a beginner. I suppose it's not so different from Unity's components in that it looks for a class matching the script's filename, but it's a bit wonky in that you have to ensure the node is of the same type as the one the script's class derives (defining the node type in two places). It would be much more intuitive if a node of any type just switched to the parent node class of a script when you attach the script.

But once you get your head around that it's a breeze to work with!

[RIKDXHQ11]

I am using GDScript not because GDScript is great, but because it rarely makes mistakes, because the engine support is good, but I feel that the official support for C# is relatively cold, and it looks like a stepmother's daughter.
I made some mistakes in version 3.23, but later I had to give up C#,
I used to be a user of UNITY before using GODOT. UNITY used to have two languages, JS and C#. Later, JS was gradually abandoned and now only uses C# programming.
I think C# is a great language, and it should not be ignored, because many users of UNITY are considering using the C# version of GODOT, even though its father is Microsoft. If GODOT can optimize and support C# in 4.0, I would be happy to join the list of C# users. With the help documentation and support getting better and better, I think others will join it in succession. thank you!

[RIKDXHQ11]

I recently submitted an error and crash report. You can see it in the error report area. It crashed the operating system,
If I do not apply GODOT4.0, my computer is normal. I am very suspicious that it is caused by the instability of the C # engine, or it may be because the new engine uses Vulkan. I heard that if there is a BUG in VK, the system will strike.

[RIKDXHQ11]

I know BOO, but I'm not interested in it.
In fact, I have two versions of GODOT, one is the GD script, and the other is the C # version. I have rewritten the C # code.
The experience is still poor. GD scripts can directly use the editor in the engine, and have the function of automatically completing code. However, C # has poor support. You can only use an external editor, and the support for signals is weak. When signals are sent, even when they are connected, they are blank and will not generate any code for you (the engine just jumps to the VS editor for you).
When using UNITY, I am happy to use C #, but when I use GODOT, I think they still need to work hard to improve it.

[lewiji]

The experience is still poor. GD scripts can directly use the editor in the engine, and have the function of automatically completing code. However, C # has poor support. You can only use an external editor, and the support for signals is weak. When signals are sent, even when they are connected, they are blank and will not generate any code for you (the engine just jumps to the VS editor for you).

Personally I think that being able to leverage professional grade tools like specialist IDEs is one of the strengths of using C# in Godot, and I much prefer the workflow of being able to run my project directly from an ide and only have the editor running when I need it. I think it could be made clearer to the user that this is the expectation as probably many newcomers to godot and C# will start writing scripts in the built in editor and wonder why it doesn't auto complete etc.

Now, even if intellisense and analyzers and stuff were implemented into Godot's editor I would still use an external IDE, and I feel like most experienced C# devs would feel similarly. Why spend loads of time reinventing the wheel when these tools and the larger C# ecosystem exist already and will always be light years ahead of any attempt Godot makes to replicate the experience.

I also think that Unity devs coming over to Godot will be used to using an external IDE and won't find it a problem. But perhaps the editor could warn the user in the script tab when editing a C# file internally that better tools should he used.

As for signals, personally I never used the editor UI to connect signals, since you can connect them in code very reliably, and with Godot 4 now using C# native event syntax for signals it makes even more sense just to handle that in C# code where it's clear what the intent is, and the connection isn't buried in some .tscn file somewhere. Maybe this could be made clearer as an option in the intro tutorials.

[RIKDXHQ11]

Maybe for you, you are used to handwritten code, but for me, if GD script can directly generate code, but C # can't,
This already shows that C # is not paid as well as GD script, so I hope the production team can improve it. At the very least, they should generate the code corresponding to the signal after the jump. Whether to use handwritten code depends on the user.

[lewiji]

Maybe for you, you are used to handwritten code, but for me, if GD script can directly generate code, but C # can't,
This already shows that C # is not paid as well as GD script, so I hope the production team can improve it. At the very least, they should generate the code corresponding to the signal after the jump. Whether to use handwritten code depends on the user.

At least part of the reason is that with the expectation that you'll use an external IDE comes the problem that you probably don't want to start modifying files that are open in another program that might not be saved, because you'll end up overwriting the unsaved work and run into reloading issues. I don't think this has anything to do with the idea that C# support is somehow lacking compared to gdscript, or that these features have some sort of paid incentive (? spoiler: most of the work on godot is voluntary).

There's nothing else in godot I can think of that generates code like that, maybe godot could warn the user if they connect a signal to a c# script (or any other language) and link to examples. But it's basically a one off thing a new user will run into, figure out how to write the code, and then just write it from then on.

[Mantissa-23]

So... After giving Godot 4 Beta 7's Mono build a whirl, I'm having trouble seeing what people are talking about with C# being a second class citizen.

I'm getting a feeling this is more of an appearances, documentation and tutorialization issue than anything. Most of the examples are in GDScript, and if you're even a journeyman in your programming career, it's pretty trivial to translate them to C#.

But for lots of users, especially the indie dev audience Godot attracts, Godot is their first introduction to programming. Hence the strong bias towards GDScript in user share. It's Pythonic, dynamically typed, has no build step, and lots of examples and tutorials.

I feel like this is reinforced by all the negative comments that just kinda say "C# is bad in Godot" without backing it up. I'd love to see a bullet point list of problems.

I'll be using C# for my upcoming projects. The allure of stronger typing, a more mature language, and leveraging the .NET ecosystem far outweighs any minor ragged edges. I can't just import a library for dual countouring or utility AI in GDScript like I can in C#.

[GeorgeS2019]

VS2022 for Godot4 .NET6 is working. However, we need to keep improving the experience

Ideally, we need a hybrid test-driven environment that could test how GDscript and c# interoperability @MikeSchulze

[GeorgeS2019]

@lewiji @MikeSchulze Ideally eventually we have a test-driven framework to improve NativeAOT development process in Godot

[filipworksdev]

Every year is the exact same answer 81% of people use GDScript .

Right now C# is pretty well integrated and supported by Godot meanwhile GDScript still lacks some of the most basic functionality for example inability to extend basic classes, no private modifier, no nullable types and a lot more ..

Also if we're looking at performance both C# and GDScript what ends up happening is Godot's slow api will bring C# performance down while GDScript ends up faster . So for code that makes a lot of api calls both C# and GDScript end up around same performance.

The real bottleneck is Godot's api calls. The way Godot is written with everything marshalled though Variant class and very slow internal datatypes I think that's where it needs more.

Godot's api should be re-written with better more modern and more streamlined code. GDScript should have feature parity with LuaJIT. And C# with only 14% of users should not even be an officially supported language. It should be a GDExtension supported by the community like Nim, Rust C++ etc

[peti29]

This is a very bad way to look at it.

I'm just getting to know Godot. Which language do I use? GDScript. Why? Because my (parobably less then well informed) impression is that I can save myself a lot of trouble (you know on top of not knowing how everything is supposed to work) when sticking to it rather than C#.

Meanwhile I'm a professional C# developer and would naturally prefer using that for Godot instead of having to learn a new language.

[azur-wolve]

don't agree with C# being not officially supported
its the best option lang aside the built-in solution (GDScript)

don't take those polls too literally, they only give some approx.

[cyraid]

You can't trust those stats, because currently most of the addons and such assume people use original godot editor and not the .net version, seeing as it's safer to use gdscript in plugins as both versions of the editor will have gdscript. Until you have a unified editor that supports .net and gdscript and not biasing gdscript, then another poll could be done. There has also been a lot more converts from Unity since the whole Unity debacle, so having another poll would benefit.

[Shadowblitz16]

Also gdscript has a build in editor with auto complete and syntax highlighting, C# requires installing a 3rd party editor and switching between the two applications which is a severe productivity kill.
Also C# doesn't have very good support it requires partial classes, most thing's are tied to strings, and godot's C# collections suck.
Emitting signals isn't 1:1 either.
There is probably more, but no C# is not as good as it could be.

[lewiji]

Also gdscript has a build in editor with auto complete and syntax highlighting, C# requires installing a 3rd party editor and switching between the two applications which is a severe productivity kill.

Working with external IDEs has been standard in gamedev for a long time - in most areas of development, actually, for example, you dont tend to code web applications in the browser. Personally, I prefer using an external editor even for gdscript, in fact, I don't even have the godot editor open much these days. The extra tools for refactoring, testing, and code generation/templating that an IDE gives you is a severe productivity boost.

Also C# doesn't have very good support it requires partial classes, most thing's are tied to strings, and godot's C# collections suck.

Why are partial classes a problem? They're pretty standard for code generation support these days. Godot 4's api has much less requirement for strings than Godot 3's, the partial classes allows Godot to generate static members for all signals, method names, property names, etc. Things that are truly dynamic such as animation names should use const or readonly StringNames rather than string literals. If you're using string literals, there's usually a better more type safe way to do it.

And yeah, Godot's C# collections are slow and lack a few things compared to .NET's system/generic collections - but it's simply a limitation of having to communicate across a managed/unmanaged bridge, you have the same problem in any engine that uses this scripting paradigm. But once you understand that, and know how to separate things out from your own performance intensive "pure" C# code, and godot api access, so using .NET collections for performance and then moving data into the godot api separately only when necessary. Also, using Packed Array types in godot allows you to pass in primitive C# arrays, eg a PackedByteArray will work with a byte[] array, allowing you to build out more performance intensive data transfer where needed via buffer copies/refs/unsafe etc.

Emitting signals isn't 1:1 either.

I'm not sure what you mean by this exactly, but everything you can do in gdscript with signals you can do in C#, plus with C# you actually get more flexibility via lambdas/delegates. You can use native event syntax or you can use the .Connect() API.

[BenMcLean]

Android support is available and iOS support is being worked on

Yeah I should have mentioned that it's being worked on. That is definitely a valid point and I applaud the work on bringing C# Android back to Godot.

There are plenty of reasons, the primary one is better integrated and serves the specific needs of the engine better

What specific needs do game engines have that make them so unique as to require their own language? I can see why shaders need their own language since they have a different hardware architecture, but a game engine is just connecting the game dev's scripting code to the underlying input, graphics and sound hardware and there's no way a small independent team is going to beat decades of work by multi-million or even billion dollar companies in the area of language design or language optimization. I do not mean any offense at all to the Godot team but it seems like they should focus on where they can bring the most benefit to the world and that isn't going to be in building a better language.

you also have to balance functionality that has little to no use in a game engine that is in a pre-existing language

Such as?

I am not meaning to be sarcastic here.

[BenMcLean]

Anyone who really wanted complete ultimate control would be writing their own engine for each game in C++, C or even assembly.

I don't start from choosing an engine and then a language. I start from wanting to write it in C# and then go looking for what game engines support C#. And that isn't even necessarily Godot: I've also been looking into Raylib for future projects.

Godot needs official, first party C# support (whether that's through GDExtension or directly) because that's going to drive game industry adoption, picking up people with Unity and Unreal experience.

[filipworksdev]

I disagree that the ultimate control is to make your own game engine in C/C++ or assembly in 2023. Today that's a waste of time. The best thing you can do right now is learn C++ and start with an engine that already exist sand is open source and modify it to fit your needs. I think Godot's open source nature is way better than it's C# support.

[BenMcLean]

Yeah well, this would be the point where you are objectively wrong in a way we can check, because of what the words "complete" and "ultimate" mean.

[filipworksdev]

I think you're going offtopic .

[azur-wolve]

not all users have computer programming background
GDScript is easy to pickup and get stuff working
and also the extra performance isn't needed in the majority of the project codebase

the lacking language features are a small penalty in pro of simplicity and cleanness.
If need more, just pick C#, C++, Rust or whatever

[GeorgeS2019]

One can use GDScript immediately to access GDExtension and NOT c# NOW ==> this is an unfortunate lower priorty!.

[GeorgeS2019]

We have to be VERY careful with this sort of this discussion which suggest lower priority of c#.

[GeorgeS2019]

@akien-mga

I think it is important to address how this discussion is being hijacked here after the recent discussion on a better GDExtension for c# is closed.

[akien-mga]

People are free to discuss as long as it's civil. That doesn't mean project priorities will change. This discussion is too broad anyway from the start and hardly actionable, so it's fine if it's used as a general C# related chat room.

Real actionables should be written as formal proposals, ideally by the people who intend to do the work.

I haven't read it all, but all the discussion on whether C# should be supported or GDScript dropped is pointless. We've already made our position clear many times.

GDScript is great and will stay first class. C# is also great for different users and use cases and we're working on making it better integrated and perfomant. These things take time, we got good input, further discussion isn't particularly productive but we respect that folks need at outlet for their views and concerns on language support.

[RIKDXHQ11]

I think you can use vs2022 to write games out of thin air. Yes, there is no need to use godot. It is redundant, you only need a compiler. After compilation, it is AOT, which can convert the code to binary. It is faster and does not require completely immature support through godot. It is not necessary, early games did not require an engine, and now it is not actually needed. You need to be familiar with D3D12 instead of godot.
In addition, UE does not support C #, they are still C++, and C # support is not favored by the official.
UE has exposed local code and does not require slower C # for intermediate layer construction.

[Mantissa-23]

I just want to put this comment in here for anyone who is thinking about using Godot 4 + C# or thinking about switching from GDScript to C#, and then sees this 130 reply thread and gets cold feet-

C# is more than usable as of November 2023. Don't be too discouraged. Still think about your decision, but there's a lot of out-of-date information in this thread. There are definitely places where it is missing features compared to GDScript:

• currently no mobile builds for 4.x, but this is actively being worked on and will likely be ready before your game is
• editor-integrated debugging and profiling
• lack of docstring integration with editor/inspector
• some bugs with language features like inheritance from generics

But those features are nice-to-have (don't get me wrong, some are really nice to have, but still not critical), or corner-case bugs.

And nobody ever seems to mention the things GDScript is missing which C# has:

• nullish coallescing, optional chaining
• destructuring
• greater performance in isolation, and nearly on-par performance with engine-interfacing code in spite of marshaling
• interfaces
• the entire .NET ecosystem and all of its documentation
• proper static typechecks including compile-time null checks
• linting/formatting/a language server that is mature
• enum flags
• native support for popular technologies relevant to gamedev like SQLite and Protobuf just to name a few
• collections like Set, SortedList, Stack and Queue which GDScript either will never have or won't have for a long time
• probably like 50 other things I haven't encountered yet

C# used to have major issues, like really poor compiler messages and error messages, no helpful documentation, etc., but those have all been fixed. A lot of people complain about C#'s lack of documentation, but I would argue for the target audience (people who aren't completely new to game development or who are non-programmers), that's fine. I've been finding that my text editor's linting, hints and goto-definition have been more than sufficient documentation. There would be definite value in improving the availability of C# code snippets in the official documentation, given the recent Unity mass exodus, but it's not like there is no documentation- The C# doc pages are comprehensive and mention all of the caveats and differences to the GDScript API. Other than these clearly documented caveats, the C# API is almost identical to the GDScript API, in a really impressive way.

Some people will disagree with me, I would argue that they are purists overly obsessed with perfection. GDScript is a tool that just works. C# is also, as of November 2023, a tool that just works. Both have their problems. Each is suited for a different kind of developer; GDScript is best for new users and non-career programmers, while C# is best for those with prior C#/.NET experience and generally those who are more focused on programming and the features one would expect out of a modern language.

Hell, if it would help the community, I will gladly make a flowchart for the docs to help new users decide between the many different languages Godot supports. This is no longer a complicated decision. There is more to discuss, but that's the case with GDScript too.

[AThousandShips]

currently no mobile builds for 4.x, but this is actively being worked on and will likely be ready before your game is

Only true for 4.1, it is supported for 4.2 (godotengine/godot#73257 and godotengine/godot#82729) (is scheduled for release in a few days)

some bugs with language features like inheritance from generics

Not really something under "missing features compared to GDScript" as this is not supported in GDScript

[Damnae]

Most problems I have with C# are centered around data being lost when the solution is rebuilt.

Writing a C# [Tool] is particularly painful. From what I understand, my object is silently discarded and a new object is made, its private fields are overridden with the old one's values, BUT only if they were convertible to Variant. This causes so many problems:

• I can't use a struct/class to structure data inside my resource, it's not a Variant all its data will be lost.
  

• It breaks encapsulation by writing my private variables directly and skipping my properties. If can't use a struct/class to structure data, because it's not a Variant, I'll use a Variant that can structure data: a sub Resource. But since I need to know when its values are changed I need an event on that sub Resource. After rebuilding the solution my event isn't set anymore.
  

• So I can't have structured data, I get it, I split my data into multiple arrays:
  
  Not only it looks cursed, but I can't use int[] or it won't survive solution rebuild, I'm forced to use Array.. which doesn't have an initial size initializing parameter, so I have to give each of them a dummy array to set their size.

• Surely at least it works now? Not really, there's no event that tells my resource that it's been reloaded, so it cannot act and stays in a broken state until I toggle one of its property to force it to refresh.

[lewiji]

Writing a C# [Tool] is particularly painful. From what I understand, my object is silently discarded and a new object is made, its private fields are overridden with the old one's values, BUT only if they were convertible to Variant.

I'm not sure if this is Godot, or a fundamental behaviour of .NET hot reload. Either way, yeah, it is a pain sometimes. Mind you, when writing gdscript plugins I seem to run into similar issues with lost/reset state, so it may be more fundamental than just C# types/build system.

I'll use a Variant that can structure data: a sub Resource. But since I need to know when its values are changed I need an event on that sub Resource. After rebuilding the solution my event isn't set anymore.

Resources have a built in Changed signal which you have to manually emit when you deem necessary - you can then subscribe to this elsewhere. If that's what you were doing already, perhaps you experienced the bug when assigning signal callbacks with the += event syntax which has been hanging around recent versions - its better to use the more verbose method of calling .Connect and constructing a Callable with Callable.From at the moment until that's fixed.

Not only it looks cursed, but I can't use int[] or it won't survive solution rebuild, I'm forced to use Array.. which doesn't have an initial size initializing parameter, so I have to give each of them a dummy array to set their size.

It would be nice if Godot exposed the PackedIntArray etc types in the GodotSharp namespace as they serve that purpose internally/in gdscript. Other areas of the API that expect a Packed Array type do accept C# native arrays, so it's a shame that functionality is missed in exported properties (unless there's some way I'm unaware of)

• Surely at least it works now? Not really, there's no event that tells my resource that it's been reloaded, so it cannot act and stays in a broken state until I toggle one of its property to force it to refresh.

Unsure, but there may be a compiler event on the .NET side to indicate hot reload has occurred. Definitely could do with that being exposed in Godot if so, it'd be useful.

[xerothermic06]

Throwing one more largely-anecdotal comment on the pile here. Small-time one-person dev for context.

TL;DR: using Godot ~4 years w/ GDScript only, started using C#, opinion of engine improves enormously, still in love after honeymoon period.

I've been using Godot heavily since 2020 and have struggled to make more than a few stray tech demos and half-finished jam ideas, primarily all 3D stuff. Every single project I've started to date usually ends up in a half-finished, unplayable state, and the major reason I'd pin it on is that I was writing the entire thing in GDScript. It's an excellent scripting language, incredibly impressive and ambitious for an open-source project, but very much not what I'd want to scaffolding a large, complicated codebase. It has some great features but the ones it's missing (no protocol/trait/interfaces, lack of a large dependency ecosystem like NPM or Maven, no type safety for signals, just to name a few) make it unsuitable for my needs.

I was completely new to C#, but this year I've started a new project with a mix of mostly C# and a small amount of supporting GDScript, and I've absolutely loved it so far. I've had significant experience with a laundry list of popular languages and I've never used one with the amenities of C#. Just a couple weeks ago I hacked together an emulation of Unity's MonoBehaviour/GetComponent paradigm for Godot using generics and attributes, and it works amazingly. The pain points of Godot's C# integration are significant but, in my opinion, absolutely worth pushing through. Based on my needs and wants, using C++ for native extensions would be the most obvious fallback, but SCons builds significantly slower than dotnet and, hot take, C++ has a very hostile experience compared to C#. The godot-rust people are doing extremely fine work and I'm enthusiastic about it, but it's far from production-ready.

I've never felt so confident about any of my projects until I started using Godot's C# integration. If it were to go away in future major Godot versions or transition into a non-officially supported GDExtension, I would find a way to keep using it. In any case I would never, ever, ever attempt to scaffold an entire project around GDScript again, so I would implore the powers that be to retain official C# support. I've always said I wouldn't consider using any other engine than Godot for its extremely good suite of existing features, and C# just made me dig my heels in another 10 feet or so.

[azur-wolve]

the plans are to keep official C# support
and eventually only have a single Godot Editor version instead of the standard and the C# versions

with all the Unity Engine refugees C# support on Godot only can improve from now forward