Choosing Between C# and GDScript in Godot

If you're looking to get into the Godot game engine, you might be faced with an immediate decision: do I use GDScript or C#? The answer, as always, is "it depends", but there are a few factors that might help you decide which way to go, and in this blog post I'd like to collect some thoughts together to help inform others on why they might use one or the other (or, perhaps both).

Who are you?

Are you new to programming? If so, GDScript is very beginner-friendly due to its simplicity and aesthetic similarity to Python, which is one of the most popular programming languages being taught to complete newcomers. It is much more concise and can feel more natural to people who are unfamiliar with other traditional programming languages. As someone who has used C# for a number of years, I can say that it has a much steeper learning curve for someone new to programming due the number of features and keywords it has accumulated over the years at the language design level. If your goal is to just get started and to program in Godot, then I think GDScript is a no brainer. However, if you have ambitions to learn programming in other areas, such as web or native development, C# is definitely a great language to consider investing the time to learn.

Are you a seasoned programmer looking to get into gamedev? I think the choice is a little bit more nuanced here because your taste in programming languages will have likely been influenced by what you work with and enjoy using already. To many experienced developers, GDScript is lacking in a number of features they might want that are already available in C#, such as interfaces and abstract classes, generics, stronger typing, access modifiers like private and public, extension methods, namespaces, (better) pattern matching, and a whole host of other things you might be missing in a different language. I think if you are used to developing software with these sorts of features you will likely be much happier in C#.

That being said, it's worth pointing out that GDScript has evolved a lot over time, and many features it was lacking before have been added over time. GDScript 2.0 brought in a stronger type system, annotations, lambda functions, basic pattern matching, named and default parameters, and support for getter/setter syntax that works similar to C#'s. In short, GDScript will get better, but there may be features that are never implemented, or will take a long time to implement. If you are okay with that and feel satisfied with what's available, then GDScript might be what makes sense for you.

One other aspect that ties into this topic is tooling. With C#, you are pretty much guaranteed to need to use an external text editor or IDE, and for many beginners this can be intimidating. In comparison, Godot's built-in editor is pretty great for writing GDScript, and while it still doesn't compare favorably to tools like Rider, VSCode, Neovim, Emacs, etc, it's entirely possible to be happy writing code in the editor and enjoy an out of the box debugging experience and (slightly) faster iteration loop, with the added bonus of being able to drag-and-drop nodes into your editor.

What are you making?

The kind of game can influence your choice as well. While it's entirely manageable to write large, complex games with GDScript, C# has a number of features that can help make some of this easier, such as the aforementioned interfaces, generics, and namespaces. These features help with code re-use and encapsulation, but they come at the cost of possibly over-engineering your solutions in pursuit of crafting the "perfrect code" instead of finishing the game. In this way GDScript's simplicity, while possibly frustrating at times, can make it easier to focus on accomplishing development goals. This may sound pedantic, but I've seen this when working in languages with less features versus languages that supported a lot of advanced features, and often times it's hard to strike a balance between reinventing the wheel, perfecting your codebase, and getting stuff done.

Beyond language features there are also some differences in platforms. For instance, if your goal is to publish a game on the web or you plan to use a web version of your game for demoing, marketing, or playtesting, then as of 10/2024 C# is still not supported for web exports, and so GDScript is the only game in town; this will likely change in the future, as mobile exports were also in a similar situation and now support C# as of Godot 4.2. For consoles there are also a few differences depending on who you might be using. A list of some options are available here on the official documentation. According to the W4 Games porting page, the company employing some of the core developers of Godot that offers various paid services and support, they consider their support for C# to be beta. Some other porting houses don't list support for C# or may only target certain platforms, so definitely do your research and make sure this won't be an issue for you.

Ultimately, your target platform will impact your choice for the immediate future, but it's highly likely that in the next few releases of Godot there won't be as many differences as there are now, and some of this just comes down to whether or not the .NET project addresses certain blockers that help the Godot project move forward. If you just want to focus on a standard Windows, Mac, and Linux release and understand the limitations, then either language should suffice.

Beyond Gameplay

One aspect that can be overlooked but could be very critical in your decision are the features you're trying to implement and whether or not you can leverage third-party libraries to facilitate developing those features. This is one area where C# simply wins: being a general-purpose language, there are an incredible amount of useful NuGet packages that can be installed to do things that would otherwise require a significant amount of effort to implement in GDScript simply because the community is much smaller and newer. This includes libraries for more general things like working with databases and YAML serialization, or things tied directly to the game itself, including ECS (entity component system) and rollback netcode.

This isn't including a lot of the other great things that come with .NET, including ASP.NET, which could also be used to create back-end services for parts of your game, such as auth or stat tracking, allowing you to use C# for all of your needs and possibly do some code sharing.

If none of this sounds useful or interesting, then it's probably not going to change your mind either. I do want to point out that there are definitely a number of cool and useful GDScript libraries, including GDUnit (which also works with C#), Dialogic, godot-console, and Beehave, and the community is definitely getting larger.

Performance

It is very hard to find any sort of definitive performance benchmarking between GDScript and C# in Godot 4.x. In most discussions about performance between the two, you'll find most people will say C# is faster in almost every case. But by how much? It seems to vary, and with each iteration of Godot the gap seemingly closes a little bit each time. Depending on the solution being implemented, GDScript might perform very similarly to C#, but in other situations it might be significantly outperformed. Until someone does in-depth performance benchmarks that aren't surface-level comparisons between the two, it's going to be hard to say how much of a difference there is. One thing to keep in mind is that GDExtension will be faster than C# anyways, so even C# has a gap to close.

The main takeaway from thinking about performance in game development is that unless you have a very clear idea of why you might have performance issues based on your game design, it's more likely you will hit a non-technical bottleneck sooner than a technical one, so I wouldn't put too much thought into it unless. Should you have a strong understanding of your problem domain and have concerns that GDScript might not cut it, it would make sense to prototype the worst case scenario in both languages and see how much of a difference it makes.

Conclusion

It's important to note that you can also use both languages in a single project. Godot offers interop between scripting languages, which allows developers to write most of their code in one language and rely on the other for specific areas. In areas like working with the UI, a C#-focused developer may be more interested in reaching for GDScript due to its more concise nature, or maybe you want to use C# in your GDScript project for performance-sensitive areas that you found to be too slow for GDScript to handle. This feature isn't exactly painless, but it is available and could prove to be very useful to the right kind of project.

One other thing I didn't mention is that you can also choose even more languages. While not a complete or updated look at what's available, this GitHub repo gives you an idea of how many languages that have bindings to Godot are out there, and there are likely even more that aren't in this list. The ability to leverage a language you are already familiar with can be highly motivating to someone who just wants to focus on the game development aspects of working in Godot, but keep in mind that you will always have a much harder time finding support when you inevitably encouter an issue, so unless you are already very familiar with the risks then I would recommend sticking to GDScript or C#.

Hopefully this article helps someone new to Godot decide on which path they want to embark on when learning the engine. You can always try both out and see what you like, but for many people they will simply use what they know or what's popular. GDScript usage seems to be in the vast majority, which almost every tutorial, course, or book being written with GDScript, but as C# support has gotten better and more folks experienced with Unity start trying out Godot, those numbers will shift around a little bit, and there has definitely been more interest in C# Godot content creation as more folks from Unity come over to Godot. The main thing you should also realize is that no matter what you pick, your knowledge of Godot and how to use it will transfer over, so don't feel too stressed out if you end up deciding something isn't for you.