11 ms·

Godot 4.6 Release: It's all about your flow

247 points by makepanic 8mo ago

383toast 8mo ago
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.
lasgawe 8mo ago
this is one of the best applications I’ve ever used as open source
brooke2k 8mo ago
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_ 8mo ago
  > 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?
  - HelloNurse 8mo ago
    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.
jokoon 8mo ago
I am curious to see how much the editor have been increasing in executable size after each version
- Lalabadie 8mo ago
  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 8mo ago
    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 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 8mo ago
    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 8mo ago
    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 8mo ago
I'm pretty excited about libgodot! Let's see what use cases people can come up with for it.
- torginus 8mo ago
  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 8mo ago
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 8mo ago
  My philosophy has always been “ergonomic scripting or drop to C++”, so I’m quite okay with it. C# has always felt a bit clunky to me. It’s nice to have alternatives.
  - clownpenis_fart 8mo ago
    [dead]
- roflcopter69 8mo ago
  Is the GC in C# actually that much of a problem? Slay the Spire 2 is made with Godot + C# and the devs seem to be fine with it. Of course, it's probably not a computationally very demanding game but still the GC in C# does not seem to be a problem there.
  - eudamoniac 8mo ago
    Yes it is a big problem. StS devs cannot write normal C# code, you have to really work around the C# integration to avoid lag spikes. See my other comment GitHub thread. There's also things like this https://github.com/godotengine/godot/issues/86926 https://github.com/godotengine/godot/issues/86926 and that the underlying types aren't compatible (Godot collections) that make it clear they aren't serious with the C# support. The other huge problem is the terrible external editor support, it does not work well at all. This means your vim, jetbrains, whatever muscle memory from a lifetime of professional dev work becomes useless, and you have to use a gimped text editor worse than notepad++. You can use an external editor, but then lots of things don't work very well, scenes get randomly corrupted, hot reloading doesn't work, etc. It's many issues like this that prove Godot's only priority is attracting and entertaining people who have never written code before, instead of making an engine viable for shipping games. I gave Godot a real chance for years, but at the end of the day it's a toy. There's a good reason that there are barely any games using it, and they're all extremely technically simple; surprisingly, that reason is not an unsophisticated underlying engine, but rather a million DX papercuts that a good ambitious developer would just never accept.
mieko 8mo ago
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 8mo ago
Is there anything in this which will make it easier/better to make GUI applications? https://github.com/derkork/openscad-graph-editor https://github.com/derkork/openscad-graph-editor kind of has me considering using Godot for creating a drawing program....
- hiccuphippo 8mo ago
  Check Lorien, a whiteboard/drawing app made in Godot. https://github.com/mbrlabs/Lorien https://github.com/mbrlabs/Lorien
  - WillAdams 8mo ago
    Tried. It doesn't support palm rejection on a touch screen w/ a stylus, so is useless to me.
- _rousbound 8mo ago
  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.
  - dualogy 8mo ago
    > 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.
skrebbel 8mo ago
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 8mo ago
  > 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 8mo ago
    Thanks! I bet I've had it confused with something else then.
Fraterkes 8mo ago
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 8mo ago
  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.
  - nycdotnet 8mo ago
    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.
heyitssim 8mo ago
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 https://www.youtube.com/watch?v=mBLFv5R8jJI [2] https://craftmygame.com/ https://craftmygame.com/
glimshe 8mo ago
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 8mo ago
  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 8mo ago
    > 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 :)
    - georgeecollins 8mo ago
      Godot is surprisingly old. But I take your point.
mr_world 8mo ago
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 8mo ago
I really want to experiment with Godot but Unreal keeps giving me free assets....
- cardanome 8mo ago
  This exporter works really well for getting Unreal assets into Godot: https://relativegames.gumroad.com/l/unrealtogodot?a=290489843 https://relativegames.gumroad.com/l/unrealtogodot?a=29048984...
- galleywest200 8mo ago
  https://kenney.nl/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 https://itch.io also has a lot of free assets as well.
  - efilife 8mo ago
    These are not comparable to the UE assets at all
  - stefanka 8mo ago
    Another excellent source is https://quaternius.com/ https://quaternius.com/
OsrsNeedsf2P 8mo ago
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 https://ziva.sh
accrual 8mo ago
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.
- sph 8mo ago
  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 8mo ago
    Yeah, passing argument "--display-driver wayland" fixed the issue for me.
- helterskelter 8mo ago
  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 https://wiki.archlinux.org/title/Godot_Engine
  - accrual 8mo ago
    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.
pwdisswordfishs 8mo ago
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/react.html https://firefox-source-docs.mozilla.org/devtools/frontend/re...>

247 points by makepanic 8mo ago

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.

lasgawe 8mo ago

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

brooke2k 8mo ago

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_ 8mo ago
> 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?
- HelloNurse 8mo ago
  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.

jokoon 8mo ago

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

Lalabadie 8mo ago
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 8mo ago
  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 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 8mo ago
  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 8mo ago
  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 8mo ago

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

torginus 8mo ago
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 8mo ago

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 8mo ago
My philosophy has always been “ergonomic scripting or drop to C++”, so I’m quite okay with it. C# has always felt a bit clunky to me. It’s nice to have alternatives.
- clownpenis_fart 8mo ago
  [dead]
roflcopter69 8mo ago
Is the GC in C# actually that much of a problem? Slay the Spire 2 is made with Godot + C# and the devs seem to be fine with it. Of course, it's probably not a computationally very demanding game but still the GC in C# does not seem to be a problem there.
- eudamoniac 8mo ago
  Yes it is a big problem. StS devs cannot write normal C# code, you have to really work around the C# integration to avoid lag spikes. See my other comment GitHub thread. There's also things like this https://github.com/godotengine/godot/issues/86926 https://github.com/godotengine/godot/issues/86926 and that the underlying types aren't compatible (Godot collections) that make it clear they aren't serious with the C# support. The other huge problem is the terrible external editor support, it does not work well at all. This means your vim, jetbrains, whatever muscle memory from a lifetime of professional dev work becomes useless, and you have to use a gimped text editor worse than notepad++. You can use an external editor, but then lots of things don't work very well, scenes get randomly corrupted, hot reloading doesn't work, etc. It's many issues like this that prove Godot's only priority is attracting and entertaining people who have never written code before, instead of making an engine viable for shipping games. I gave Godot a real chance for years, but at the end of the day it's a toy. There's a good reason that there are barely any games using it, and they're all extremely technically simple; surprisingly, that reason is not an unsophisticated underlying engine, but rather a million DX papercuts that a good ambitious developer would just never accept.

mieko 8mo ago

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 8mo ago

Is there anything in this which will make it easier/better to make GUI applications? https://github.com/derkork/openscad-graph-editor https://github.com/derkork/openscad-graph-editor kind of has me considering using Godot for creating a drawing program....

hiccuphippo 8mo ago
Check Lorien, a whiteboard/drawing app made in Godot. https://github.com/mbrlabs/Lorien https://github.com/mbrlabs/Lorien
- WillAdams 8mo ago
  Tried. It doesn't support palm rejection on a touch screen w/ a stylus, so is useless to me.
_rousbound 8mo ago
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.
- dualogy 8mo ago
  > 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.

skrebbel 8mo ago

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 8mo ago
> 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 8mo ago
  Thanks! I bet I've had it confused with something else then.

Fraterkes 8mo ago

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 8mo ago
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.
- nycdotnet 8mo ago
  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.

heyitssim 8mo ago

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 https://www.youtube.com/watch?v=mBLFv5R8jJI [2] https://craftmygame.com/ https://craftmygame.com/

glimshe 8mo ago

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 8mo ago
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 8mo ago
  > 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 :)
  - georgeecollins 8mo ago
    Godot is surprisingly old. But I take your point.

mr_world 8mo ago

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 8mo ago

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

cardanome 8mo ago
This exporter works really well for getting Unreal assets into Godot: https://relativegames.gumroad.com/l/unrealtogodot?a=290489843 https://relativegames.gumroad.com/l/unrealtogodot?a=29048984...
galleywest200 8mo ago
https://kenney.nl/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 https://itch.io also has a lot of free assets as well.
- efilife 8mo ago
  These are not comparable to the UE assets at all
- stefanka 8mo ago
  Another excellent source is https://quaternius.com/ https://quaternius.com/

OsrsNeedsf2P 8mo ago

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 https://ziva.sh

accrual 8mo ago

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.

sph 8mo ago
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 8mo ago
  Yeah, passing argument "--display-driver wayland" fixed the issue for me.
helterskelter 8mo ago
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 https://wiki.archlinux.org/title/Godot_Engine
- accrual 8mo ago
  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.

pwdisswordfishs 8mo ago

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/react.html https://firefox-source-docs.mozilla.org/devtools/frontend/re...>