Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Godot 4.6 Release: It's all about your flow

godotengine.org

Post reply on HN
Print view View original

11–20 of 135 posts

Re: Godot 4.6 Release: It's all about your flow

#11

Post by roflcopter69 »

dandersch wrote: post #10
roflcopter69 wrote: post #9

Earlier quoted context omitted.

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 as well. FWIW the Slay the Spire 2 devs also seem to be happy with Godot + C#

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…

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-t... but I wouldn't hold my breath for now.

Similarly for the new GDExtension based C# bindings 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 and JetBrains seems to be quite committed to supporting 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.

Re: Godot 4.6 Release: It's all about your flow

#12

Post by dandersch »

roflcopter69 wrote: post #11
dandersch wrote: post #10

Earlier quoted context omitted.

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…

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-t... but I wouldn't hold my breath for now. Similarly for the new GDExtension based C# bindings https://github.com/raulsn…

> It's apparently an official priority

I've been following the github issue for C# web export and let me tell you: It's not been a priority.

> EnC makes it possible to change C# code while the game is running and the changes are reflected without losing the game state.

sounds exactly like code hot reload to me? It would be very nice to have.

> About setting up debugging+lsp, what were your struggles?

> Godot + C# DevEx is quite lacking if you use something like Neovim or Zed

you got me. I tried integrating a Godot workflow using neovim and at some point with emacs. Both were subpar. This actually reminds of another pain point: gdshader. Also very integrated with the editor just like GDscript, which makes it another thing you have to work on getting integrated with your IDE of choice - or you bite the bullet and just use the editor for this. But shaders are such a massive shitshow that I can't really blame Godot for this.

Re: Godot 4.6 Release: It's all about your flow

#13

Post by brooke2k »

dandersch wrote: post #8
eudamoniac wrote: post #5

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 b…

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…

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#.

Re: Godot 4.6 Release: It's all about your flow

#14

Post by eudamoniac »

roflcopter69 wrote: post #9
dandersch wrote: post #8

Earlier quoted context omitted.

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…

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 as well. FWIW the Slay the Spire 2 devs also seem to be happy with Godot + C#

https://github.com/godotengine/godot-proposals/issues/7842

For starters. Read through this thread and be appalled.

Re: Godot 4.6 Release: It's all about your flow

#15

Post by eudamoniac »

roflcopter69 wrote: post #7
eudamoniac wrote: post #5

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 b…

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.

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 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.

Re: Godot 4.6 Release: It's all about your flow

#16

Post by neonsunset »

eudamoniac wrote: post #15
roflcopter69 wrote: post #7

Earlier quoted context omitted.

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.

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 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 ext…

[dead]

Re: Godot 4.6 Release: It's all about your flow

#17

Post by cheeseomlit »

eudamoniac wrote: post #5

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 b…

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.

Re: Godot 4.6 Release: It's all about your flow

#18

Post by brooke2k »

dandersch wrote: post #12
roflcopter69 wrote: post #11

Earlier quoted context omitted.

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-t... but I wouldn't hold my breath for now. Similarly for the new GDExtension based C# bindings https://github.com/raulsn…

> It's apparently an official priority I've been following the github issue for C# web export and let me tell you: It's not been a priority. > EnC makes it possible to change C# code while the game is running and the changes are reflected without losing the game state. sounds exactly like code hot reload to me? It would be very nice to have. > About setting up debugging+lsp, what were your struggles? > Godot + C# Dev…

FWIW, Rider has very good support for keybindings - I can't vouch for vim bindings directly but their emacs keybinding scheme is brilliant, IMO it's the next closest thing to working from Emacs itself. So I'm guessing the vim bindings support is similarly fantastic.

I spent ages trying to get Emacs to work well with C# stuff, because I can't stand using IDEs that don't have some sort of emacs-style keybinding support, but eventually I bit the bullet and started using Rider and honestly it's been amazing and worked seamlessly with everything I've thrown at it (especially Godot). Highly recommended.

Re: Godot 4.6 Release: It's all about your flow

#19

Post by roflcopter69 »

eudamoniac wrote: post #15
roflcopter69 wrote: post #7

Earlier quoted context omitted.

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.

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 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 ext…

> 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 and also showing some significant commitment 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/ 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.

Re: Godot 4.6 Release: It's all about your flow

#20

Post by mieko »

For 3D, the return of in-engine inverse kinematic nodes (SkeletonModifier3D descendants) has been a big deal for me.

The old 3.x system was a mess, so it was dropped in 4.0. The community filled a lot of the gaps in the meantime, but having the new system (in-engine) is great.

I've been working with it for a few weeks from git master, and everything just works as I expect. It definitely needs some more user-level documentation, though: if I hadn't been following development, I don't think I'd know what everything does, and if someone were new to IK generally, it'd be hard to get off of the ground.

Post reply on HN