Gdscrpit vs C# - what do you prefer?

Mugborn_Games · July 18, 2025, 3:06pm

I wonder what do you guys prefer for scripting language?
Coming from Java programming world, I always missed proper encapsulation and interfaces with GDScript. Just switched my project to C# and I marked 90% of fields private.
It feels so good. Finally knowing exactly what should be called from outside and what not. I know people use _ prefix for marking private stuff, but it feels much better when compiler makes sure you don’t accidentally use them. Also, code completion gives me just public methods and field makes coding much more enjoyable.

wchc · July 18, 2025, 3:43pm

That depends.

In Godot, I prefer GDScript and that’s what I use almost exclusively, as it’s better documented, has a bit more features than C#, and is easier to use. I like the fact that I can just open Godot and start writing, no more setup required as opposed to C# with a separate IDE etc.

In general however, I prefer strongly typed languages, with the features you mentioned. My background is Unity, so I’m used to C# and I like it a lot as a language. Even though I use GDScript, I usually try to make my code as type-safe and explicit as it allows me, so I’m somewhere in the middle.
I think if Godot had the possibility to properly parse C# in its native editor - I would most likely switch to C#.

I would love to see a hybrid in the future - GDScript syntax with fully type-safe capabilities, private properties and methods, traits, etc. Very slowly, but we’re getting there

foldear · July 18, 2025, 3:49pm

I am using C# as well, mainly because it’s easier to apply OOP pattern (for me) and because I am experienced with it.

Mugborn_Games · July 18, 2025, 4:22pm

Yeah, I totally agree it’s more convenient to have code integrated into the engine. But I find it less annoying to switch between Godot and VS Code then I expected. I feel like I have more space for the code view.
It would be awesome to see private modifier added to GDScript. I miss that the most.

Mugborn_Games · July 18, 2025, 4:24pm

Thanks for your reply, foldear,
Did you ever experience any issues because of using C#, like additional performance cost compared to GDScript? Or some missing features, like preload() function?

wchc · July 18, 2025, 4:31pm

Give these proposals a solid thumbs-up then! Hopefully we’ll see them being added one day.

github.com/godotengine/godot-proposals

Add public/private access modifiers to GDScript and autocompletion improvements

opened 09:43AM - 27 Mar 20 UTC

2plus2makes5

topic:gdscript

**Describe the project you are working on:** 2.5d beat'em up **Describe the …problem or limitation you are having in your project:** Inside a GDScript class i often use "private" variables and functions that shouldn't be visible ouside but that instead are "public", hence visible and usable by everyone. More or less related is the fact that autocompletion is cluttered, yes alphabetic order is good but the list always starts with lots of constants and the function or variable we want is usually buried in lots of other things that aren't useful in that moment. **Describe the feature / enhancement and how it helps to overcome the problem or limitation:** Let us specify if a variable or function is private or protected(or whatever keywords you want to use), a private variable can only be used by the functions of the same class, protected means that it's also accessible by the classes that inherit from the class the variable is in. About autocompletion in my opinion it would be even more useful if suggestions were grouped by class, ordered from the leaf of the class tree back to the root class, or maybe add to the editor's options the possibility to order and filter what is shown. **Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams:** var v(no access modifier means public) protected var v(accessible only in the class it's in and the ones that inherit it) private var v(accessible only in the class it's in) Autocompletion suggestions would be grouped by class, ordered from the leaf to the root of the class tree, maybe with their class written somewhere. It would be also helpful if the suggestions were colored the same way as in the editor, this way it would be even faster and easier to find what we want. **If this enhancement will not be used often, can it be worked around with a few lines of script?:** Access modifiers and autocompletion are essential features so they would be used very often and probably they can't be made with few lines of script. **Is there a reason why this should be core and not an add-on in the asset library?:** It seems to me that a GDScript feature like these ones should be core.

github.com/godotengine/godot-proposals

Add a Trait system for GDScript

opened 06:19PM - 03 Mar 23 UTC

vnen

topic:gdscript

### Describe the project you are working on The GDScript implementation. #…## Describe the problem or limitation you are having in your project The main to reuse code in GDScript is via inheritance. One can always use composition, either via instances stored in class variables or as nodes in the scene tree, but there's a lot of resistance in adding a new prefix to accessing some functionality in the class, so many go to the inheritance route. That is completely fine if the inheritance tree includes related scripts. However, it's not uncommon for users to create a library of helper functions they want to have available in every script, then proceed to make this the common parent of everything. To be able to attach the sub-classes to any node, they make this common parent extend `Node` (or even `Object`) and rely on the quirk of the system that allows attaching scripts to a sub-class of the type it extends (cf. godotengine/godot#70956). The problem with this usage is that a script gets a bit of "multiple inheritance" which is not really supported by GDScript. One script can now extend another that ultimately extends `Node` but it can also use the methods of, say, a `Sprite2D` when attached to a node of such type, even when not directly on the inheritance line. Here I put a more concrete example to understand the issue:[^self] ```gdscript # base.gd extends Node class_name Base # ------- # sprite_funcs.gd # Attached to a Sprite2D. extends Base func _ready() -> void: # Here using `self` as a hack to use dynamic dispatch. # Because GDScript won't know what `centered` is, since it's not on the inheritance tree # and it does not know the attaced node. self.centered = true # ------- # body_funcs.gd # Attached to a RigidBody2D extends Base # This method can't be validated in signature to match the super class since RigidBody2D is not being inherited. # So it won't catch a potential user error. func _integrate_forces(state: PhysicsDirectBodyState2D) -> void: print(state) ``` All of this works against the user since they lose optimizations and compile-time checks for potential errors. It's a bigger loss if they use static types since not knowing the actual base class will make the compiler not know the types of properties and methods, making the checks less reliable. Another problem for users of static typing is checking if a particular method implements a given interface. You can use `has_method()` but that's often not enough since you can't tell what the signature of the method is. Even with introspection, it would require a lot of boilerplate for each check and you still lose the benefits of static type check. You can only check for inheritance but since that is linear you cannot use for a class that needs to implement multiple interfaces. **Previous requests for a feature like this, or problems that could be solved by this feature:** - https://github.com/godotengine/godot/issues/23101 - https://github.com/godotengine/godot-proposals/issues/758 - https://github.com/godotengine/godot-proposals/issues/4872 (interfaces) - https://github.com/godotengine/godot-proposals/issues/1346 - https://github.com/godotengine/godot-proposals/issues/1093 (multiple inheritance) [^self]: As an extra note, I would like to make `self` be transparent and work the same as not using it (unless used for scope resolution), since some people like to use it just for clarity and end up losing performance optimizations without realizing. But this is not related to this proposal in particular. ### Describe the feature / enhancement and how it helps to overcome the problem or limitation For solving this, I propose the creation of **trait** in GDScript. #### What is a trait? It is a reusable piece of code that can be included in other scripts, parallel to inheritance. The included code behave pretty much as copy and paste, it adds to the existing code of the script, not unlike the `#include` directive in C/C++. Note that the compiler is aware of traits and can provided better error messages than an actual `#include` would be able to. Its contents is the same thing that can be included in a script: variables, constants, methods, inner classes. Besides that, it can include **method signatures**, which are methods without an implementation defined, making the trait acting like an interface. #### How is a trait defined? In its own file, like a GDScript class. To avoid confusion, I propose using a new file extension for this, like `.gdt` (for GDScript Trait), so it won't be usable for things that requires a script. For instance, you won't be able to attach a trait file to a `Node` directly. I'm still considering whether trait files should be resources. They will only be used from the GDScript implementation, so the resource loader does not need to be aware of them. OTOH, it might make the filesystem scan more complex. This will be investigated further during implementation. Traits can also be nested in trait files or in GDScript files, using the `trait` keyword: ```gdscript # script.gd class_name TraitCollection trait NestedTrait: pass ``` That would be accessible with `TraitCollection.NestedTrait`. Example of a trait file: ```gdscript # trait.gdt const some_constant = 0 var some_variable := "hello" enum Values { Value1, Value2, } func some_func_with_implementation() -> void: print("hello") func some_abstract_function() -> void # No colon at end. # This is independent of the outer trait, it won't be automatically used. trait InnerTrait: pass ``` I consider also using a `trait_name` keyword that would work similar to the `class_name` keyword, making the trait available by name in the global scope. I prefer not to reuse `class_name` for this as I believe it might be confusing, since the trait file is not a class. Trait files cannot contain inner classes. Traits can use the `extends` keyword to select a base class. That will mean that any script that does not derive from this class cannot use the trait: ```gdscript # trait.gdt trait_name MyTrait extends Node2D func flip(): rotate(PI) # Works because `rotate()` is defined in Node2D. # node3d.gd extends Node3D implements MyTrait # Error: MyTrait can only be used with scripts that extends Node2D. # sprite2d.gd extends Sprite2D implements MyTrait # Valid: Sprite2D inherits from Node2D ``` The `extends` keyword can also be used with a custom GDScript type. Traits can also override methods of the base class. This means they need to match in signature and will give an error otherwise. Note that for native classes the overriding of methods can be unpredictable as the overrides won't be called internally in the engine, so this will give a warning (treated as error by default) as it does for when this happen with a GDScript class. #### How to use a trait? I propose adding the `implements` keyword[^implements]. This should be added at the beginning of the class, together with `extends` and `class_name`. ```gdscript # file.gd extends Node.gd implements "trait.gdt" implements GlobalTrait implements TraitCollection.NestedTrait ``` Using multiple traits will include them all in the current class. If there are conflicts, such as the same method name declared on multiple used traits, the compiler will give an error, also shown in-editor for the user. If the current class has a method with the same name as one used trait, it will be treated as an override and will be required to match signature. For variables, constants, and enums, duplication won't be allowed at all, as there are no way to override those. If multiple traits has the same variable, then it will be considered a conflict only if they have different types. Conflicts between trait methods can be resolved by implementing an override method in the script and calling the appropriate trait method: ```gdscript # trait_a.gdt trait_name TraitA func method(a: int) -> int: return 0 # trait_b.gdt trait_name TraitB func method(a: int) -> int: return 1 # script.gd implements TraitA, TraitB func method(a: int) -> int: return TraitA.method(a) # Or: # return TraitB.method(a) ``` Traits can also use other traits, allowing you to extend on an existing trait or create "trait packages" so you only need to use once in the classes and it includes many traits. It is not a conflict if multiple used traits happen to use the same trait. The nested inclusion won't make it being included twice (which differs from how `#include` works in C/C++). Once a trait is used, its members can be accessed as if belonging to the same class: ```gdscript # trait.gdt var foo = "Hello" func bar(): print("World") # script.gd implements "trait.gdt" func _init(): print(foo) # Uses variable from trait. bar() # Uses method from trait. ``` #### Are traits considered types? Yes. Traits can be used as type specifications in variables: ```gdscript var foo: SomeTrait ``` They can also be used in type checks and casts: ```gdscript var foo := value as SomeTrait if bar is OtherTrait: print("do stuff") ``` To avoid polluting the global scope, the traits can also be preloaded like classes: ```gdscript const SomeTrait = preload("traits/some_trait.gdt") var foo: SomeTrait if foo is SomeTrait: print("yes") ``` **Warning:** One thing to consider when using traits as types is that all are considered to be a basic `Object` with a script attached. That is, even if the instance you have extends, say, `Node2D`, you won't be able to use the static type checks for `Node2D` members. That also means that optimizations done by GDScript to call native methods faster won't be applied, since it can't guarantee at compile time that those will be available without knowing the actual super class. Using `extends` in the trait helps when it's meant to be applied to a particular type, as it will hint the compiler to what is available. **Warning:** Consider too that when checking for traits with `is` and `as`, the check will be for the use of the exact trait. It won't check if the object implements the same interface as the trait. As an example: ```gdscript # trait.gdt func foo(bar: int) -> void # a.gd class_name A func foo(bar: int) -> void: print(bar) # b.gd const MyTrait = preload("trait.gdt") func _init(): var a := A.new() print(a is MyTrait) # Prints 'false'. ``` While the class `A` implements a method `foo` with the same signature, it does not use `"trait.gdt"` so it won't be considered to be this trait when checking with `is` nor when casting with `as`. This is a technical limitation since performing an interface validation at runtime would be costly, and not validating at runtime would be unpredictable for users. [^implements]: Note that `implements` won't be a reserved word to avoid breaking compatibility. The context will be enough to not confuse it with and identifier. ### Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams Internally, a trait file will be treated a bit differently from a script file, to allow the little differences in syntax (e.g. methods without body). They will use the same parser since the differences are small, but will be treated differently when relevant. This does add a burden for the parser, though I believe it is better than using a different parser that would do most of the same. The analyzer, which is responsible for type-checking, will also run on traits. They will be required to be internally consistent on their own, even before being used in a class. This allows the errors to be detected when writing the trait, rather than when using it. Fully defined functions will be compiled and stored in a `GDScriptTrait` object. This object won't be exposed to scripting and only used internally. It will be used for caching purposes to avoid compiling the same trait multiple times. The defined functions will be copied to the GDScript object that implements the trait, so it won't have any reference to the original `GDScriptTrait` object. Used traits will be stored in the GDScript object as a set of strings. The stored string is the FQN (fully qualified name) that uniquely identifies the trait (essentially the file path plus identifiers for nested traits). This will be used for runtime trait checks and casts, created by the `is` and `as` keywords. During parsing, the used traits will be collected and referenced in the resulting parse tree. The parse trees won't be directly mixed in order to allow the parser to detect the origin of code and thus provide more specific error messages. The analyzer phase will further check if there are no conflicts and if types are correct, including checks for trait types. It will give specific errors and warnings where appropriate. The `GDScriptCache` will be responsible for keeping the the `GDScriptTrait` objects and intermediary compilation steps when necessary. After a GDScript is compiled, the trait cache will be purged. This cache is only used for the compilation of a single file and re-used for multiple uses of the same trait by the script or by its dependencies (either by the `implements` keyword or using them as types), so after the compilation is complete it needs to be cleared as we can't know when or if other scripts will be compiled or whether they will use the same traits. For variables/constants/enums, used traits will behave like copies and recompiled in the current class. This is so the constructor is done per class without having to rely on calling other functions compiled into traits. Usually the default values are not complex expression and it shouldn't be a problem compiling them multiple times (this case will be rare too). ### If this enhancement will not be used often, can it be worked around with a few lines of script? Considering all the requests, it will likely be used often. The work around for this can be quite clunky, especially if you are trying to validate interfaces and not only reuse code. ### Is there a reason why this should be core and not an add-on in the asset library? It is an integral part of GDScript, it cannot be implemented externally.

frontline · July 18, 2025, 4:45pm

GDScript, it’s just so easy and straight forward in my opinion. I used to use c# in unity, but gdscript is just so much simpler, i also have a background in python and gdscript is a bit more pythonic in nature, it just feels more natural for me. The documentation is also super helpful.

Mugborn_Games · July 18, 2025, 4:54pm

Thanks for sharing the links. Just voted for both.

Mugborn_Games · July 18, 2025, 4:56pm

I agree it’s simple, and I mostly like it too. However, on bigger code base, it’s much harder to keep things organized without encapsulation and clean interface definitions.

foldear · July 18, 2025, 5:20pm

I’m new to Godot, I’ve just been tinkering with it for a couple of weeks now, so I haven’t used any GDScript at all, I am not the best person to ask ahah. For now, it’s just a matter of preference, but I’ll definitely try GDScript to see the differences.

Mugborn_Games · July 18, 2025, 5:54pm

Thinking more about this, it would probably require GDScript to become compiled language in order to show invalid access errors in the code. I really don’t know how does GDScript executes currently, I guess it’s interpreted in runtime. Having the compiler which can check invalid access during building/exporting the project (or even before like some IDEs like VS Code do) would be awesome. However I guess it’s a huge change compared how it works today,

Firedude123 · July 22, 2025, 11:09am

I prefer to use C#, personally, because of its familiar syntax. However, GDscript is more commonly used amongst the Godot community, but if you’re coming from Java, I would recommend C# for its similarity to Java.

OriginalBadBoy · July 22, 2025, 12:08pm

Outside of programming at Uni about 30 years ago (so Ada, Pascal , and x68000 ASM) c# was the first language I picked up and tried to learn properly (still learning).

For most small projects it wont matter, but I would recommend anyone who is doing a sizeable project to learn it. Also if performance is somewhat critical the its probably the only way to go.

It does have some annoyances with Godot, but over time they will get sorted out.

georges2019 · July 22, 2025, 12:36pm

Microsoft presenter integration of Aspire.net to Godot c# project solutions..at GodotCon 2025 at Boston

With c# 13 and interoperability with Java, c++ and python, Godot with c# will have many advantages from .net ecosystem than Gdscript

What we need is higher coverage of unit tests for Godot c# as GDScripts …this high coverage is more effective than c# Documentation

With LibGodot, through c#, greater flexibility with UI, backend service and secured business logic

Mugborn_Games · July 22, 2025, 5:49pm

After all said in this post, to be honest, I would be happiest to use Kotlin. There is Godot Kotlin plugin but it doesn’t seem to be so well integrated with Godot editor, and also I don’t like the fact it requires so many annotations in the code.

LemmaEOF · July 23, 2025, 5:28am

Almost a decade of writing Minecraft mods has basically hardwired my brain for the idioms of Java, so I mainly use C#. The encapsulation and interface systems are really nice of course, but the big killer feature for me has been performance - it’s very nice not having to worry as much about the price of method calls, since I don’t really use many reflection features anyway.

Basically the only big catch for me with using C# in Godot right now is how C# structs can’t be used for exported properties since they can’t extend GodotObject - it’s a frustrating but really understandable limitation all things considered, and just ends up with me writing things like I would in Java anyway lol

dragonforge-dev · July 23, 2025, 6:39am

GDScript 100%.

I’ve programmed professionally for years in both Java and C#, as well as Python, Ruby, C++, PHP, and JavaScript. I am a huge fan of OOP, though I do believe that Functional Programming has its place.

I also agree strongly with all the reasons @wchc gave, so I won’t re-iterate those.

If this is the most important thing for you, cool.

Personally since I can enforce type and know how to read what’s private/protected/public in my code, this isn’t an issue for me. Neither has autocompletion. I also haven’t ever had that problem in professional Godot projects using GDScript with other developers.

You can do OOP in any modern language from the last 20 years except for a few that are intended to be Functional Programming languages and then…you just shouldn’t.

While C# does has things like templating that would be nice in GDScript, the absence hasn’t been an issue for me so far.

I pop out the GDScript editor on one of my portrait mode monitors. The same one I use for VSCode when I’m editing C# Godot code. So I get the same amount of screen real-estate for either.

I’d like to see private and protected, but mostly for use with other people in collaboration. Since in a codebase I own I can change modifiers anytime I want, the distinction is more for readability than anything else for me. Of course I am religious about adding that _ or removing it when I change the scope even though it doesn’t matter to the interpreter/compiler. It’s very clear in my code that if I’m calling a function prepended with an underscore, I will find it in that file.

C# is more performative, and that’s a great reason to use it - if that is an issue for you. But I have yet to have that be a limiting factor in any game I’ve made yet.

As far as missing GDScript features, keep in mind the Godot Mono (the .NET version) allows you to use GDScript as well. So you can preload() anything you want.

I disagree. But I also use other tools to enforce that kind of stuff on larger projects. Such as forcing human code reviews, and using unit tests on all PRs in the pipeline. If someone changes an interface, either a person or the tests will catch it.

I also disagree because I use encapsulation and clear interface definitions along with code comments in all my GDScript code. Plus Godot’s use of signals easily allows you to enforce encapsulation by using signals to communicate between objects instead of making direct function calls where appropriate.

GDScript is a compiled language on export. It’s only interpreted when running in the editor. When your project gets large enough, you’ll notice the difference in loading times between C# and GDScript. After making a game in C# I decided that the benefits of the language did not outweigh the load time and compile time of C# for my game.

Using C# with Godot made me feel like I was back in the 90s programming in C++ and waiting forever for a compile before I could test. (It’s not even close to that bad because those builds were hours long.) However I’ve grown fond of an Agile workflow. Godot with C# is an impediment to me in that. Every time you want to press the Run button in C# you have to compile all the code. This is especially annoying when I just want to test a single scene and not the whole game.

Regardless, the cycle time for making a change, running a test, and then getting results is significantly faster with GDScript. For me, that quality of life is more important than the few language features I wish GDScript had.

I’m curious how come. I’ve dealt with Kotlin before professionally and I always wondered why people just didn’t use Java instead. I don’t know as much about Kotlin though, hence my curiosity.

I just want to re-iterate that I’m just giving my opinion. You do you.

I will add that I’ve been using Godot since 3.0, and the changes to GDScript have been HUGE. What finally sold me on GDScript was when they made it so you could make your functions type safe if you wanted. When I started, everything was duck typed. You just passed variants around. They’ve come a long way, and this is one of the most active open source projects I’ve ever seen.

One final note for anyone who is trying to decide. You can always move from GDScript to C# by using the Mono (.NET) versino of Godot and using everything you’ve already made, and then redo anything that you needs better speed for in C#. It’s harder to go the other way. (If C# is your jam, this approach probably isn’t worth it.)

Demetrius_Dixon · July 23, 2025, 6:44am

I’m much more of a designer than a programmer. So I use whatever language is easiest as a means to get to the gameplay, which is my speciality.

That means to an end, for me at least, is GDscript. It’s easier than C# and is nicely integrated into the Godot Engine; which is also my prefered game engine.

I don’t think too hard about stuff like this, because I understand what I value most: Gameplay and Community.

sante · July 23, 2025, 5:59pm

Honestly, I still can’t understand the point of C# with Godot… As someone already pointed out, a programmer must choose the most appropriate language, in order to work as comfortably as possible. I made a tutorial (on my YouTube channel @sante76, in Italian, with English subtitles) dedicated to GDExtension, or C++. I essentially demonstrated that GDScript is as fast as C++, as long as you use the classes provided by Godot, because, in essence, it simply gives commands to the engine. It starts to have speed issues with calculations, especially with large loops, such as those for creating terrain meshes. At that point, however, I prefer to unleash the power of C++ with GDExtension, only for the parts of the code where it’s necessary. GDScript is so simple that it allows you to focus on the “artistic” side of creation, without getting lost in the frills due to the rigidity of other programming languages, like C++ itself.

athousandships · July 23, 2025, 6:07pm

This is not universally true, calls from C# code to engine methods is slower than GDScript, some times by a large margin, as all data is serialized when calling, code strictly in C# not interacting with the engine are usually faster, like looping over a container in C# (not necessarily engine containers like Array), but if you have a loop calling things on a node it might be slower, or at least not much faster

This is not the case, it’s always interpreted, though work on AOT compilation is being investigated