Is Godot Gradually Adopting C# as Its Primary Programming Language?

If I was interested in creating an FPS I would move wholesale in Unreal it really is the only choice, I have been there and done that. Looks great, performance is great, so many great assets, I was using Unreal 4 and my goodness was that thing was buggy, sometimes I lost up to 2 weeks work, and it tested your patience. Change a line in code - recompile, another change recompile, made a syntax error fix and recompile. I don’t know how to use GitHub, so I had to backup manually and just when a backup was becoming necessary crashola. You could be something easy that shouldn’t have any effect and boom gone.

At the moment my needs are very simple creating a 2d platform game only with all the features that my Unity game had before it corrupted itself into oblivion many moons ago, the next day I jumped into Unreal for a 1st and 3rd person shooter. While there are some things in gscript I don’t like I am prepared to stick with it for now.

2 Likes

Mono is an open source implementation of Microsoft’s .NET Framework
Mono uses C# and other .Net languages as well
Unity still uses the mono run-time, so i don’t understand when you say Unity transitioned from Mono to C#, please explain.
On the Godot side of things i hope GDScript will be always the Godot scripting language of choice, I really like GDScript and the internal editor.

2 Likes

Unity once had a proprietary language called “UnityScript”. Unity also once supported a language called Boo (https://boo-language.github.io/). You can read a bit about Unity’s support (and deprecation) of both here: UnityScript’s long ride off into the sunset | Unity Blog

Anyway, just as a data point, my team migrate away from Unity, and we are quite excited to NOT use C#. As convenient as C# is in many ways, we often found ourselves fighting the garbage collector and dealing with annoying memory allocation quirks.

Our intention in Godot is to write code in C++ (using GDExtension or direct engine modification), and treat GDScript as the engine’s scripting language (which, you know…it is).

3 Likes

I dislike dynamic typing but gameplay development is quick iteration; making and dropping things as fast as possible, game-specific editor tools, fast compiling and hot-reloading. Strictness gets in the way.

Performance is directly related to memory management and processing. You will need languages with low-level and strict memory management for this. C++ was made so easy to use with Godot that it doesn’t make sense to use C# if your goal is really performance. I would use Rust as alternative to C++ for more syntax sugar and modern features.

I like C# features yet I go with GDScript for 90% of the game, gameplay, and editor tools and C++ for data-oriented systems such as procedural generation, simulation, and anything like the engine’s low-level work. Would mix in C# too since languages are just modules, but honestly the only use case is to use .NET libs.

1 Like

you know if you dislike dynamic typing, you can just cast variables with type…I mean, not sure why this is an issue. It’s not like dynamic typing is mandatory.

3 Likes

I’m not sure what you mean dynamic typing is not mandatory. It’s not like GDScript was designed for types. Types are a second-class feature in any dynamic language.

Dynamic typing is mandatory when you want contract-like functions because we use strings and duck typing to simulate interfaces. It is also mandatory in many API methods that use strings as type hints, dictionaries as structs, and Variants. It is required if you don’t want conflicts in the global namespace because we can’t define type aliases so we preload scripts without giving them class names. Also to avoid parser errors such as references to editor class because their types are removed when you export a project but there is no feature to remove snippets of editor code as we would do with C++/C# preprocessors.

There are many other cases you can run at because GDScript and the API were designed around reflection, not types. However, as I pointed out, the dynamic nature is ideal for faster iteration and there is no need to change it. I just don’t like coding anything besides gameplay or small-scope tools with it.

1 Like

Oh well, I agree with this about 99%…I don’t like using GDScript for things covered under the System.IO, Collections, and Collections.Generic names spaces. C# or C++ are far better choices if your collections of any significant size. But for methods and properties that access the GD space, I wouldn’t use anything except GDscript.

1 Like

My personal chain of thought:

  1. Use GDScript.
  2. Identified a bottleneck? Use the profiler to find the problem.
  3. Is it a language problem? Use GDExtension.

I can use GDExtension with Rust (my main language), as well as C++ and Go.

And yeah, I’d rather use any of the above over C# :upside_down_face: (even if C# is better integrated).

3 Likes

Just because someone likes C# so much because of a .NET bloated Unity doesn’t mean we all have to be forced into it. I prefer the lean and mean Gdscript. It integrates beautifully, more readable, and is more efficient than C#, because the underlying code is C++ anyway. Don’t make the mistake of following MS and .net into bloatware.

1 Like

I prefer C# because I prefer object-oriented paradigms over more linear approaches. I find it to be cleaner and more maintainable, and consequently more “fun” in the long run (bigger games with longer development cycles). GDScript, to me, feels more like the BASIC programs I grew up writing. They were quick, fun, and encouraged dubious programming practices. I’m not going to say people shouldn’t use it, just that it isn’t for me.

Having said that, I love the idea that Godot has multiple options. C#, C++ and similar languages are more likely to prevent beginners and hobbyists from learning the craft than to draw them into it. I was already a professional developer when I made my first game 20 years ago, but I probably wouldn’t have bothered if GameMaker hadn’t been so user-friendly at the time.

I also like the idea that I can write some quick and dirty code in GDScript just to make sure my nodes/animations/etc. are set up correctly before dealing with the maintenance of setting up a C# hierarchy.

So I hope the parallel language options remain a thing. I believe it is not only a strength, but it is something that sets Godot apart.

2 Likes

I prefer C# because I prefer object-oriented paradigms over more linear approaches.

GDScript is object oriented.

2 Likes

Yes, but not to the extent C# is.

1 Like

C# has more quality of life features, but you were implying that you didn’t like GDScript because you thought it wasn’t OOP.

I wasn’t implying that it wasn’t OOP. I said that it doesn’t emphasize OOP paradigms the way C# does.

1 Like

Honestly, gdscript seems easy to pickup for someone used to C# anyways. Just focus on making things well organized and readable. Keep things simple and don’t overcomplicate things.

1 Like

Just a little note on this: GDExtension is notably slower than C#/.NET 8, especially godot-rust. The FFI layer is a real turtle there, taking almost 8x longer for any engine API call compared to C#. The current Godot 4 C# implementation is quite special and even faster than C++ GDExtensions for API calls. I learned that the hard way mid-production.

For general data processing, C++, Rust and C# are about the same speed, so this only matters if you are planning to write actual gameplay code or if you need to pass a lot of data around between the engine and your extension.

1 Like

That’s so odd.

Good info tho, ty.