7
\$\begingroup\$

Does godot 3.5.1 support C# fully ? Like does C# for godot have all the same methods that GDscript has?

I'm asking because I remember trying to learn gamedev a long time ago with C++, I was overwelmed with having to define every single basic thing from the graphics to normalizing fps, diagonal movement and don't get me on 3D stuff... I've never used it again since then.

The creators of Godot said through their own tests C# is 4 times faster than GDscript.... So I'm asking now, once I finish my game in GDscript is it possible to just take all the scripts and change them to C#? will all the methods used be the same?

I don't care if it is tedious and slow work, Ain't got the biggest brain, all I care is that it is easy work.

My game as it is consumes only 3% to 10% of my cpu and 5% to 20% of my gpu even on havier scenes and I have a really bad laptop... so for now performance is not a problem... but you never know... I mean.... 4 times faster! it could probably run on a toaster.

\$\endgroup\$
4
  • 7
    \$\begingroup\$ Code running 4 times faster does not mean the end game will run 4 times faster. \$\endgroup\$
    – Zibelas
    Jun 26, 2023 at 14:13
  • 1
    \$\begingroup\$ First result on a web search for godot c# has documentation covering the differences. \$\endgroup\$
    – Pikalek
    Jun 26, 2023 at 17:43
  • 6
    \$\begingroup\$ What @Zibelas wants to imply is that in the majority of Godot projects, most of the CPU and GPU load is caused by things that happen in the core of the engine, not by the execution of user script code. So if your main reason for converting your codebase to C# is to improve performance, then you might get disappointed. \$\endgroup\$
    – Philipp
    Jun 27, 2023 at 9:02
  • \$\begingroup\$ Your C++ problems sound like they're actually (lack of) an engine problem. There are game engines written in C++ you could use, that traditionally have been scripted in Lua. \$\endgroup\$ Jun 29, 2023 at 4:11

2 Answers 2

12
\$\begingroup\$

The Godot C# documentation provides an incomplete list of the API differences between C# and GDScript. There are some difference in the methods & properties names. Additionally, some things in C# work differently than they do in GDScript. For example,

GDScript uses onready to defer the initialization of a member variable until the ready function is called. However C# does not have this ability and to work around the issue you need to override the _Ready() in the item of interest to perform the necessary initialization. So where you might do the following in GDScript:

onready var my_label = get_node("MyLabel")

The C# version would look like this:

private Label _myLabel;

public override void _Ready()
{
    _myLabel = GetNode<Label>("MyLabel");
}

Similarly, preload isn't available in C# and some work arounds are required to get the same functionality.

However, it's probably worth fact checking some of the differences. For instance, the documentation mentions in several places that C# doesn't support parameterless constructors for structs. As mentioned in the comments, this was recently added in C# 10. Since Godot already has an official alternative you may want to stick with that, but it may be the case that embracing changes to C# make more sense depending on your situation and context.

Can you take all the scripts and change them to C#?

Generally yes, though the work will vary depending on the nature and complexity of the scripts.

Will all the methods used be the same?

No.

As alluded to in the comments, translation isn't a silver bullet solution for optimization. If you want to improve your performance, profile your code.

\$\endgroup\$
2
  • \$\begingroup\$ Parameterless constructors for structs was added with C# 10: learn.microsoft.com/en-us/dotnet/csharp/language-reference/… \$\endgroup\$
    – Cole Tobin
    Jun 28, 2023 at 18:16
  • 1
    \$\begingroup\$ @ColeTobin Thanks. I'm guessing that the examples in the documentation were correct at the time the were posted & they haven't updated it to include the more recent C# developments. In any case, I've update my answer to account for the change. \$\endgroup\$
    – Pikalek
    Jun 28, 2023 at 18:52
11
\$\begingroup\$

Pikalek answer is correct. I'll expand a bit about the performance and the translation process.


I want to point out that C# will give you more optimization avenues than GDScript, because C# has typed dictionaries, supports passing by reference,defining custom structs, etc.

C# has other perks not available in GDScript, for example interfaces.

Be aware that C# - as GDScript - run on the CPU, so the GPU should remain the same.


Furthermore, I want to point out that this is not an all or nothing conversion, as Godot support having both GDScript and C# on the same project.

My recommendation is to have GDScript call into C#, this is because the integration of GDScript with Godot is better (having syntax for easy node access, and for exporting variables to the inspector).

One gotcha you will stumble upon the interaction between C# and GDScript is that they can't consume each other async methods. However, GDScript yield can work with a method that returns objects that emit signals, and you can await signals on C# with ToSignal. Thus, you might want to refactor any asynchronous operations in the boundary between C# and GDScript to use signals for communication.

Because of this, you can translate your project from GDScript to C# by parts. However you need to choose carefully the boundary for your translation.


Another thing to keep in mind is that C# is an static typed language.

Even if you decide to use dynamic in C#, GDScript duck typing is more convenient for dynamically typed code (usually if you rely on duck typing in GDScript, you would want to define interfaces in C#).

Thus you might find helpful to specify the types of as much of the GDScript code as possible before attempting to translate to C#. At least when C# and GDScript interact, you need the methods to have their return and parameters types specified.

The Godot editor will help you identify which lines are not fully typed... Pay attention to the color of the line numbers. If the color is pale, the line is not fully typed.

By the way, you don't have to specify all types explicitly. As in GDScript you can use implicit typing, by initializing variables with := instead of = (this is similar to using var in C# or auto in C++).

Anyway, as you would know, you cannot have everything fully typed in GDScript (e.g. GDScript does not have typed dictionaries, as mentioned earlier), but as long as you can tell the types even when the code is not fully typed, you should be able to translate to C#.


I'll close by saying that even though C# is fully supported in Godot, since C# integration with the Godot editor is inferior, you will want to move to an external editor for C#, which might give you proper IntelliSense, refactoring options, and so on.

\$\endgroup\$

You must log in to answer this question.

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