Clone of some popular game that I forgot the name of where you're a block and you move around a maze (tile-based, 2d) but you can't take small steps or slow down, you always slide quickly in one direction until you hit a wall. It's a puzzle game, you gotta make it to the exit without hitting the kill blocks. He wants to figure out how to make an in-game level editor for it but he still only 10% groks the node/scene s…
It has support for typing Arrays and Dictionaries these days. Yes, nested Arrays are still a problem but I am sure they will get to it. As for performance well the GDExtension support has also gotten much better. You can always go down to C++, Rust, Nim, Zig or whatever. It is really easy to set up.
This line of reasoning is silly, because no one in their right mind would choose to use gdscript for any program that was not in Godot. You can't even type a nested array, among many other issues. That is because gdscript is a bad language objectively. It being part of Godot doesn't change that. Why would I choose to write my game, the thing that is very hard and will take years, in an objectively bad language? I wou…
GDScript might be a bad general purpose language but it is a good language for Godot.
You say Python is a "normal" language for me while I love Python, modern Python has gotten way too complicated and clunky with lots of new features added. For me GDScript feels much closer to the original pythonic ideal. Plus it is much easier to learn for people that are not professional programmers.
Maybe you don't enjoy using GDScript and that is fine but saying it is a "objectively bad" language is really uncalled for. For many devs it is the right fit.
I've loved using Godot more, and it's been very informative as the first big OSS project where I'm closely following the development / proposals / devchat. I don't agree on many of the points by people downthread: I use C# almost exclusively and while it's been awkward (and clearly not a "priority") it's pretty seamless to use once you set up some stuff (though it certainly helps if you keep much of your logic in C#…
I'm in the same position, I use C# both because that sort of syntax is more familiar to me, but also because it just seems better as a language (in terms of both code structure and performance). There's a lot of downplaying of the advantages of C# in the Godot community, seemingly moreso by people who are amateur game devs/programmers, who perhaps just don't need the advantages for their particular kind of game.
I am a C# dev by day and love working with it. I miss interfaces, Linq, and the nicer pattern matching features of C# when using GDScript, but overall GDScript is quite adequate for what it needs to do and the game dev loop feels faster when using it. They can interop as well without too much friction, so if you have the .NET version of Godot, it can have some code in C# where (if?) you need it and other code in GDScript when you don’t.
My 13yo son recently discovered Godot and I'm very impressed by how accessible and powerful it all is. He had started gamedev a few years ago with Scratch. Figured out Roblox Studio a fair amount, but it's super quirky, plus he wanted to do 2D games. Tried some other stuff (eg pygame) but that's just super low level, inaccessible, plus you can't properly distribute pygame games for shit. Godot is on a whole nother le…
Great experience, thanks for sharing, a great way to get them motivated.
It got me motivated! I downloaded Godot and I'm gonna do something with all those level designs I made years ago...
Reading OP comment made it clear how little excuse I really have.
Is there anything in this which will make it easier/better to make GUI applications? https://github.com/derkork/openscad-graph-editor kind of has me considering using Godot for creating a drawing program....
I wonder the same thing, but with an emphasis on app mobile development. Godot from project setup to running on my Android is way more effortless/lightweight experience than doing the way of AndroidStudio and/or Flutter stuff. What I dream of is making a Lua binding for essential godot GUI control nodes using GDExtension and using this LibGodot to own the engine loop, so I can do all the app code in Lua. So, I may ha…
> but for writing a complete application I would want to develop in my language/editor/ecosystem of choice
For well over a year now, you can use an external editor (VSCodium or whatever) and set it in Godot settings (so that clicking a script icon in the scene tree opens that file, and clicking a signal handler in the properties pane jumps to that line), and the LSP for GDScript (which is hosted by your running Godot instance, and which your editor's LSP client connects to) has been excellent back when I last dabbled in it.
It has support for typing Arrays and Dictionaries these days. Yes, nested Arrays are still a problem but I am sure they will get to it. As for performance well the GDExtension support has also gotten much better. You can always go down to C++, Rust, Nim, Zig or whatever. It is really easy to set up.
This line of reasoning is silly, because no one in their right mind would choose to use gdscript for any program that was not in Godot. You can't even type a nested array, among many other issues. That is because gdscript is a bad language objectively. It being part of Godot doesn't change that. Why would I choose to write my game, the thing that is very hard and will take years, in an objectively bad language? I wou…
If you’re being objective about a programming language, its strengths and weaknesses are always going to a reflection of the game you’re trying to make. Python’s ecosystem will get you very far making web services, but less so with cert on consoles.
C# and GDScript are no different. They both have made design decisions for particular reasons.
You’re a skilled developer in real languages, so I’d encourage you to explore why other developers might prefer a DSL for their needs!
that's not been my experience at all. I've found that Godot works exceptionally well with C#, and I've felt zero pressure to use GDScript. It integrates really well with Rider too, which is the C# IDE I use. Even when there's places online that use GDScript examples, they tend to translate pretty much directly 1:1 to C#.
Rider seems neat, and I'd be happy to purchase a license, but subscription only? No thank you.
Visual studio 2026 offers a one time perpetual license for $500. It's not advertised at all and the hyperlink to it seems to shift constantly. I think if more people knew about this option, VS would have a significantly better reputation around here. $500 isn't cheap but it's a one time deal. If I hadn't discovered this I'd probably be looking for other options too.
I'm developing a game in Godot using C# and my experience with it is very good. I guess it depends on how deeply you integrate with Godot. I try as far as its possible to write my game headless. My opinion may change when I have gotten to the point of actually shipping a game though, so this take needs a grain of salt.
For me the real headaches emerged when I started writing [Tool] classes in C# for scripting within the editor itself. I don't know enough about the lower level nitty-gritty stuff to explain it, but I basically had to close and re-open the editor every time I recompiled. It had something to do with not being able to load assemblies, for example if I had a Tool script which referenced a sqlite library. There were also…
I find it amusing how Unity gets hate for domain reloading when it's this inevitable.
Rider seems neat, and I'd be happy to purchase a license, but subscription only? No thank you.
Visual studio 2026 offers a one time perpetual license for $500. It's not advertised at all and the hyperlink to it seems to shift constantly. I think if more people knew about this option, VS would have a significantly better reputation around here. $500 isn't cheap but it's a one time deal. If I hadn't discovered this I'd probably be looking for other options too.