5 ms·

They're still quintupling down on their sad Python-lite clone language and toy inbuilt text editor, what a damn shame. Still no way to avoid GC in C#. Godot had

They're still quintupling down on their sad Python-lite clone language and toy inbuilt text editor, what a damn shame. Still no way to avoid GC in C#. Godot had real potential, but they continue to insist it is a playground for learning about game development, rather than a tool to release a real game. If a fraction of gdscript and editor manhours had gone into real engine development, it would be better than Unity by now.

danbolt 9mo ago
My philosophy has always been “ergonomic scripting or drop to C++”, so I’m quite okay with it. C# has always felt a bit clunky to me. It’s nice to have alternatives.
- clownpenis_fart 9mo ago
  [dead]
roflcopter69 9mo ago
Is the GC in C# actually that much of a problem? Slay the Spire 2 is made with Godot + C# and the devs seem to be fine with it. Of course, it's probably not a computationally very demanding game but still the GC in C# does not seem to be a problem there.
- eudamoniac 9mo ago
  Yes it is a big problem. StS devs cannot write normal C# code, you have to really work around the C# integration to avoid lag spikes. See my other comment GitHub thread. There's also things like this https://github.com/godotengine/godot/issues/86926 https://github.com/godotengine/godot/issues/86926 and that the underlying types aren't compatible (Godot collections) that make it clear they aren't serious with the C# support. The other huge problem is the terrible external editor support, it does not work well at all. This means your vim, jetbrains, whatever muscle memory from a lifetime of professional dev work becomes useless, and you have to use a gimped text editor worse than notepad++. You can use an external editor, but then lots of things don't work very well, scenes get randomly corrupted, hot reloading doesn't work, etc. It's many issues like this that prove Godot's only priority is attracting and entertaining people who have never written code before, instead of making an engine viable for shipping games. I gave Godot a real chance for years, but at the end of the day it's a toy. There's a good reason that there are barely any games using it, and they're all extremely technically simple; surprisingly, that reason is not an unsophisticated underlying engine, but rather a million DX papercuts that a good ambitious developer would just never accept.
  - neonsunset 9mo ago
    [dead]
  - roflcopter69 9mo ago
    > StS devs cannot write normal C# code, you have to really work around the C# integration to avoid lag spikes Do you have any sources for this? A while ago I had a small chat with the StS devs on the Chickensoft Discord server and they didn't mention this. Instead they were overall just very positive about their Godot + C# experience. > The other huge problem is the terrible external editor support Have your recently tried JetBrains Rider for Godot + C# development? Lately, they've been quite actively improving the Godot integration https://github.com/JetBrains/godot-support https://github.com/JetBrains/godot-support and also showing some significant commitment https://godotengine.org/article/jetbrains-joins-dev-fund-supports-godot/ https://godotengine.org/article/jetbrains-joins-dev-fund-sup... and tbh I can't share your experiences since I'm using Rider. Even hot reload works really well without losing the running game state. > There's a good reason that there are barely any games using it, and they're all extremely technically simple Well, as of now when checking https://steamdb.info/tech/Engine/Godot/ https://steamdb.info/tech/Engine/Godot/ there are 6,109 games made with Godot engine on Steam with 2,568 of them having been released in that last 12 months so there is a strong growth going on right now. But I agree that most of those look technically simpler. > but rather a million DX papercuts that a good ambitious developer would just never accept I think you're generalizing a bit too much here. You're implying that the StS devs or the devs of Road to Vostok are not ambitious? I don't know man, there's more nuance to this. Don't get me wrong, I'm aware that Godot + C# still has a bunch of shortcomings and there's still some catch up to do but overall it's imo already quite pleasant to use.
  - bzzzt 9mo ago
    You can make up some 'critical defects' for every tool and engine in the universe. So what game engine is perfect for an 'ambitious developer' to use?
    - plopz 9mo ago
      bevy?
- socalgal2 9mo ago
  I don't know about it's use in godot but it's obvious it's not a problem to shipping a good game https://unity.com/blog/games/games-made-with-unity-2025-releases https://unity.com/blog/games/games-made-with-unity-2025-rele...
dandersch 9mo ago
Very true. While I believe there can be a place for a language tailored specifically for gamedev, GDScript certainly is not it. C# support seems to have been added reluctantly, because the prospect of attracting unity devs was to good to pass on. But then they switch over and realize it is treated like the ugly stepchild and the hope is that you will just use their scripting language to avoid the friction. And don't get me started on using GDExtension for other languages. Claiming C/C++ is available as a scripting languages in the same sentence as GDScript is a joke. I'll look into Libgodot, maybe it's an option.
- roflcopter69 9mo ago
  Can you please elaborate why you think C# is not really well integrated into Godot? I'm using it myself and it seems fine to me. There's quite a community around Godot + C# check out https://chickensoft.games https://chickensoft.games as well. FWIW the Slay the Spire 2 devs also seem to be happy with Godot + C#
  - dandersch 9mo ago
    For the record I would still choose C# out of all the options for a bigger game (GDscript with strict type-hinting might suffice for small ones). My main complaints that I can still remember: - deprecated web export for C# with Godot 4. This is basically my main gripe and why C# has been a non-starter for me. - Engine still has a separate binary for C# support. I think they are working on unifying them. But once you use the .NET one you can't export to web even when you don't use C#. - setting up debugging+lsp was a pain and consistency was very flaky afterwards Also a lot of the editor workflow is built around using GDScript with the built-in text-editor. I don't actually mind it that much, but you asked why it's not as well integrated and that's an obvious one for newbies. If your experience was wildly different, please do tell.
    - roflcopter69 9mo ago
      Thanks for sharing your experience. Mostly very fair points. Yes, exporting Godot + C# games to web is not possible right now and it seemingly takes the maintainers quite a lot of time to figure it out. It's apparently an official priority https://godotengine.org/priorities/#enable-users-to-export-their-csharp-projects-on-the-web https://godotengine.org/priorities/#enable-users-to-export-t... but I wouldn't hold my breath for now. Similarly for the new GDExtension based C# bindings https://github.com/raulsntos/godot-dotnet https://github.com/raulsntos/godot-dotnet which have been cooking for quite a while now. Those would make it possible to only have a single Godot build and get rid of the .Net build. Tbf, the maintainers were teasing that godot-dotnet will soon™ be ready for early testing so who knows. About setting up debugging+lsp, what were your struggles? Personally, I'm quite happy with JetBrains Rider Godot integration https://github.com/JetBrains/godot-support https://github.com/JetBrains/godot-support and JetBrains seems to be quite committed to supporting Godot https://godotengine.org/article/jetbrains-joins-dev-fund-supports-godot/ https://godotengine.org/article/jetbrains-joins-dev-fund-sup... you even get support for Edit and Continue (EnC), which is what's easy to confuse with hot reload but EnC is actually the thing that makes it possible to change C# code while the game is running and the changes are reflected without losing the game state. Really handy. AFAIK you can't get this with open source C# tools like netcoredbg so I'd understand if you'd think that the Godot + C# DevEx is quite lacking if you use something like Neovim or Zed. I think VSCode has actually pretty good support but the really good tech behind the C# extension is proprietary and cannot be used by forks like Cursor or Windsurf. But I totally agree, the GDScript integration is what Godot cares the most about and it shows in many places in the editor. So my experience is not wildly different in that sense. Just some different aspects I focus on maybe. But I'm always curious to see how people approach this stuff and what they feel about it.
cheeseomlit 9mo ago
Agreed 100%, C# is obviously a second-class citizen and I'm not going to waste my time with GDScript. It really is a shame because there are so many things to like about Godot, but the litany of issues with C# support due to their focus on GDScript has just soured the whole thing for me. Unity is just not an option as far as I'm concerned due to their bizarre licensing fiasco (and their own mountain of technical issues). So it's Monogame/FNA for me I suppose.
- cardanome 9mo ago
  > I'm not going to waste my time with GDScript. The GDScript hate is so odd. If you know any scripting language you know GDScript. How much time are you wasting when it takes one afternoon to learn? And nowadays it even has gradual typing support for those that are scared of dynamic types. I have seen C# devs coming to Godot being super prejudiced against GDScript and then end up using GDScript anyway because it is just more pleasant to use.
  - neonsunset 9mo ago
    [dead]
  - krapp 9mo ago
    I don't hate it, but I don't like it either. Mostly because I don't like the Python-style use of significant whitespace. But functions aren't first class citizens, making closures and lambdas awkward, type hinting isn't supported everywhere (such as with callables). I could probably come up with more petty gripes if I opened up a project and played with it. "pass" is an abomination to God. It's a lot better than it used to be and it gets the job done but I still find it ugly and awkward as a language. A more general complaint I have is that Godot tries to load every script regardless of whether it's actually included in the game hierarchy.
  - eatsyourtacos 9mo ago
    >for those that are scared of dynamic types. If you aren't scared of dynamic types for any type of semi-large project (like a game..) then you aren't qualified to talk about much.
poulpy123 9mo ago
It has been used for pretty successful games on steam
calibas 9mo ago
So use Rust instead, Godot supports bindings via FFI: https://godot-rust.github.io/ https://godot-rust.github.io/ I wont claim it works flawlessly, but you don't have to use GDScript or C# to program Godot. You can also use C++, Go, Java, Typescript, Zig, Scala, Kotlin and Swift: https://github.com/Godot-Languages-Support/godot-lang-support https://github.com/Godot-Languages-Support/godot-lang-suppor...
- robby_w_g 9mo ago
  I was able to hack together a toy game with godot-rust several years ago, and it had some rough edges but I was able to integrate Bevy’s ECS with godot’s editor and rendering. I’ve loosely followed its development since then, and the roughest parts seem to have been smoothed out. If it’s important to the dev, they can absolutely use rust
Eric_WVGG 9mo ago
Miguel de Icaza of Mono fame has a whole video on how C# was a "multi billion dollar mistake," and is working on a Swift Godot package. https://www.youtube.com/watch?v=tzt36EGKEZo https://www.youtube.com/watch?v=tzt36EGKEZo https://github.com/migueldeicaza/SwiftGodot https://github.com/migueldeicaza/SwiftGodot (I've had some fun dabbling with Swift Godot but all of the documentation seems to be a bit out of date)
- sfn42 9mo ago
  As a current C# web developer I think C# is amazing. I know multiple other languages (Java, JS, Python and others) fairly well and none of them measure up to modern C# in my opinion. Visual studio is trash though.
  - Eric_WVGG 9mo ago
    Garbage collection hiccups are probably meaningless on a web platform. As far as real-time processing goes, one of the most significant figures in the history of C# thinks it's a bad fit. If you disagree with him, respond to the video, I guess.
    - neonsunset 9mo ago
      [dead]
    - sfn42 9mo ago
      Yeah sure there are some issues with game development and garbage collection. It's fine for a lot of other stuff though. He says that too, still uses C#. I also think there's probably a lot of skill issue involved as well. I've seen the code written by the average developer, it isn't pretty. Very few developers actually write half-decent code. The vast majority write code that I'd just delete and rewrite rather than work with. Slow, buggy, messy, sloppy. And then they write a game and there's a bunch of problems because their code is ass and there's an angle where they can blame someone other than themselves so they do. And so the authors of Mono and Unity etc are held responsible, why can't they just fix their thing so that the bad developers can write bad code and still have a functioning game? And sure, if Swift can offer that then it seems Swift is the better choice for this application. But there's plenty of good games made with C# so clearly it's also possible to do so.

danbolt 9mo ago

My philosophy has always been “ergonomic scripting or drop to C++”, so I’m quite okay with it. C# has always felt a bit clunky to me. It’s nice to have alternatives.

clownpenis_fart 9mo ago
[dead]

roflcopter69 9mo ago

Is the GC in C# actually that much of a problem? Slay the Spire 2 is made with Godot + C# and the devs seem to be fine with it. Of course, it's probably not a computationally very demanding game but still the GC in C# does not seem to be a problem there.

eudamoniac 9mo ago
Yes it is a big problem. StS devs cannot write normal C# code, you have to really work around the C# integration to avoid lag spikes. See my other comment GitHub thread. There's also things like this https://github.com/godotengine/godot/issues/86926 https://github.com/godotengine/godot/issues/86926 and that the underlying types aren't compatible (Godot collections) that make it clear they aren't serious with the C# support. The other huge problem is the terrible external editor support, it does not work well at all. This means your vim, jetbrains, whatever muscle memory from a lifetime of professional dev work becomes useless, and you have to use a gimped text editor worse than notepad++. You can use an external editor, but then lots of things don't work very well, scenes get randomly corrupted, hot reloading doesn't work, etc. It's many issues like this that prove Godot's only priority is attracting and entertaining people who have never written code before, instead of making an engine viable for shipping games. I gave Godot a real chance for years, but at the end of the day it's a toy. There's a good reason that there are barely any games using it, and they're all extremely technically simple; surprisingly, that reason is not an unsophisticated underlying engine, but rather a million DX papercuts that a good ambitious developer would just never accept.
- neonsunset 9mo ago
  [dead]
- roflcopter69 9mo ago
  > StS devs cannot write normal C# code, you have to really work around the C# integration to avoid lag spikes Do you have any sources for this? A while ago I had a small chat with the StS devs on the Chickensoft Discord server and they didn't mention this. Instead they were overall just very positive about their Godot + C# experience. > The other huge problem is the terrible external editor support Have your recently tried JetBrains Rider for Godot + C# development? Lately, they've been quite actively improving the Godot integration https://github.com/JetBrains/godot-support https://github.com/JetBrains/godot-support and also showing some significant commitment https://godotengine.org/article/jetbrains-joins-dev-fund-supports-godot/ https://godotengine.org/article/jetbrains-joins-dev-fund-sup... and tbh I can't share your experiences since I'm using Rider. Even hot reload works really well without losing the running game state. > There's a good reason that there are barely any games using it, and they're all extremely technically simple Well, as of now when checking https://steamdb.info/tech/Engine/Godot/ https://steamdb.info/tech/Engine/Godot/ there are 6,109 games made with Godot engine on Steam with 2,568 of them having been released in that last 12 months so there is a strong growth going on right now. But I agree that most of those look technically simpler. > but rather a million DX papercuts that a good ambitious developer would just never accept I think you're generalizing a bit too much here. You're implying that the StS devs or the devs of Road to Vostok are not ambitious? I don't know man, there's more nuance to this. Don't get me wrong, I'm aware that Godot + C# still has a bunch of shortcomings and there's still some catch up to do but overall it's imo already quite pleasant to use.
- bzzzt 9mo ago
  You can make up some 'critical defects' for every tool and engine in the universe. So what game engine is perfect for an 'ambitious developer' to use?
  - plopz 9mo ago
    bevy?
socalgal2 9mo ago
I don't know about it's use in godot but it's obvious it's not a problem to shipping a good game https://unity.com/blog/games/games-made-with-unity-2025-releases https://unity.com/blog/games/games-made-with-unity-2025-rele...

dandersch 9mo ago

Very true. While I believe there can be a place for a language tailored specifically for gamedev, GDScript certainly is not it. C# support seems to have been added reluctantly, because the prospect of attracting unity devs was to good to pass on. But then they switch over and realize it is treated like the ugly stepchild and the hope is that you will just use their scripting language to avoid the friction. And don't get me started on using GDExtension for other languages. Claiming C/C++ is available as a scripting languages in the same sentence as GDScript is a joke. I'll look into Libgodot, maybe it's an option.

roflcopter69 9mo ago
Can you please elaborate why you think C# is not really well integrated into Godot? I'm using it myself and it seems fine to me. There's quite a community around Godot + C# check out https://chickensoft.games https://chickensoft.games as well. FWIW the Slay the Spire 2 devs also seem to be happy with Godot + C#
- dandersch 9mo ago
  For the record I would still choose C# out of all the options for a bigger game (GDscript with strict type-hinting might suffice for small ones). My main complaints that I can still remember: - deprecated web export for C# with Godot 4. This is basically my main gripe and why C# has been a non-starter for me. - Engine still has a separate binary for C# support. I think they are working on unifying them. But once you use the .NET one you can't export to web even when you don't use C#. - setting up debugging+lsp was a pain and consistency was very flaky afterwards Also a lot of the editor workflow is built around using GDScript with the built-in text-editor. I don't actually mind it that much, but you asked why it's not as well integrated and that's an obvious one for newbies. If your experience was wildly different, please do tell.
  - roflcopter69 9mo ago
    Thanks for sharing your experience. Mostly very fair points. Yes, exporting Godot + C# games to web is not possible right now and it seemingly takes the maintainers quite a lot of time to figure it out. It's apparently an official priority https://godotengine.org/priorities/#enable-users-to-export-their-csharp-projects-on-the-web https://godotengine.org/priorities/#enable-users-to-export-t... but I wouldn't hold my breath for now. Similarly for the new GDExtension based C# bindings https://github.com/raulsntos/godot-dotnet https://github.com/raulsntos/godot-dotnet which have been cooking for quite a while now. Those would make it possible to only have a single Godot build and get rid of the .Net build. Tbf, the maintainers were teasing that godot-dotnet will soon™ be ready for early testing so who knows. About setting up debugging+lsp, what were your struggles? Personally, I'm quite happy with JetBrains Rider Godot integration https://github.com/JetBrains/godot-support https://github.com/JetBrains/godot-support and JetBrains seems to be quite committed to supporting Godot https://godotengine.org/article/jetbrains-joins-dev-fund-supports-godot/ https://godotengine.org/article/jetbrains-joins-dev-fund-sup... you even get support for Edit and Continue (EnC), which is what's easy to confuse with hot reload but EnC is actually the thing that makes it possible to change C# code while the game is running and the changes are reflected without losing the game state. Really handy. AFAIK you can't get this with open source C# tools like netcoredbg so I'd understand if you'd think that the Godot + C# DevEx is quite lacking if you use something like Neovim or Zed. I think VSCode has actually pretty good support but the really good tech behind the C# extension is proprietary and cannot be used by forks like Cursor or Windsurf. But I totally agree, the GDScript integration is what Godot cares the most about and it shows in many places in the editor. So my experience is not wildly different in that sense. Just some different aspects I focus on maybe. But I'm always curious to see how people approach this stuff and what they feel about it.

cheeseomlit 9mo ago

Agreed 100%, C# is obviously a second-class citizen and I'm not going to waste my time with GDScript. It really is a shame because there are so many things to like about Godot, but the litany of issues with C# support due to their focus on GDScript has just soured the whole thing for me. Unity is just not an option as far as I'm concerned due to their bizarre licensing fiasco (and their own mountain of technical issues). So it's Monogame/FNA for me I suppose.

cardanome 9mo ago
> I'm not going to waste my time with GDScript. The GDScript hate is so odd. If you know any scripting language you know GDScript. How much time are you wasting when it takes one afternoon to learn? And nowadays it even has gradual typing support for those that are scared of dynamic types. I have seen C# devs coming to Godot being super prejudiced against GDScript and then end up using GDScript anyway because it is just more pleasant to use.
- neonsunset 9mo ago
  [dead]
- krapp 9mo ago
  I don't hate it, but I don't like it either. Mostly because I don't like the Python-style use of significant whitespace. But functions aren't first class citizens, making closures and lambdas awkward, type hinting isn't supported everywhere (such as with callables). I could probably come up with more petty gripes if I opened up a project and played with it. "pass" is an abomination to God. It's a lot better than it used to be and it gets the job done but I still find it ugly and awkward as a language. A more general complaint I have is that Godot tries to load every script regardless of whether it's actually included in the game hierarchy.
- eatsyourtacos 9mo ago
  >for those that are scared of dynamic types. If you aren't scared of dynamic types for any type of semi-large project (like a game..) then you aren't qualified to talk about much.

poulpy123 9mo ago

It has been used for pretty successful games on steam

calibas 9mo ago

So use Rust instead, Godot supports bindings via FFI: https://godot-rust.github.io/ https://godot-rust.github.io/ I wont claim it works flawlessly, but you don't have to use GDScript or C# to program Godot. You can also use C++, Go, Java, Typescript, Zig, Scala, Kotlin and Swift: https://github.com/Godot-Languages-Support/godot-lang-support https://github.com/Godot-Languages-Support/godot-lang-suppor...

robby_w_g 9mo ago
I was able to hack together a toy game with godot-rust several years ago, and it had some rough edges but I was able to integrate Bevy’s ECS with godot’s editor and rendering. I’ve loosely followed its development since then, and the roughest parts seem to have been smoothed out. If it’s important to the dev, they can absolutely use rust

Eric_WVGG 9mo ago

Miguel de Icaza of Mono fame has a whole video on how C# was a "multi billion dollar mistake," and is working on a Swift Godot package. https://www.youtube.com/watch?v=tzt36EGKEZo https://www.youtube.com/watch?v=tzt36EGKEZo https://github.com/migueldeicaza/SwiftGodot https://github.com/migueldeicaza/SwiftGodot (I've had some fun dabbling with Swift Godot but all of the documentation seems to be a bit out of date)

sfn42 9mo ago
As a current C# web developer I think C# is amazing. I know multiple other languages (Java, JS, Python and others) fairly well and none of them measure up to modern C# in my opinion. Visual studio is trash though.
- Eric_WVGG 9mo ago
  Garbage collection hiccups are probably meaningless on a web platform. As far as real-time processing goes, one of the most significant figures in the history of C# thinks it's a bad fit. If you disagree with him, respond to the video, I guess.
  - neonsunset 9mo ago
    [dead]
  - sfn42 9mo ago
    Yeah sure there are some issues with game development and garbage collection. It's fine for a lot of other stuff though. He says that too, still uses C#. I also think there's probably a lot of skill issue involved as well. I've seen the code written by the average developer, it isn't pretty. Very few developers actually write half-decent code. The vast majority write code that I'd just delete and rewrite rather than work with. Slow, buggy, messy, sloppy. And then they write a game and there's a bunch of problems because their code is ass and there's an angle where they can blame someone other than themselves so they do. And so the authors of Mono and Unity etc are held responsible, why can't they just fix their thing so that the bad developers can write bad code and still have a functioning game? And sure, if Swift can offer that then it seems Swift is the better choice for this application. But there's plenty of good games made with C# so clearly it's also possible to do so.