[HN Gopher] Godot 4.6 Release: It's all about your flow
___________________________________________________________________
Godot 4.6 Release: It's all about your flow
Author : makepanic
Score : 215 points
Date : 2026-01-26 18:32 UTC (4 days ago)
(HTM) web link (godotengine.org)
(TXT) w3m dump (godotengine.org)
| brooke2k wrote:
| 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
| mon_ wrote:
| > 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?
| jokoon wrote:
| I am curious to see how much the editor have been increasing in
| executable size after each version
| Lalabadie wrote:
| 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)
| embedding-shape wrote:
| 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.
| ash-b-dev wrote:
| 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.
| riidom wrote:
| 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.
| roflcopter69 wrote:
| I'm pretty excited about libgodot! Let's see what use cases
| people can come up with for it.
| torginus wrote:
| 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.
| eudamoniac wrote:
| 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 wrote:
| 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.
| roflcopter69 wrote:
| 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 wrote:
| 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.
| roflcopter69 wrote:
| > 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.
| bzzzt wrote:
| 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 wrote:
| bevy?
| eudamoniac wrote:
| 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.
| kittiepryde wrote:
| 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 )
| socalgal2 wrote:
| 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...
| dandersch wrote:
| 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 wrote:
| 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#
| dandersch wrote:
| 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 wrote:
| 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(tm) 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.
| dandersch wrote:
| > 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.
| brooke2k wrote:
| 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.
| eudamoniac wrote:
| https://github.com/godotengine/godot-proposals/issues/7842
|
| For starters. Read through this thread and be appalled.
| brooke2k wrote:
| 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#.
| TulliusCicero wrote:
| Rider seems neat, and I'd be happy to purchase a license,
| but subscription only? No thank you.
| cheeseomlit wrote:
| 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 wrote:
| > 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.
| krapp wrote:
| 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 wrote:
| >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.
| foxygen wrote:
| Why?
| BoorishBears wrote:
| 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.
| cardanome wrote:
| 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".
| BoorishBears wrote:
| 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.
| cardanome 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.
| foxygen wrote:
| > dynamic types become more of liability as a project
| gets larger
|
| Why?
| BoorishBears wrote:
| > 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.
| foxygen wrote:
| 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(tm) 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.
| TulliusCicero wrote:
| 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.
| cardanome wrote:
| 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.
| TulliusCicero wrote:
| 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.
| plomme wrote:
| 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.
| cheeseomlit wrote:
| 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
| bj-rn wrote:
| Did you check out Stride? https://www.stride3d.net
| poulpy123 wrote:
| It has been used for pretty successful games on steam
| calibas wrote:
| 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...
| robby_w_g wrote:
| 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 wrote:
| 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)
| sfn42 wrote:
| 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 wrote:
| 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.
| mieko wrote:
| 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.
| WillAdams wrote:
| 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....
| _rousbound wrote:
| 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.
| pwdisswordfishs wrote:
| The future of cross-platform toolkits for graphical apps is
| Godot ("GDTK"?), instead of Electron?
| ranger207 wrote:
| 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
| presbyterian wrote:
| 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
| glimshe wrote:
| They made improvements in visualizing margins for Margin
| containers. A small but very useful enhancement.
| cridenour wrote:
| They just added docs for how to best achieve GUI apps.
|
| https://docs.godotengine.org/en/latest/tutorials/ui/creating...
| skrebbel wrote:
| 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!
| dismalaf wrote:
| > 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.
| skrebbel wrote:
| Thanks! I bet I've had it confused with something else then.
| lynndotpy wrote:
| 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
| skrebbel wrote:
| 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.
| pdpi wrote:
| 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)
| skrebbel wrote:
| Nah either it was Irrlicht or it was really just Godot
| and I simply incorrectly committed to memory what it was.
| hacker_88 wrote:
| LibGDX?
| Fraterkes wrote:
| Hats off to your son too, I'd say.
| pjmlp wrote:
| Great experience, thanks for sharing, a great way to get them
| motivated.
| lagniappe wrote:
| That's awesome! What type of game is your son making now?
| skrebbel wrote:
| 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
| socalgal2 wrote:
| > 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.
| npinsker wrote:
| 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.
| skrebbel wrote:
| 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").
| Fraterkes wrote:
| 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.
| TulliusCicero wrote:
| 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.
| heyitssim wrote:
| 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/
| glimshe wrote:
| 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.
| georgeecollins wrote:
| 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.
| embedding-shape wrote:
| > 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 :)
| mr_world wrote:
| 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
| pdntspa wrote:
| I really want to experiment with Godot but Unreal keeps giving me
| free assets....
| galleywest200 wrote:
| 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.
| stefanka wrote:
| Another excellent source is https://quaternius.com/
| efilife wrote:
| These are not comparable to the UE assets at all
| OsrsNeedsf2P wrote:
| 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
| accrual wrote:
| 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.
| helterskelter wrote:
| 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
| accrual wrote:
| 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.
| sph wrote:
| Never had any issues, using the Godots (sic) version manager
| from Flathub, and custom built versions from git. Something's
| wrong on your end
| accrual wrote:
| Yeah, passing argument "--display-driver wayland" fixed the
| issue for me.
| pwdisswordfishs wrote:
| 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...>
| 383toast wrote:
| 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.
___________________________________________________________________
(page generated 2026-01-30 23:01 UTC)