GDScript vs C# in Godot 4 | Chickensoft — Open source tools for Godot and C# (2024)

Almost every day, someone asks "Should I use GDScript or C# to make my Godot game?"

A lot of amazing advice has been given out on the Godot Reddit, the forums, various Discord servers, and just about anywhere people are talking about Godot — so let's write it up, once and for all!

In this article, we’ll take a deep dive into the advantages and disadvantages of GDScript and C# in Godot 4.x, as well as tips on how to choose one — or use them both!

🤖 GDScript​

As you likely know, Godot provides its own high-level, dynamically typed programming language called GDScript. While GDScript often gets compared to Python, I find the syntax to be even friendlier, with optional type hints that are also reminiscent of TypeScript or Swift.

For quick prototypes and experiments, I will often just throw together a quick script using GDScript (or hack away on someone else's) until I get what I want. In almost every case, it is simply easier and faster to use GDScript.

If you happen to be handy with C++ or Rust, you can create a GDExtension for just about anything you can't do in GDScript (or that would be too slow to do in GDScript). Godot will generate bindings for extensions, allowing you to call your extension code from GDScript with no additional work. Pretty magical!

To sweeten the deal further, Godot 4 has drastically improved GDScript: it's considerably faster, can handle circular/cyclic dependencies, and supports lambda functions. On top of all that, just about every tutorial or video you watch regarding Godot uses GDScript.

If you're not sold yet, there probably isn't anything else I can say to get you to use it.

☀️ GDScript Pros​

• 🚀 Incredibly easy to learn and well supported.
• 🤝 Many large, friendly communities that provide hands-on support.
• 📚 Tons of tutorials and videos.
• 🥳 Supports every platform Godot supports.
• ✨ Always up-to-date with the latest Godot features.
• 🔌 Perfect native extension integration.
• 🪛 Tooling support — you can write GDScript directly inside the Godot Engine's editor, or use the official VSCode extension. You can even get a VSCode extension for formatting your GDScript files, too.

🌧 GDScript Cons​

So what's the catch with GDScript? Not much, really, but I'll list a few considerations to be aware of here:

• 💨 Not necessarily as performant as C#. There is a performance penalty when calling into the Godot engine from C# due to marshalling, but C# itself tends to execute considerably faster than GDScript.
• 🔒 Any code written in GDScript is completely specific to the Godot engine. This is usually not a problem for game scripts (since they are not very portable by nature), but it's worth mentioning.
• ⬜️ Whitespace-delimited syntax. If you can't stand Python or just strongly prefer curly braces, no amount of GDScript will ever soothe your soul. Likewise, if you love whitespace-delimited syntax, you'll feel right at home.
• ⚡️ Not statically typed. While you can specify type hints to help with error-checking, they are optional at best. For some, this is an advantage. For others, the lack of enforced static typing presents a headache.

For the majority of game developers I've spoken to, none of those are typically deal-breakers. GDScript has a cult following for a reason: it's really, really great. Now that you know its strengths and weaknesses, you can feel confident choosing it.

Still not convinced? Let's talk about C#.

#️⃣ C#​

While not as popular as GDScript, C# support in Godot has come a long ways. Out of the approximately 5,000 surveyed users, only about 13% said they were using C# to build Godot games.

🌧 C# Cons​

Before we get too far, it's worth reiterating a couple of points:

• ❌ Godot can't export C# games for iOS or web.
• ❌ You cannot call GDExtensions directly from C#.

If either of those are an immediate must-have for your project, you should not use C#. Unless you are optimistic and believe those shortcomings will be addressed by the time your project requires them, you should use GDScript or a third party language integration instead.

☀️ C# Pros​

Because C# is a general-purpose programming language that first appeared 23 years ago, it is hard to fully extol its virtues. In the interest of time, I'll list a few positives within the context of Godot game development:

• 🚀 C# is a well-established language with the full weight of Microsoft behind it. If you've ever used Java or Dart, you'll also feel right at home.
• 🛠 Incredible tooling support. Want to create a custom analyzer with an automatic fix? A source generator? A template project? You can do that.
• 🧑‍💻 Choice of IDE's: You can use Visual Studio, JetBrains Rider, or Visual Studio Code.
• 📦 The entire .NET package ecosystem. If there's a nuget package that solves your problem, you can probably use it.
• 🤝 There's an extremely helpful C# channel in the official Godot Discord.
• 🐤 We have a Chickensoft Discord server dedicated to supporting the Godot C# community. If you run into questions or just want to talk, feel free to stop by and say hello!

🎟 Free Stuff​

While there aren't many Godot addons created with C#, Chickensoft provides a number of well-tested packages to help you get started. Each project began as a piece of my own personal game project before being broken into separate packages to share with the community. Each project is fully tested and has 100% code coverage (for my own peace of mind).

Want to quickly create a Godot game with basic CI/CD and unit testing already setup? Use our dotnet new template for creating a game. We have a package template for creating nuget packages for use with Godot, too.

Need to inject code into lifecycle methods in your scripts automatically? We have a source generator for that. How about automatic, node-based dependency injection?

We even have our own command line tool, GodotEnv, that will automatically manage Godot addons for your project based on an addons.json file and let you symlink addons locally while they're in development. No more git submodules for addons!

If you'd like to use Godot from a GitHub actions workflow, you can use setup-godot to run Godot directly on a macOS, Windows, or Linux runner.

We also have packages for running tests inside Godot, creating basic state machines in C#, logging, and a handful of other things.

😅 Afraid of Commitment?​

Since you can mix and match C# and GDScript in the same project, you only have to choose which language you want to use for the majority of your project.

If you happened to have chosen C# as your primary scripting language, you may need to be able to call into GDScript occasionally from C# since it is impractical to rewrite every addon you might need in C#. While this probably isn't as efficient as keeping everything in one language, it can really help in a pinch.

So, if you hate committing to a single language, why not have both¹? The Godot documentation discusses how to bridge between C# and GDScript.

🎁 Wrapping Up​

Even though Chickensoft is dedicated to the C# Godot community, C# isn't necessarily the correct choice for every Godot game. For most people, GDScript is probably the best choice.

I like to think that if you need (or want) to use C#, you already know that deep down inside.

Ultimately, if you decide to embark on an adventure and use C# for your next Godot game, we're happy to lend a hand and cheer you on in the Chickensoft Discord. Either way, we wish you the best of luck and we hope to hear from you! 😀