Godot 4.6 Release: It's all about your flow | Hacker News Reader

Godot 4.6 Release: It's all about your flow

godotengine.org

247 pointsmakepanic126 comments

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

I had never bothered pointing him to it, because I remembered Godot as "a bunch of C++ libraries for gamedev". I'm not even sure whether that's ever been the case or just an incorrect memory, but today's Godot is incomparable to that. The editor UI is very full featured, and you can easily make simple 2D games with relatively small amounts of programming. It includes a level editor, animation stuff, and so on. It's just very feature complete, and I think it's very impressive for a FOSS project to be so accessible to newcomers stumbling into it by chance. Points also to the people making videos.

Also sidenote I think GDScript is great. My son had tried Unity first, but the C# compile cycle was so slow that he kept getting out of the flow. As a developer dad, Godot's GDScript struck me as a super weird "not invented here" thing at first, but realizing what tradeoffs they're going for (familiarity, fast edit-compile-run cycle, concurrency, lightweight binding to C++ internals, etc), I now see the point completely. I'm sure it has plenty quirks but for a beginner like my son it's a perfect fit.

Bottom line, he was able to make a Flappy Bird clone and put it on his Android phone, totally solo (except the Android export, and with lots of YouTube support), in like two afternoons. Drew the art, coded the dynamics, everything. Hats off to the Godot team!

> because I remembered Godot as "a bunch of C++ libraries for gamedev".

Yeah it's never been that, it's always been an editor-driven engine. Started life as a proprietary game engine by a consultancy, then open sourced about a decade ago.

Super cool though, learning Godot at 13 is a great opportunity.

Thanks! I bet I've had it confused with something else then.

I would bet SDL; it's a C library that a ton of other libraries are influenced by or based on. It's not usually thought of as an engine on its own nowadays

Nah, like you said, SDL is just window creation and a bit of audio etc. If that counts as a "game engine" then so does every web browser.

EDIT: Sorry if I seem grumpy, I'm not actually grumpy at you, I'm grumpy at PyGame for calling itself a game engine when really it's just SDL + the ability to blend images.

> SDL is just window creation and a bit of audio etc.

It's a bit more than that, especially the current version. You're right that it isn't an engine in and of itself but you could probably build a decent engine on top of it. SDL3 + WASM + Lua would be chef's kiss.

I wasn't alive or making games at the time, as I was a baby, but I believe SDL would have been understood as an engine when it released.

I wouldn't call it one nowadays, except in so far that someone looking for an engine might find themselves happy with SDL (or PyGame, etc)

> SDL would have been understood as an engine

SDL is funny in that it kind of is an engine, à la Raylib, with SDL_Renderer (2D only), but most people use it just as a platform abstraction layer.

I don't get it. SDL has an event/messaging queue, cross-platform hardware support, basic collision detection, it packs its own stdlib, a cross-platform file storage API, a camera API, a pen API, asynchronous I/O, metadata/property support using its own hashmap, a geometry API that lets you throw triangles at the GPU, and other things, but all 99% of people ever seem do with it is open a window and an OpenGL context.

I've seen plenty of projects where people use it and reimplement things it already does because they want to minimize dependency. The entire point of using a library like SDL is dependency! Use all the things!

Might’ve been MonoGame? It sounds enough like Godot that you might’ve confused the two, it’s a code-first framework, and it’s popular enough that you might’ve heard of it (Stardew Valley, Bastion, and Celeste are all built on MonoGame)

Nah either it was Irrlicht or it was really just Godot and I simply incorrectly committed to memory what it was.

LibGDX?

Hats off to your son too, I'd say.

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.

That's awesome! What type of game is your son making now?

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 system so that'll take him some attempts for sure :D

might be geometry dash.

What OP is describing is Tomb of the Mask or in that genre. There’s a good GIF embedded here showing the navigation mechanic: https://en.wikipedia.org/wiki/Tomb_of_the_Mask

That’s the one!

> My son had tried Unity first, but the C# compile cycle was so slow that he kept getting out of the flow.

I'd like to know more about this. Were you comparing similar sized projects? I've only done very small projects in Unity and the cycle was near instant. Loading up some of their 3gig+ samples, there was an initial build that took 40+ mins but that's because it had 3gig of assets to process.

It’s probably not compilation, but “Domain Reloading” (https://docs.unity3d.com/2022.2/Documentation/Manual/DomainR...) which is laughably slow and on by default.

I think Unity does this because the same process is re-used for Play and Editor modes, whereas Godot does the normal thing and spawns a new process when testing.

My entire experience with Unity is "my kid said it took long to run the game he was trying to make". Sorry that I can't be more helpful. He might've been unreasonably impatient, I never looked over his shoulder when he was trying out Unity. All I know is that he says he likes Godot way more, in no small part because it's "faster" (and I'm pretty sure he doesn't mean engine performance when he says "faster").

wow, this release looks really cool! this part especially:

> With the new LibGodot, you can now embed the engine directly into your own applications. Instead of running Godot as a separate executable, you can control startup, manage the engine loop, and integrate it seamlessly into custom workflows.

it might seem like a small thing but the IoC setup of Godot makes it really annoying to build certain game infrastructure (specifically in my case, automated testing) because everything is beholden to the main engine loop, to the node tree getting mounted, etc. being able to take control of that and have the engine run under your own terms is super cool.

that being said, I'll probably wait for a couple versions before trying it out on my game since I'm sure it's not exactly battle-tested yet

> I'll probably wait for a couple versions before trying it out on my game since I'm sure it's not exactly battle-tested yet

Who better to do the battle-testing?

Indeed. If a test runner embedding the Godot engine is now feasible on paper a proof of concept implementation seems deserved: if there are fatal bugs or limitations they will be eventually corrected (sooner if properly discovered, reported and discussed), and if there are none the new technology is "battle-tested" enough.

The new UI is terrific. The old Godot was already pretty decent, allowing me to release my indie game on Steam. But this one is so much better.

Godot is slowly becoming the next Blender, a dominant open source success story.

To me it is so conceptually clean and easy to work with. Unity and Unreal are great products, but they also seem kind of clunky and bloated.

> but they also seem kind of clunky and bloated

Like their predecessors, they were initially conceptually clean and simple in the beginning too. But then decades of feature development, the scope creep overcomes the clean architectures and design decisions. Lets see if Godot remains the same in 10-20 years, I'm cautiously optimistic :)

Godot is surprisingly old. But I take your point.

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# and mostly use Godot as a frontend, crossing the boundary is kinda awkward and slow).

Having said that, I do agree that Godot has a bit of complicated identity: it is at once geared towards being a good first programming experience, and a general purpose replacement for stuff like Unity.

I'd prefer a focus on the second part, there's a huge industry of game-devs right now, and providing them with the stability of a solid, free, transparent engine would be a great service.

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.

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 have drifted away from your question, but the point is that I love Godot for gaming, and I can handle GDScript plus the engine editor, but for writing a complete application I would want to develop in my language/editor/ecosystem of choice.

In that sense, LibGodot(plus GDExtension) may help indirectly developing GUI applications by letting people own Godot in their ecossystem of choice.

The future of cross-platform toolkits for graphical apps is Godot ("GDTK"?), instead of Electron?

A fork of Godot optimized for native apps would be a good idea. Especially if it learned the lessons of the web stack and used basic text-based formats for describing layout and theming (like HTML and CSS). Maybe something like QT. Something simple, flexible and portable that's as easy to use as Electron but doesn't require lugging around a 60mb Chromium instance for every application.

Some work would need to be done improving text rendering, layout and to add more GUI elements. Probably a lot of stuff removed from the backend that isn't necessary (apps won't need physics or lighting, probably.)

I made a basic theme loader for a project ages ago based on the config file format because dealing with theming and fonts was a pain at the time. Nothing novel, it was just a dictionary that had node paths as keys and set values. It is possible, I don't know why Godot makes some things more complicated than they need to be.

This is how GTK came about. Literally "GIMP Toolkit". They took the widgets that the GIMP creators had created, and turned it into a general-purpose toolkit for other apps to use, due to issues with Qt.

The comments about web stack stuff is probably off. Godot is already a pretty featureful UI framework + form designer that makes anything the "frontend" world has ever produced seem like they only had a fraction (1-to-10%) as much time and resources to build, compared to what Godot was already shipping in 1.0, (even though the reverse is true).

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

Yes! I am aware of that functionality, and I've tried it, but this just substitutes the Godot code editor with an external one while keeping the rest of the Godot editor.

In short terms, Godot development workflow has three pieces at least: editor interface(nodes, viewport, etc) + code editor(can be external through LSP) + game/app running.

What I'm trying to say is that app development doesn't strictly need the editor interface at all. For instance, when I'm developing an app with web technology I usually just have a text editor on the left, with my language of choice server side rendering html, and the browser on the right with the "app running".

It would be lovely to spawn the Godot editor and drag around interface components experimenting with them(like the inspector tool on browsers), but usually I just want the peace of mind of having the code and the app running.

So what I'm envisioning is that it would be possible to call Godot in my language of choice just like I would call a normal framework(PyGame in python, Love2D in Lua). With the difference of the powerhouse of functionalities that Godot carries, and the possibility of launching the full editor if desired.

I'm working right now on an app in Godot to support a tabletop game. Their UI framework is pretty nice IMO. It really helps that the editor itself is made in Godot, so they have a lot of real usage of their UI system already

I don't know about the new features, but you could definitely make a drawing program in Godot already. There are a couple really good RPG map-making tools in Godot, and that's basically a drawing app where your brushes are trees and buildings

They made improvements in visualizing margins for Margin containers. A small but very useful enhancement.

They just added docs for how to best achieve GUI apps.

https://docs.godotengine.org/en/latest/tutorials/ui/creating...

Check Lorien, a whiteboard/drawing app made in Godot.

https://github.com/mbrlabs/Lorien

Tried. It doesn't support palm rejection on a touch screen w/ a stylus, so is useless to me.

I'm pretty excited about libgodot! Let's see what use cases people can come up with for it.

Afaik due to how .NET webassembly works, it expects to own the main loop, so I think the main motivator of this change was to enable .NET in Wasm builds.

I tried gamedev before, but was never able to fully commit to getting over the learning curve for Unity and Unreal. Godot has proved much easier to just jump in and make things. I really like where the project is heading. Godot + Blender = the dream

I am curious to see how much the editor have been increasing in executable size after each version

Comparing the win64 build for each version. For 12 years of growing scope, that seems pretty good to me:

  1.0 – 9.4  MB (2014)
  2.0 – 12.3 MB (2016)
  3.0 – 20.2 MB (2018)
  4.0 – 51.6 MB (2022)
  4.6 – 79.4 MB (2026)

As something to compare to, I picked a random repository from what GitHub Explore showed, clicked on the first that looked like a desktop application (https://github.com/siyuan-note/siyuan/releases/tag/v3.5.4), and their Windows binary is currently 166MB for a "privacy-first, self-hosted, fully open source personal knowledge management software".

I'd claim 80MB for an entire game engine + editor for said engine is very good.

That is actually pretty amazing for a game engine. I'm not a game dev and I've only ever made some tiny games in Unity back in college but this makes me want to install Godot and try making games again.

What is to note here, this is without export templates, these are ~800MB extra (200 per platform, but it seems like you can download only all at once nowadays).

Engines like Unity and UE include those in the primary download already.

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.

Does anybody have tips for running Godot on KDE Plasma + Wayland? I tried 4.0 and an earlier 3.x release from the store but both hung shortly after startup. Maybe need some Wayland argument, will check.

From Archwiki:

Godot runs on Wayland using Xwayland, which causes a variety of UI issues, when not running in single window mode. [1] To get around this, start Godot with godot --single-window, then open a project, and enable single window mode in the editor settings.

This issue has been resolved in Godot 4.1.1. [2] This issue seems to have recurred in Godot 4.2 [3]

With Godot 4.3, Wayland can be used natively. [4] There are two ways to do this:

    Set the command-line argument --display-driver wayland.
    Enable the editor setting located at run/platforms/linuxbsd/prefer_wayland.

The above only makes Godot's client to run under native Wayland, but games still run under Xwayland. In order for games to run under native Wayland, go to project settings, click on "Display Server" at the sidebar, and at the option "Driver.linuxbsd" select wayland.

https://wiki.archlinux.org/title/Godot_Engine

Cheers, that worked! 4.6 is working great on Wayland. I created a new .desktop shortcut pointed to Godot_v4.6-stable_linux.x86_64 with argument "--display-driver wayland". Working flawlessly, thank you.

Glad it worked! Archwiki is a fantastic resource.

Never had any issues, using the Godots (sic) version manager from Flathub, and custom built versions from git. Something’s wrong on your end

Yeah, passing argument "--display-driver wayland" fixed the issue for me.

Love the workflow focus in this release. 2D animations/hitboxes and terrain creation was tedious enough that I built a tool around it—draw, animate, export to Godot if anyone needs it. It also now become a full game engine!

[1] https://www.youtube.com/watch?v=mBLFv5R8jJI

[2] https://craftmygame.com/

With all these editor improvements, we should now be waiting for someone to realize that a soft fork + a thoughtful plugin-based architecture using the original as a base means that lots of the effort that has gone into Godot's (snappy) UI could be repurposed and make for better web development inspector/debugger experience than using browsers' own built-in tools.

A "native" text editor, style properties viewer, profiler timeline, (and more, e.g., animation curve editor), instead of the ones we've got (like the one in Firefox, that they wrote in React[1] where you can see visible, whole-panel flicker when the UI repaints itself every time the cursor blinks)? Yes, please.

1. <https://firefox-source-docs.mozilla.org/devtools/frontend/re...>

I really want to experiment with Godot but Unreal keeps giving me free assets....

https://kenney.nl/assets has a LOT of public domain assets for use if you just want to experiment with the engine.

https://itch.io also has a lot of free assets as well.

Another excellent source is https://quaternius.com/

These are not comparable to the UE assets at all

This exporter works really well for getting Unreal assets into Godot: https://relativegames.gumroad.com/l/unrealtogodot?a=29048984...

this is one of the best applications I’ve ever used as open source

Do any of these changes make it easier to vibe code games in Godot? Or make it easier to make an MCP server for Godot? Saw LibGodot and the work in GDExtension but unsure if those are relevant for AI dev.

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.

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.

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.

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

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?

bevy?

Unity, Unreal, Monogame are a few engines via which ambitious games are regularly shipped. Godot is not among them because Godot has very few good games in it, with a terrible use:release ratio, which is in turn because it is primarily a game dev tutorial platform.

I'm not sure if there is any example of a studio or person making their second game in Godot when their first was not, and this rare occurrence seems to me a product of the "wow this shit is just not a serious engine compared to what I was using" effect.

Games are very complicated to make and take a very long time. Any unneeded friction will compound into games not getting shipped at all most of the time. Godot is uniquely frictional outside the basic happy path.

Don't all game engines have a terrible use:release ratio? How did you determine that ratio for Godot and Unity and does it matter? You can't blame the engine for all occurrences of beginners losing interest in building a game.

While 3D is still in heavy development it's actually easier to build simple 2D games in Godot. You can finish a simple game before the Unity installer is finished. Game engines aren't a fixed thing either. Assuming improvements continue Godot will get easier to use and gain market share.

I use visual studio pro and when I hit F5, my game runs in the godot ide. I can pipe the log output back to visual studio. So, I think the integration is quite good, imo. ( sorry for formatting on phone )

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

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.

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

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.

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

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.

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

For starters. Read through this thread and be appalled.

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 confused, does that help me with Rider?

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.

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

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.

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

Why?

Without agreeing (or disagreeing) with their larger point, dynamic types become more of liability as a project gets larger

Like "schemaless" database applications, there's always types/schema somewhere: the choice is if they'll be explicitly defined at the place of construction, or implicitly spread out across all the places data happens to flow in your application. And the more places there are, the more spread out they'll be.

Static typing is also really nice for game dev since proper unit tests are harder (but not impossible) compared to your average CRUD app.

The other side of the argument is that dynamic typing is great for prototyping and can allow for more compact code.

The discussion is exhausting because many people don't understand the difference between weak typing and dynamic typing. You basically never want weak typing but dynamic typing has legit uses. Yes JS is both weakly and dynamically typed and that sucks but Common Lisp shows you can have very strong typing and dynamic types.

Lots of very complex software has been writing in dynamically typed languages. The whole Erlang/Elixir world is dynamically typed though Elixir is getting gradual typing.

There is a good reason gradual typing is getting popular, you get the best of both world. You can prototype quickly and then add types and make everything more solid later.

(Which also why you want to always use a statically typed language in the corporate world because there is never a "later" and the bigger the team the more important it is to have the lang enforcing discipline. But not every programming is corporate.)

People that are dogmatic about static typing show their immaturity. The older I get the more I realize that there is no right or wrong way to program, everything it tradeoffs and "it depends".

Exactly which part of my comment seems dogmatic?

You literally start your comment by reaffirming my point (prototyping, like when you tend to have a smaller code base?)

Feels like you replied to a comment you imagined based on past interactions, not anything I actually wrote.

> Exactly which part of my comment seems dogmatic

I never said that any part of your comment is dogmatic. This is not private conversation where I am talking to you directly.

I wrote

> People that are dogmatic about static typing show their immaturity

Referring to the people like eatsyourtacos who started this discussion.

> dynamic types become more of liability as a project gets larger

Why?

> there's always types/schema somewhere: the choice is if they'll be explicitly defined at the place of construction, or implicitly spread out across all the places data happens to flow in your application.

> And the more places there are, the more spread out they'll be.

You can still have schema validation at the borders of the application(data in/out) without static typing.

I think there are many other factors that come into play when it comes to maintaniblity of large projects. I'd easily choose to maintain a large Elixir or Common Lisp codebase over a Java one, assuming they were all using the Best Practices™ of their respective languages.

There is research out there, and there is absolutely zero evidence that static typing catches more bugs than dynamic types. My experience is that immutability, functional programming, simplicity and testing pays a MUCH bigger role in maintainability than static typing.

Dynamic typing has trade-offs, and so does static typing, HUGE trade-offs by the way. But for some reason, no one seems to mention them... ever.

Silly me for falling for the bait after two one-word replies in a row.

If I need to specify this is about data flow inside your application when we're talking about typing, I don't want think we're having the same conversation.

Hopefully someone else will want to mud wrestle on this.

Still doesn't have full static typing support to my knowledge, which is a dealbreaker to me.

The other things are that it just has less support for structuring your code in different ways, and of course the performance is vastly worse. My game does some state space exploration for the enemy AI, so having code that runs an order of magnitude slower just doesn't work for me.

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.

But then I have to code in those other languages, languages that require manual memory management that I'm not as familiar with. C# is many times faster than gdscript, and I don't have to think about memory hardly at all. And it's easy enough to code the whole game in it.

You can use C#. It is well supported except for the (currently) missing web target and Microsoft is funding C# support so it will not get abandoned.

You can also use other garbage collected languages. I once tried the Lua bindings and they worked fine.

The problem with C# is that its garbadge collection is not really suited for game dev. The creator of the Mono runtime actually calls using C# his Multi-million dollar mistake and instead works on swift bindings for Godot: https://www.youtube.com/watch?v=tzt36EGKEZo

But if you really love C# nothing is stopping you. I prefer GDScript.

I know, I already use C# for Godot. My original comment was just to explain why I don't use gdscript.

Swift might be cool too, I've only used it a bit but I liked what I saw.

rust and swift don't require manual memory management. rust is RAII and swift is either value types or reference-counted.

(yeah there are escape hatches, but it's weird to use them)

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 would not choose that, because that doesn't make any sense to do. Writing code is like 90% of the work if I hire artists. I am not going to do 90% of years of work in a shitty language, because I don't have to do that, being a skilled developer in real languages.

So when people come out and defend gdscript for being not that bad, it's like, okay, but it's still really shitty compared to any normal language like C# or even Python. It is made by a game engine, used by thousands of people, instead of being made by gorillions of dollars poured into it by tech companies and used by millions of people. I'm just going to use good languages instead.

The Godot devs tried bindings to other languages first and it sucked: https://docs.godotengine.org/en/stable/about/faq.html#what-w...

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.

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!

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 some concerning instances of Exported properties losing their saved values, though in that case they can at least be restored from previous versions of the .tscn file from version control

I find it amusing how Unity gets hate for domain reloading when it's this inevitable.

Did you check out Stride? https://www.stride3d.net

It has been used for pretty successful games on steam

So use Rust instead, Godot supports bindings via FFI: 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-suppor...

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

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://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)

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.

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.

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.

Shameless self plug: I was tired of the limitations of Godot with Claude Code, so I made Ziva[0]. In addition to just writing Gdscript and shaders, it interacts with the rest of the editor via MCP, all without leaving the Godot interface

[0] https://ziva.sh

Reply on news.ycombinator.com