- cross-posted to:
- [email protected]
- cross-posted to:
- [email protected]
I made a blog post about my experience switching from Unity to Godot earlier this year, and some tips for Unity devs.
I made a blog post about my experience switching from Unity to Godot earlier this year, and some tips for Unity devs.
… welp. So… any more details on this? I’m not learning a single-purpose language.
Edit: yes, GDScript seems nice, I know. Please stop recommending it though :P
Honestly GDscript is really easy to learn if you’ve got a programming background. The concepts are mostly the same so you can head over to the GDScript reference and learn to use it in less than a day. As soon as you get used to the syntax you basically know it already.
I’m sure you’re right, and it looks serviceable. It’s not really about that, though. I’ve done the “learn a new language” thing many, many times. It gets old and I’m sort of over it - it’s not as fun as it once was, particularly now I have my favorite that I know well and am good at.
GDScript works almost 1-1 like Python. Any experience with Python almost instantly translates into knowing what to do in GDSCript, but not necessarily the other way around, as their script has a couple more builtin features.
Was going to say this but you beat me to it: if you know Python, you pretty much already know GDScript. It’s not at all like needing to learn another language from scratch.
If you’ve done it a lot then you know how easy it is to get up and running with a new language.
Really, it’s not that hard. GDscript is not some archaic clunker like COBOL with outdated paradigms, nor some esoteric joke language like Brainfuck that’s just pointlessly difficult. You’re going to be fine with it inside of a day.
C# works fine, lots of Godot projects are using it.
That said, consider learning GD Script? Even if it’s only used by Godot, it’s simple, well integrated with the editor and is awesome for quickly building out your game.
Besides, it’s very Python-esque. Whether you know Python or not, it’s syntax is very straightforward and easy to work with.
GDScript is very similar to Python; if you know Python, learning GDScript takes about an hour.
The C# version of the project is separate from the main one. It is possible to entirely code a game in c++ though in the main one (you can use both c++ and gdscript in it in one game interchangeably). Gdscript is a really easy language to learn though and is similar to other scripting languages (the only things you really need to learn is some keywords godot added to make coding in it easier when using things in the engine. Stuff like node names etc you would have to learn regardless of the language you’re using)
I’ve been working in Godot for about 3 years now, and have never touched GDScript. I personally haven’t felt like a second class citizen, and have rarely run into C# specific bugs, or found the documentation was missing for C#, other than when I was using the GD4 betas.
That being said, I’m not currently targeting web or mobile with my hobby projects, and I know those are open issues with the C# support.
My 2c.
C# works fine with Godot and with the changes in Godot 4.x its better than ever with Godot.
Here’s a pretty good blog post comparing the two:
Personally I dislike using scripting languages as the primary language for any bigger project. The lack of proper static typing commonly causes issues with linting, code-completion, error highlighting and refactoring tools. Lack of namespaces can lead to name clashes with type names and such especially ones you start adding bunch of 3rd party plugins.
Also using having to include/preload any script files using string references like this:
const Rifle = preload("res://player/weapons/rifle.gd")
is not just plain bad in my books. Its just plain dirty compared to Namespaces in C# or Packages in Java.I do like Python and I use it quite a bit at work to automate things as you can install and import bunch of ready made libraries for almost anything and just write script that is like sub 500 lines and does whatever. But the moment I need to make anything that contains multiple files and some object oriented practices things will get increasingly more annoying very fast.
Having interfaces is quite nice as well as it allows me to keep my code more loosely coupled. I try to keep my code as portable as possible by keeping much of my code in a separate project that has no dependencies to Godot. This way I can use nUnit in another separate project to do unit tests for the code and just write wrappers and whatever in Godot project. If Godot API changes I generally only need to fix the code in the wrapper classes.
You can do most stuff with C# just fine, unless you run into one of the C# specific bugs and lack of beginner friendly tutorials.
That said what made me make the jump to GDscript was just how seamless it is to use compared to C#.