GDScript

(Unsure if this is the correct flair)

After having built a 3D bullet hell in GDScript, spending almost as much time doing optimizations as I spent on programming the prototype, and now building a similar prototype in C# using the physics / rendering server...I can't think of any reason to NOT statically type your GDScript code.

Static typing not only makes it significantly easier to debug but has notable performance boosts across the board. As someone who comes from a Java/C++ background, I also personally feel it brings *a bit* more professional credibility to GDScript as a language.

I did a side-by-side optimization comparison test that directly accesses the Physics/Rendering 3D server to create 3000 bullets in GDScript and C#. Statically typed GDScript was only about 10% FPS slower than the C# version.

Yet the overwhelming majority of YouTube tutorials and code posted on this subreddit use dynamically typed GDScript. Any particular reason why static typing isn't the default when it only appears to have benefits over dynamically typed GDScript?

Curious on everyone's thoughts - for those programming in GDScript , do you enforce static typing in your code?

UPDATE:

Thanks to everyone for your input and insight! Didn't realize the subject of static typing was so polarizing.

For anyone interested, here is the github link to the optimization test using the PhysicsServer3D and RenderingServer to spawn 3000 objects, written in static typed GDScript:

Godot version 4.2.2, Jolt3D physics engine

Project Settings -> Debug -> GDScript:
Unassigned Variable: Error
Untyped Declaration: Error
And there is more useful stuff

Three months ago, I began learning GDScript. Prior to that, I had attempted to learn other programming languages such as JavaScript and Python but understood very little. I realized that I was too fixaded on the theory. In Godot, you receive immediate visual feedback on what you've programmed, making it much easier for me to comprehend the underlying theory.

I revisited those courses and understood everything right away. For me, GDScript was not useless; it served as an excellent introduction to programming. With this newfound knowledge, I can now explore other languages that have more practical applications beyond Godot. I acknowledge that GDScript may not have real-world utility like other languages, but it serves as an invaluable stepping stone for learning the fundamentals.

My friend and I are trying to create a game but we can't decide on the language. We have been able to set up C++ workflow, but for me it seems uncomfortable. I have to wait for compilation and all that. Is it common to endure this discomfort, or are the majority of projects (that at least anyone other than dev's mom plays) using GDScript. Please, correct me if I said something wrong, I'm just a beginner.

I have read somewhere that a simple tool can reverse engineer any Godot game and get the original GDScript code with code comments, variable names and all.

I have read that decompiled C++ code includes some artifacts, changes variable names and removes code comments. Decompiled C# code removes comments and changes variable name if no PDB file is included. Decompiled GDScript code however, includes code comments, changes no variable names and pretty much matches the source code of the game. Why is that?

For Godot, the upcoming update will introduce full support for the GDScript language, including the ability to debug. We’re aiming to maintain the compatibility with the existing community-driven plugin. Last but not least, the Godot support plugin is set to be bundled with Rider in the 2024.2 release.

This is fantastic news, and more proof that Godot is well on the way to being acknowledged as a first class engine alongside the usual Unity & Unreal duo.

PS: Jetbrains IDE are paid software but the EAP (early access program) will allow you to use the early access version for free! More info here:

I'm seeing a lot of people asking questions I originally asked when I started using Godot, so I'll add my two cents. I like Godot and I have no inclination to switch for my personal projects. I use Unreal at work for virtual production, but it's largely unnecessary for the games I make personally. Remember, this is for 3D stuff, 2D is a different monster.

First off, the official docs are great, and they're the only thing I currently use for dev reference. But that gets me to...

Resources

1: Tutorials for Unity and even Unreal are streets ahead of Godot. Get ready for a 10 minute video of someone not getting to the point. There are more every day as Godot grows, so it will get better.

2: Godot changes incredibly quickly and it makes porting things (such as tutorials) a nightmare. I tried showing a new Godot dev how I would go about making a game using Godot 4.1 with my knowledge of Godot 3.5 and nothing worked. Half the methods were deprecated. Basically pick a version and stick to it. But that's a major version change. Even the jump from 3.4 to 3.5 was game-breaking for me and required some healthy refactoring.

3: ChatGPT is woooooorthless. I hate the robot to begin with, but use it plenty as a smart assistant. Its model is from the Godot 3.0 days and it has no clue what it's talking about. It will only make your game worse. Just don't do it.

Technical stuff

1: Even with Godot 4, Godot isn't capable of what Unreal/Unity is fidelity-wise. Full stop. Doesn't matter if you're using GDScript or C#. I'm not interested in making graphics-intensive games, but I still hit the upper limits of Godot's capabilities on a regular basis.

2: GDScript doesn't allow for multiple inheritance, so that's the first thing I code around.

3: "Can I do 'X' in Godot? Yes you can. We're in the "making computers in Minecraft realm." It's just a matter if you're willing to deal with the performance of it and the coding required. Just remember your time is valuable so try to make the decision that's going to save you the most of it.

Personal Beefs

1: I hate the IDE. Surface-level, it's nice but it lacks some basic features like multiple windows and better docking and where the hell is the stupid shader editor. I'd recommend just using Sublime or something, but Godot is very dainty with it's .import files and external editing often will crash the engine.

2: The debugger is kinda weird. It's never as specific as I want it to be. Godot is written in C++ but all of the juicy errors are abstracted away, but there will be situations where Godot's built-in error checking for engine will actually hide errors that are related to your code. This is a low-level sweaty tech dweeb problem that that I only run into because I'm a software dev by day.

Final thoughts

I am very biased because I use Unreal as part of a VFX production pipeline at my job, so I think of the engine as a tool as a whole. Godot is not a replacement for Unity in terms of a mature and functional tool.

However, many of the people "jumping ship" are not going to be affected by Unity's cash-grabbery personally in their games, and to that end, most of the games that would be made in Unity don't require all of the performance that unity has to offer.

So if you're like me, and like lightweight engines and have low fidelity ambitions for a game and you want to make a lot of the code infrastructure yourself, Godot is fun. Certainly an upgrade from Pygame.

I'll be starting a new project with Godot. This will be my first serious attempt at game development (I've previously made a POC building my own game engine in SFML just to get my feet wet). I actually code for a living, and am very comfortable with C++ even if it's not my day to day coding language anymore. I like the things most people dislike about C++ : the static typing, the header/implementation separation, the choice to pass by copy, reference, or just a straight up pointer etc. Of course this isn't always great in all contexts. All of these things are time consuming, and some of the syntactic sugar in a language like Python (that I'm extremely familiar with) can make you code at the speed of thought. The tradeoffs are sometimes worth it, sometimes not. In my case, I'm building a relatively simple 2D RPG with low computational requirements, so performance isn't really my priority.

So my dilemma is this : Do I exploit my familiarity with C++ and start my project in C++ to benefit from the performance and safety boost ? Or is the user friendliness of GDScript a major boon, and I should save the C++ for a more performance intensive game ? Honestly the main thing I thought would be a drawback with GDScript was the dynamic typing leading to less safe and predictable code, but with type hints that gets rid of most of the problem. I'm mostly wondering if it'd be a shame not to start coding in C++ given my familiarity with the better performing language, or if the user friendliness of GDScript trumps that when performance isn't really an issue.

I should add that I'm not particularly worried about having to learn GDScript. Over the years I've picked up new languages and frameworks on the fly and it's never been an issue for me. What I'm really focusing on is which decision I'll be happy with mid development.

**(See final edit at bottom)**

We should be able to throw exceptions. I think it's unrealistic to think code will always work, or that data will never become corrupted. We should fight for this in the next Godot release. Or am I missing something here? I know I can use assert(..) during development. But I'm talking in production.

I was taught in university and industry, that exception handling is standard practice for modern development. What am I missing?

(Shout out to Godot dev's, I love all of you and love Godot)

**EDIT**Everyone saying a game should never crash... duh... That's why you catch exceptions, and handle them. This argument does not address the real issue at hand. Data files get corrupted, network connections fail, etc. There should be a built in way to handle unexpected outcomes, without crashing, and without writing my own exception class. Saying YoUr GaMe ShOuLdN't CrAsH is one of the most naive things I've heard in the programming industry. It's like saying a car's air bags shouldn't be needed if you drive safe.

Thanks everyone for the lively discussion. Together, we can make Godot the PREMIER game engine of the 2020's. Power to the people!! Open source for life!!

** Second Edit** The fact this post blew up, and got ratio'ed.... is a sign that there's something to this idea. Doesn't mean I'm "right" but it DOES mean, there are a bunch of dev's out here suffering... Godot can be improved through our hard work. Let's keep working!!

** FINAL EDIT**Ok I was wrong. Thanks for embarrassing me and teaching me stuff kind strangers. I'll be back again, when I'm ready to learn more stuff.

So as I have been building out a prototype in Godot / GDScript, I have been wondering how hard is it going to to be with managing a potentially large codebase in GDScript. My biggest concern is how it relates to refactoring and not so much performance.

I am almost certainly going to get initial implementations wrong and things will have to change as new features are added. From what I can tell, GDScript does not really complain about a lot of things unless the issue happens at runtime so if I rename a property of a script, change the signature of a signal, etc. and I miss some location that need to be updated, I will often not notice anything unless the code that was not changed is executed. If that is common code then is it not that big of a deal as it should be caught in normal gameplay testing but if it is code that almost never runs, that becomes a bigger problem.

For size comparison, imagine a codebase that would be required to handle the complexity of a table top RPG like D&D (just from a rules perspective, not anything graphical).

I know there is C# however 90% - 95% of resources out there on Godot seems to be GDScript related and I really don't want to be spending a ton of time translating GDScript -> C# when I don't think it is always a one to one translation. I also don't think C# is up to 100% feature parity with GDScript and personal I much prefer working in GDScript compare to C# from a DX view (and with this being just a hobby, this matter more than if it was a job).

How bad is it to manager a very large GDScript codebase? Are there ways to mitigate issues related to large GDScript codebases and issue with large refactors?

Hello, i am one of those Unity refugees that was looking for a new program for making games.

I worked on some projects with Unity using C# and now that i'm looking to switch to Godot i don't really know if i should use C# or the GDscript, especially since as far as i understand some of the features of the tool are planned around GDscript, but i also know that it's mostly based on Python and i have never really used it.

I'm not really a programmer but as far as i understand C# is fairly more complex than Python and i'm really unsure which to use and what results to expect.

I generally had in mind to try making a small multyplayer game for me and my friends to dip my toes with multyplayer features, would be the first one i do, and i'm unsure how to proceed due to all the doubts listed above.

Instead of wasting development effort on maintaining two different scripting languages, we should compromise on a single language we can all agree on. For that, we need a language that stands at the exact geometric center of Godot Python and Microsoft Java. I speak, of course, of .

At this point, a good portion of you are asking "what the hell is Groovy". To you, I say... you really don't want to know. Keep your innocence and just trust me that this is a good idea. As for those of you who do have experience with Groovy, and may be a bit cool on the idea, I'd like to remind you that compromise is, at its core, about ensuring that everyone is equally miserable. I can think of no better language to achieve this end than Groovy.

Edit: If you remain unconvinced, see my for a demonstration of Groovy's merits.

So many resources out there imply that C# is supported, but not as "mature". Obviously, that improves all the time, but is it true enough to hurt a project that doesn't plan to include a single line of GDScript?

Disclaimer: this post is about genuine interest and not to engage in a holy war of language preferences.

I recently asked this question in a comment to another post but it didn’t get any replies.

In my everyday job I am a C++/Golang backend developer so I don’t have industrial experience with .NET, however I used to use Unity for many years and I have some pet project level experience with it.

So the question is why do many godot devs choose .NET? What are the advantages of using it instead of gdscript?

My main arguments for GDScript are the following:

1. It’s super simple and does not have unnecessary complexity

2. It’s specifically crafted for the game engine

3. It’s extensible, especially due to its simplicity, you can add practically anything to the language

4. No external dependencies required, it just works

This is just from the top of my head. The only reason why someone would choose C# in my mind could be that they are switching from Unity and do not want to handle switching languages too. But… eh, you’re still gonna be learning engine specific types anyway.

So what is it then? :)