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!
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.
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.
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.
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.
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.
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.
> 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
Who better to do the battle-testing?
Godot is slowly becoming the next Blender, a dominant open source success story.
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 :)
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)I'd claim 80MB for an entire game engine + editor for said engine is very good.
Engines like Unity and UE include those in the primary download already.
https://github.com/derkork/openscad-graph-editor
kind of has me considering using Godot for creating a drawing program....
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.
https://docs.godotengine.org/en/latest/tutorials/ui/creating...
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.
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...>
https://itch.io also has a lot of free assets as well.
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.
[0] https://ziva.sh
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.
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.
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.
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.
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.
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 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".
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.
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.
Why?
> And the more places there are, the more spread out they'll be.
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.
- 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.
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.
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.
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.
For starters. Read through this thread and be appalled.
C# has always felt a bit clunky to me. It’s nice to have alternatives.
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...
https://unity.com/blog/games/games-made-with-unity-2025-rele...
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.
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.
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.
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)