2
\$\begingroup\$

I've read through the Godot page about differences between the C#/mono version and the standard version (gdscript), and it primarily seems to be focused on the fact that C# is a different language with different conventions, and that support is a new feature that may have issues. It doesn't really seem to discuss any different capabilities or features gained or lost by using one version vs. the other.

The drawbacks of using the Mono/C# version seem to be:

  • There are likely some bugs because it is a new feature
  • If you don't already know C#, you need to learn (as with any language)

Are there different features, performance implications, or platform support limitations when using C#?

\$\endgroup\$
2
  • 1
    \$\begingroup\$ I've edited this question to nudge it away from "what technology/language to use" advice (which can stray into opinion/discussion and is considered off-topic for this site) and focus on the objective side of the question: are there features or platforms or performance we give up when using this version of Godot? \$\endgroup\$
    – DMGregory
    Commented Jan 20, 2022 at 13:27
  • \$\begingroup\$ @DMGregory thanks, that's exactly what I'm trying to ask. \$\endgroup\$
    – yoozer8
    Commented Jan 20, 2022 at 14:05

2 Answers 2

1
\$\begingroup\$

There are likely some bugs because it is a new feature

C# - the language - is well supported. Also, a lot of effort have gone into supporting ahead of time compiling, which allows greater platform support than it would have otherwise. However:

  • Some .NET libraries may cause trouble (mainly related to threading and reflection).
  • It is not well integrated into the editor. At least not at the time of writing. So I'd advice to use an external editor such as Visual Studio Code with C# Tools for Godot.

If you don't already know C#, you need to learn

The same can be said of GDScript. In fact, given that other engines also use C# - but not GDScript - you probably have an easier time transfering knowledge using C# (and even entire classes, if they don't have engine specific code). But don't let that discorage you form learning GDScript.


For someone who is comfortable working with both gdscript and c#, what are the reasons for choosing one version of godot over the other?

Some C# cons:

  • Using C# your build will be somewhat heavier.
  • We can be sure that everybody using Godot can use GDScript. Thus GDScript is the language of choice for addons. Going to C++ if we want to squish more performance, or if we need to talk to native code.
  • Metaprogramming is easier with GDScript: you crate a GDScript object with some code, then load it, instance it and run it. With C# you would need reflection for something like that, but it may not work, in particular with platforms that need ahead of time compiling.

Some C# pros:

  • You will have access to a larger set of libraries (with some caveats, as I said earlier, some cause trouble).
  • GDScript - prior to Godot 4 - is an interpreted language. And also C# is fully typed. As a result, C# often performs better than GDScript.
  • C# has some language features that make it easier to use compared to GDScript (e.g. iterators, lambda functions).

For everyday use, either is OK - so you can go with personal preference. However, when you get into very specific uses (e.g. metaprogramming, addons) or when you need some extra performance, that may tip the balance one way or the other. You may - of coruse - not know if you will run into those situations ahead of time.

On that note, I want to mention that you can combine both in the same game. So don't decide between them too early. In fact, using GDScript to deal with signals and have it call into C# code for game logic, might be a good idea. Since GDScript is a great glue language, and C# can archive better performance.

However, sometimes the interaction between these languages is not that smooth. For instance, async methods in C# - often - returns a Task and GDScript can't handle that with yield. For those situation, you want to refactor the code to use signals instead of async methods.

And - by the way - you can combine any other language you have in Godot, including visual scripting, and third party languages that you can install into Godot such as Lua and Python and so on. And yes, C++.

\$\endgroup\$
7
  • \$\begingroup\$ your build will be somewhat heavier what exactly do you mean here? The resulting executable will be larger? The build will be slower (or much slower)? The build just has more steps so more chances for something to break? \$\endgroup\$
    – yoozer8
    Commented Jan 20, 2022 at 14:06
  • \$\begingroup\$ @yoozer8 All of the above. It has to build a .NET project and bundle it into the final package. And yes, that is a possible failure point. And yes, that means it takes a little more time. And yes, the final package will take more storage. However, I meant the last. That is, that it takes more storage. The little extra time is no big deal, and if there are no errors in the C# code it should build without problems. \$\endgroup\$
    – Theraot
    Commented Jan 20, 2022 at 23:54
  • \$\begingroup\$ You say don't choose between them too early, but they are presented as two different versions of the software (godotengine.org/download/windows). Kinda have to pick one just to get started. \$\endgroup\$
    – yoozer8
    Commented Jan 21, 2022 at 2:22
  • 1
    \$\begingroup\$ @yoozer8 Sadly, yes. However, if you make a project with the C# version one, and you don't use C# at all, you can open it on the other. And if you have been using the other and decide you want to start using C#, you can download the C# version and open your project there. The first reason why they are separate downloads is because C# cannot be installed as a plugin. Second, maintenance wise, if a problem happens in the version that does not include C#, we know it is not a C# related problem. And third, of course, Godot pushes for GDScript use, as it is tailor made for the engine. \$\endgroup\$
    – Theraot
    Commented Jan 21, 2022 at 3:10
  • 1
    \$\begingroup\$ @yoozer8 The idea of making the C# version the only version has been pushed before. Yet, it probably won't happen until Godot 5 or afterwards. Currently Godot 4 pre-alpha only has the version without C#, first because it make maintenance easier, and second because the C# support is moving to .NET 6, and that is still to be completed. So Godot 4 is likely to have two versions too. \$\endgroup\$
    – Theraot
    Commented Jan 21, 2022 at 3:13
0
\$\begingroup\$

There is like a Godot world and .NET/Mono world (.NET for Godot 4 and Mono for Godot 3). Godot world runs your scenes and nodes, .NET/Mono runs your scripts when using C#. GDScript scripts are apparently better at communicating with this Godot world, than C# scripts (C# carries additional cost or so I heard). On the other hand the scripts themselves in C# might be faster (especially if you want to run some complex simulation/computation). C# also gives access to many convenient libraries.

However C# can introduce some confusion and not so obvious bugs. When you write your scripts in GDScript, you are limited to doing things the Godot way. When you write in C# you can still do things the Godot way, but .NET/Mono way of doing things become available (which you might want to do if you are familiar with the language/framework). Not everything translates 1:1 between those 2 worlds (though a lot of effort went into Godot 4.0 to make the experience more seamless). In C# you might face 2 different ways to declare and emit signals, run async code, read files etc. Sometimes both are fine, sometimes one is wrong and it's not obvious when. In many cases, sticking to the Godot way of doing things might be a better option in the long run, as there is some serious optimization related to managing nodes and scenes on the Godot end and using the .NET/Mono way may cause bugs with the engine. On the other hand if you want to tap some of extra power that comes with .NET/Mono you would have to abandon Godot way of doing something. When coding in C#, you might think "how do I solve this in .NET" and miss that Godot has a built-in function for that already. Some built-in parts of .NET ecosystem refuse to work in a Godot project (I was unable to use ASP for networking, but thankfully Godot has it's own functions for that).

Adding to the mix of pros and cons, in C# it's easier to extend Godot's built-in functions using Extensions and the the like (for when GDScript is missing something). Although some of the things I miss in GDScript work in C# out of the box for Godot (like you can do much more with collections and easier at that). GDScript in Godot 4.0 went a long way from the previous versions, so I expect less things to complain about in future versions of Godot.

With Godot 4.0, Visual Studio integration works really well and preparing the environment for debugging is much easier. C# project structure and solution were also greatly improved (Framework styled project were replaced with the modern SDK style projects and Godot no longer appears to overwrite them which would lead to losing changes made in an external IDE).

Last, but not least, I think it's possible to do a bit of both (C# and GDScript) in your project.

\$\endgroup\$
1
  • \$\begingroup\$ Also, in Godot 4.0 there are more nuget packages to chose from and nuget is easier to use. \$\endgroup\$
    – jahu
    Commented Mar 20, 2023 at 11:08

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .