Godot 4.0 Stable(github.com)
github.com
Godot 4.0 Stable
https://github.com/godotengine/godot/releases/tag/4.0-stable
108 comments
I can't agree with you more about how demotivating Unity is to work with. waiting for 5 seconds every time I save a C# file and another 5 seconds when I press play (on a new, small project), rolling a d4 to see if the engine crashes, fighting VCS with random changes to files I haven't touched every time I open the editor, absolutely no clear direction about how I should be building if I start a project today.. I could go on and others already have.
it's sad, because I can see what Unity could be (and what it used to be), and it is just not there right now.
I still haven't "clicked" with Godot, but I'm eager to give v4 a try now that it is officially released.
it's sad, because I can see what Unity could be (and what it used to be), and it is just not there right now.
I still haven't "clicked" with Godot, but I'm eager to give v4 a try now that it is officially released.
[deleted]
I just don't understand why more gamedevs don't work in pure code like libsdl and C++, it is very liberating.
because the code is only one, comparatively small, element of making a modern game.
I've been using Godot 3 for 2+ years. It's great. There's some downsides to Godot for sure, but I think they will all be resolved over time.
I could work on Godot for the rest of my life. It brings me great joy to contribute to the engine. I would never feel comfortable writing Unity code again, as I do not want any other commercial interests injected into my artwork, my hobbies and my craft.
Godot is truly a public good.
I could work on Godot for the rest of my life. It brings me great joy to contribute to the engine. I would never feel comfortable writing Unity code again, as I do not want any other commercial interests injected into my artwork, my hobbies and my craft.
Godot is truly a public good.
I have been using Unity a long time and in general appreciate it, despite it's many many quirks and rough edges.
That said I'm extremely excited to see an open source alternative that looks to have a very active community around it and that looks to be doing great things!
If blender has taught me anything, it's that having a fantastic free and open source tool in a sea of commercial offerings benefits everyone.
The paid offerings are forced to up their game, the consumer benefits with more competitive pricing and those that can't afford to buy tools have a great product at their disposal in which to learn and create.
That said I'm extremely excited to see an open source alternative that looks to have a very active community around it and that looks to be doing great things!
If blender has taught me anything, it's that having a fantastic free and open source tool in a sea of commercial offerings benefits everyone.
The paid offerings are forced to up their game, the consumer benefits with more competitive pricing and those that can't afford to buy tools have a great product at their disposal in which to learn and create.
I used Unity for a long time and I appreciate it as well. Last couple years I havent liked the direction that unity is going. The docs and usability have regressed imo.
[deleted]
Do you use GDScript or C#? Just curious, I feel like most developers just use GDScript as opposed to C# but I'm not sure how wrong I am on that.
GDScript for UI and prototyping, c++ for the game logic when its needed or when the game design is stable and we have time to rewrite it. I want to write a GDScript -> C++ transpiler, to be honest.
I wouldnt want to use c# as I dont want the complexity. Our games go on the web, as well, and I don't think c# works there.
godot-Nim is an attractive project, as well.
I wouldnt want to use c# as I dont want the complexity. Our games go on the web, as well, and I don't think c# works there.
godot-Nim is an attractive project, as well.
C# definitly works on WebAssembly.
https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...
https://opensilver.net/
https://platform.uno/
https://avaloniaui.net/
https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...
https://opensilver.net/
https://platform.uno/
https://avaloniaui.net/
In this context it's nice to know Godot supports that use case as well: https://godotengine.org/article/csharp-wasm-aot/
Godot 4.0 doesn't support C# on the web and mobile, one of those fabled "Godot $nextver fixes this" things that somehow immediately come up whenever I get hyped up for giving Godot another try.
I think most do use GDScript, but the C# support is very good. If you need great performance in your game scripts, or are familiar with C#, best to start with that.
I am familiar with both C# and Python so I'm in a weird boat where I could use either GDScript since it seems familiar to Python, or C#.
It’s great to read this. I dabbled and make demos from time to time (in other engines) and show them to friends.
Could you list some of those downsides you mention? Not just for me, developers sometimes also read things here on HN that are *not* on their Issues or on their radar at all.
Have fun!
Could you list some of those downsides you mention? Not just for me, developers sometimes also read things here on HN that are *not* on their Issues or on their radar at all.
Have fun!
> 1,500 individual contributors across engine and docs.
I feel like this is an outstanding achievement. I've never contributed to Godot, but somebody must be doing something right and making people feel welcome. I may have to check it out.
I feel like this is an outstanding achievement. I've never contributed to Godot, but somebody must be doing something right and making people feel welcome. I may have to check it out.
Akien does a great job managing the PRs. They have a decent system to enable them to review quickly and the core team does a ton of code reviews. Once you start contributing to Godot, it's pretty addicting.
>They have a decent system to enable them to review quickly and the core team does a ton of code reviews.
Are there other open source projects like this? My biggest blocker from contributing to open source have always been the slow to never happening code reviews.
Are there other open source projects like this? My biggest blocker from contributing to open source have always been the slow to never happening code reviews.
In my experience this is one of the keys to a good OSS project along with rapid ticket response/triage.
Congrats to all the people involved, it's really great to see such a FOSS tool!
How is it for app development? I've seen that they have started to showreels for apps (https://godotengine.org/article/announcing-godot-2022-showre...) and it's quite impressive. I'm wondering if it can be a good alternative to stuff like Qt/Qt Quick for rapid prototyping, or even production app.
The easy export to multiple platforms is a really an interesting point. I'm mostly wondering if it can handle correctly stuff like accessibility, desktop integration, and if it's good at handling texts (Unicode, RTL, etc).
How is it for app development? I've seen that they have started to showreels for apps (https://godotengine.org/article/announcing-godot-2022-showre...) and it's quite impressive. I'm wondering if it can be a good alternative to stuff like Qt/Qt Quick for rapid prototyping, or even production app.
The easy export to multiple platforms is a really an interesting point. I'm mostly wondering if it can handle correctly stuff like accessibility, desktop integration, and if it's good at handling texts (Unicode, RTL, etc).
It was used for:
https://github.com/derkork/openscad-graph-editor
which I've been using quite successfully.
https://github.com/derkork/openscad-graph-editor
which I've been using quite successfully.
I tried one of the beta releases and successfully migrated a small toy project that I had been working on in Unity. It's remarkable how much Godot has improved. The new 2D tilemap editor in 4.0 is really good. I was also really happy to see that the type system in the Godot scripting language is a lot more comprehensive now.
It's pretty remarkable how much faster and cleaner the Godot developer experience is compared to Unity. I feel like a spend a huge amount of my Unity development time waiting for the compiler and fighting with the tools. In Godot, the development iteration loop is much faster. I can't really speak to 3D capabilities, but for 2D projects I'm totally sold on Godot and see no reason to ever go back to Unity.
It's pretty remarkable how much faster and cleaner the Godot developer experience is compared to Unity. I feel like a spend a huge amount of my Unity development time waiting for the compiler and fighting with the tools. In Godot, the development iteration loop is much faster. I can't really speak to 3D capabilities, but for 2D projects I'm totally sold on Godot and see no reason to ever go back to Unity.
Godot is one of those pinnacle FOSS projects that just totally impresses me, especially given the state its in now, with 4.0. It's so cool that a loose community of "The People" have created things like Godot, OBS, and Blender. What a time to be alive.
> Godot is one of those pinnacle FOSS projects that just totally impresses me, especially given the state its in now, with 4.0.
It is definitely one of the success stories, at least so far.
For example, there are projects like jMonkeyEngine (a game engine in Java, on top of LWJGL) that don't get as much attention and their movement forwards is way slower: https://jmonkeyengine.org/
There's also Stride 3D, which is a bit closer to Unity I'd say, which is still a really nice project, but is also limited in how much development can be done: https://www.stride3d.net/
Regardless, I wish all of those projects success and would still be glad if Godot could be one of the champions of open source game engines, perhaps as a viable and easy to use alternative to something like Unity for those who want that sort of thing, even in the professional development space eventually!
It is definitely one of the success stories, at least so far.
For example, there are projects like jMonkeyEngine (a game engine in Java, on top of LWJGL) that don't get as much attention and their movement forwards is way slower: https://jmonkeyengine.org/
There's also Stride 3D, which is a bit closer to Unity I'd say, which is still a really nice project, but is also limited in how much development can be done: https://www.stride3d.net/
Regardless, I wish all of those projects success and would still be glad if Godot could be one of the champions of open source game engines, perhaps as a viable and easy to use alternative to something like Unity for those who want that sort of thing, even in the professional development space eventually!
OBS is amazing...except for the complete lack of 'undo' support. Just feels so bizarre to be missing such a basic UI feature.
I'm 41 and just getting into game development. I've been kind of weighing my options for awhile, and waiting for Godot 4 to come out. This is rad.
The only complaint I have is that the scale of the GUI is ridiculous. It's not like I'm running some crazy resolution. Why is it so small? Why hasn't it been complained into options to scale it? I literally cannot read the project creation interface without using Windows zoom.
The only complaint I have is that the scale of the GUI is ridiculous. It's not like I'm running some crazy resolution. Why is it so small? Why hasn't it been complained into options to scale it? I literally cannot read the project creation interface without using Windows zoom.
Editor -> Editor Settings -> interface -> Display Scale
Oh, thank you for that. I missed those settings completely - mostly because I couldn't read them haha.
I'm also 41, and would have the same feedback if I steeled myself to learning something new like game development. These keen-eyed kids and their crazy resolutions!
I really tried to like Godot, using it to make a node-based logic editor. But GDScript is incredibly bad at handling data, as well as having terrible editor support (and the built in editor is bad), which made things incredibly difficult. It doesn't even have first class functions or support for doing multiple HTTP requests at once to a single endpoint if you don't make multiple callback functions, one for each request. And the signals system, allegedly meant to reduce spaghetti, only increased it. The inability to put multiple scripts on a object and use of inheritance over composition only made things worse.
I tried the Rust integration but the API was very rough around the edges and there was huge amounts of unsafe where I really wasn't sure how I was meant to verify its usage.
In the end I switched to Bevy+egui. Progress is good, typing is strong, and while some things are more difficult, I'm not tearing my hair out about basic things.
I tried the Rust integration but the API was very rough around the edges and there was huge amounts of unsafe where I really wasn't sure how I was meant to verify its usage.
In the end I switched to Bevy+egui. Progress is good, typing is strong, and while some things are more difficult, I'm not tearing my hair out about basic things.
Anecdotal but most people I've ran into that are writing non-trivial Godot apps are using C# for these reasons.
> 4 years of development.
For some perspective, console generations are usually around 6-7 years. Given their stated AAA aspirations, I wonder what the future development process will actually look like, because another dark age like from Godot 3 to 4 would be a deal breaker. It's easy to say "future 4.x releases will come with a much faster cadence", but it's also easy to decide that something else absolutely needs to be rebuilt from the ground up in a multi-year effort.
But negativity aside, finally having a stable release is great. Godot is a really nice engine, and definitely a huge step up from the existing commercial engines in terms of usability.
For some perspective, console generations are usually around 6-7 years. Given their stated AAA aspirations, I wonder what the future development process will actually look like, because another dark age like from Godot 3 to 4 would be a deal breaker. It's easy to say "future 4.x releases will come with a much faster cadence", but it's also easy to decide that something else absolutely needs to be rebuilt from the ground up in a multi-year effort.
But negativity aside, finally having a stable release is great. Godot is a really nice engine, and definitely a huge step up from the existing commercial engines in terms of usability.
Unreal:
UE1: 1998 (some had access in 1996)
UE2: 2002 (announced 1998)
UE3: 2006 (announced 2004)
UE4: 2014 (announced to be in development in 2005, imminent in 2012)
UE5: 2022 (announced 2020)
The development cycles of Godot seems pretty comparable to the competition? The only difference is that by being an open source project, people can see the new engine is being worked on before a marketing department for a commercial engine would reveal it.
UE1: 1998 (some had access in 1996)
UE2: 2002 (announced 1998)
UE3: 2006 (announced 2004)
UE4: 2014 (announced to be in development in 2005, imminent in 2012)
UE5: 2022 (announced 2020)
The development cycles of Godot seems pretty comparable to the competition? The only difference is that by being an open source project, people can see the new engine is being worked on before a marketing department for a commercial engine would reveal it.
It's not about version numbers. I wasn't a UE3 licensee, but I'd imagine that came with decent support and the release of features to keep pace with the industry at the time. Godot obviously can't be expected to provide Epic Games-level support, but the main development efforts from the OSS team was split since they were (understandably) focused on Godot 4. So all of the improvements/changes in 4 were completely useless to most users during that time, who were realistically only going to be able to use 3.5.
There was no hint of a release date, a roadmap, or anything like that. It felt like Godot 4 was going to be stuck in development hell forever, meanwhile people trying to actually build a game would be stuck on the increasingly obsolete and divergent 3.5 (unless you were willing/able to maintain an incomplete engine during development). So that was essentially 4 years of nothing to most people (tbf 3.5 did continue to get bug fixes during that time).
I say this not to trash on the Godot team's work, but rather to say that I think they should focus less on improving the engine for the sake of it, and more on work that seeks to increase the direct value it provides to users (which includes potential customers of W4 Games).
There was no hint of a release date, a roadmap, or anything like that. It felt like Godot 4 was going to be stuck in development hell forever, meanwhile people trying to actually build a game would be stuck on the increasingly obsolete and divergent 3.5 (unless you were willing/able to maintain an incomplete engine during development). So that was essentially 4 years of nothing to most people (tbf 3.5 did continue to get bug fixes during that time).
I say this not to trash on the Godot team's work, but rather to say that I think they should focus less on improving the engine for the sake of it, and more on work that seeks to increase the direct value it provides to users (which includes potential customers of W4 Games).
> It felt like Godot 4 was going to be stuck in development hell forever, meanwhile people trying to actually build a game would be stuck on the increasingly obsolete and divergent 3.5 (unless you were willing/able to maintain an incomplete engine during development). So that was essentially 4 years of nothing to most people (tbf 3.5 did continue to get bug fixes during that time).
???
What are you talking about, the 3.x branch was being worked on and had new releases during most of that time.
3.5 itself only came out in August 2022, so between that and 4.0 was a massive...six months or so? Why is waiting six months a problem?
???
What are you talking about, the 3.x branch was being worked on and had new releases during most of that time.
3.5 itself only came out in August 2022, so between that and 4.0 was a massive...six months or so? Why is waiting six months a problem?
Keep in mind they were still updating 3.x that entire time. The 3.x line made it all the way up to 3.5 with significant improvements even as 4.0 was being worked on for those 4 years. Considering it is an open source project with very few people paid to work on it, keeping both going over that time is kind of impressive.
I really hope they can pull a Blender and become productive for small-to-medium games.
It's great to see some "commercially viable" games like Dome Keeper being built upon Godot.
It's great to see some "commercially viable" games like Dome Keeper being built upon Godot.
It's definitely viable for 2D -- I'm 100% sure on this. The biggest factor holding people back is the hesitancy for a professional developer to leave something like Unity. That won't matter to the 1-2 person teams.
As I have no aspirations of working professionally in games, I'm using Godot. If I did have such, I would probably be in Unity or Unreal just for the opportunities. As of right now...today.
As I have no aspirations of working professionally in games, I'm using Godot. If I did have such, I would probably be in Unity or Unreal just for the opportunities. As of right now...today.
> another dark age like from Godot 3 to 4 would be a deal breaker.
Sorry, but there was no "dark age". The 3.x line was being continually updated during the work on 4.0. the last major 3.x release came out only six months or so ago, in August 2022 (3.5).
Sorry, but there was no "dark age". The 3.x line was being continually updated during the work on 4.0. the last major 3.x release came out only six months or so ago, in August 2022 (3.5).
I don't follow Godot too close, but wasn't the big change also from 3.x to 4.x also migration from OpenGL to Vulkan? That's a rewrite of the rendering engine, which is a big part of a game engine, that most likely also affect a lot of other aspects of the engine.
Related (about this release—there are too many Godot threads to list):
What's new in C# for Godot 4.0 - https://news.ycombinator.com/item?id=34944340 - Feb 2023 (105 comments)
Godot 4.0 RC 2 - https://news.ycombinator.com/item?id=34805594 - Feb 2023 (8 comments)
Godot 4 Release Candidate 1 - https://news.ycombinator.com/item?id=34709249 - Feb 2023 (27 comments)
Godot 4.0 beta 16: Initial .NET 7 support - https://news.ycombinator.com/item?id=34547637 - Jan 2023 (33 comments)
Godot 4.0 beta 9 Released - https://news.ycombinator.com/item?id=34052510 - Dec 2022 (15 comments)
Godot Engine Release Management: 4.0 and beyond - https://news.ycombinator.com/item?id=33793281 - Nov 2022 (43 comments)
Movie Maker mode in Godot 4.0 - https://news.ycombinator.com/item?id=33598256 - Nov 2022 (8 comments)
Godot 4 Beta 1 - https://news.ycombinator.com/item?id=32856034 - Sept 2022 (110 comments)
Godot 4.0 will discontinue visual scripting - https://news.ycombinator.com/item?id=32571893 - Aug 2022 (110 comments)
Godot 4.0 development enters feature freeze ahead of the first beta - https://news.ycombinator.com/item?id=32265429 - July 2022 (118 comments)
Fog Volumes arrive in Godot 4.0 - https://news.ycombinator.com/item?id=32003065 - July 2022 (44 comments)
What's new in C# for Godot 4.0 - https://news.ycombinator.com/item?id=34944340 - Feb 2023 (105 comments)
Godot 4.0 RC 2 - https://news.ycombinator.com/item?id=34805594 - Feb 2023 (8 comments)
Godot 4 Release Candidate 1 - https://news.ycombinator.com/item?id=34709249 - Feb 2023 (27 comments)
Godot 4.0 beta 16: Initial .NET 7 support - https://news.ycombinator.com/item?id=34547637 - Jan 2023 (33 comments)
Godot 4.0 beta 9 Released - https://news.ycombinator.com/item?id=34052510 - Dec 2022 (15 comments)
Godot Engine Release Management: 4.0 and beyond - https://news.ycombinator.com/item?id=33793281 - Nov 2022 (43 comments)
Movie Maker mode in Godot 4.0 - https://news.ycombinator.com/item?id=33598256 - Nov 2022 (8 comments)
Godot 4 Beta 1 - https://news.ycombinator.com/item?id=32856034 - Sept 2022 (110 comments)
Godot 4.0 will discontinue visual scripting - https://news.ycombinator.com/item?id=32571893 - Aug 2022 (110 comments)
Godot 4.0 development enters feature freeze ahead of the first beta - https://news.ycombinator.com/item?id=32265429 - July 2022 (118 comments)
Fog Volumes arrive in Godot 4.0 - https://news.ycombinator.com/item?id=32003065 - July 2022 (44 comments)
Been working with Godot for a couple of months now and can highly recommend it. Maybe it's just the mental model that matches mine well, but I have to spend very little time reading things up - in general stuff turns out to work how I think it should, and it's not more complicated than it has to be. Quite different from my experience with Unity.
I'll probably steer clear of 4.0 for now though - for my non-AAA needs 3.x (3.6 will receive LTS if I understood it correctly) is quite sufficient, and it looks like I'd have to do quite a bit of yak shaving to switch.
I'll probably steer clear of 4.0 for now though - for my non-AAA needs 3.x (3.6 will receive LTS if I understood it correctly) is quite sufficient, and it looks like I'd have to do quite a bit of yak shaving to switch.
The release announcement blog post with all the information is at https://godotengine.org/article/godot-4-0-sets-sail/.
It might make more sense to use that link instead.
It might make more sense to use that link instead.
Having looked at the migration guide from 3.x to 4.x, I am rather worried at the large amount of stuff that needs to be changed to port projects from 3.x to 4.x. There's an automated conversion tool for parts of it, but there's so much that it doesn't handle.
My enthusiasm waned quite quickly when I read that. The huge amount of breaking changes means that few projects or tutorials are likely to get updated and adoption of this new version is likely to be much slower as it's like having to build the ecosystem up from scratch.
As I'm about to start my first larger Godot project, I was initially waiting for 4 so I could work in that (and looking forward to it), now I'm going to have to seriously consider staying on 3.x if I want to get a good start.
Definitely not the case that you can just take a 3.x project, load it into 4.0, spend a few minutes fixing some bugs or deprecation warnings and then enjoy new features or performance enhancements.
My enthusiasm waned quite quickly when I read that. The huge amount of breaking changes means that few projects or tutorials are likely to get updated and adoption of this new version is likely to be much slower as it's like having to build the ecosystem up from scratch.
As I'm about to start my first larger Godot project, I was initially waiting for 4 so I could work in that (and looking forward to it), now I'm going to have to seriously consider staying on 3.x if I want to get a good start.
Definitely not the case that you can just take a 3.x project, load it into 4.0, spend a few minutes fixing some bugs or deprecation warnings and then enjoy new features or performance enhancements.
2.x to 3.x was like that too, I basically had to start over.
If you're starting a new project (like I am) I think 4.0 is the only choice. 3.x has awful 3D and even worse presets, GDScript can only be used realistically without the static typing features since they break all the time (for 4.0 they rewrote the whole thing just so they could fix static typing). C# really feels like something that was bolted on even years later.
It's not hard to see why 4.0 is such a breaking upgrade, many of 3.x problems aren't surface level, since those were ironed out long ago.
If you're starting a new project (like I am) I think 4.0 is the only choice. 3.x has awful 3D and even worse presets, GDScript can only be used realistically without the static typing features since they break all the time (for 4.0 they rewrote the whole thing just so they could fix static typing). C# really feels like something that was bolted on even years later.
It's not hard to see why 4.0 is such a breaking upgrade, many of 3.x problems aren't surface level, since those were ironed out long ago.
I really don't understand this mindset. Just start.
> My enthusiasm waned quite quickly
> As I'm about to start
You sure your not just looking for external reasons to justify procrastinating?
> My enthusiasm waned quite quickly
> As I'm about to start
You sure your not just looking for external reasons to justify procrastinating?
Wow, judgemental much? "Just start" is a recipe for disaster in a siatuation like this, and I'd rather not set myself up for failure.
My enthusiasm about this particular version, that I had been looking forward to, waned quickly. I'm about to start the new project after I finish up my previous one, and I'm currently waiting on getting the design document. I'm doing the opposite of procrastinating, I want the project to be done smoothly and in a reasonable timeframe. Having to contend with conflicting information where almost everything I look up will be for 3.x and not applicable to the 4.x series is the antithesis of smoothly.
So it seems now that my choices are to go with Godot 3.x and end up with maintenance trouble in the future and not being able to make use of 4's much improved feature set, go with Godot 4 and have a much rougher development experience, or go with another engine altogether.
My enthusiasm about this particular version, that I had been looking forward to, waned quickly. I'm about to start the new project after I finish up my previous one, and I'm currently waiting on getting the design document. I'm doing the opposite of procrastinating, I want the project to be done smoothly and in a reasonable timeframe. Having to contend with conflicting information where almost everything I look up will be for 3.x and not applicable to the 4.x series is the antithesis of smoothly.
So it seems now that my choices are to go with Godot 3.x and end up with maintenance trouble in the future and not being able to make use of 4's much improved feature set, go with Godot 4 and have a much rougher development experience, or go with another engine altogether.
I've been using Godot 4 exclusively since around Beta 8 and have had little to no trouble adapting. Godot 4 has had documentation for a while now, and finding the "new" version of whatever I needed was always pretty easy. That's only going to get better.
There is also of course the Godot 4 channel in the Godot Discord that is helpful.
There is also of course the Godot 4 channel in the Godot Discord that is helpful.
That at least gives me hope that the ecosystem will adapt quickly. And I noticed GodotSteam for instance delivered a 4.0 compatible release today already: https://github.com/Gramps/GodotSteam/releases
> As I'm about to start my first larger Godot project, I was initially waiting
You were waiting for Godot?
You were waiting for Godot?
Lol, in a sense. At least now he actually arrived.
Seriously though, mostly waiting on getting the design document and was hoping for Godot 4 to be the clear way forward. I've only done smaller projects with 3.x and lots of experimentation and preparation for these larger projects, so it is a bit disappointing to see that all rendered useless by the sheer amount of breaking changes unless I decide to stick with a now outdated engine.
Seriously though, mostly waiting on getting the design document and was hoping for Godot 4 to be the clear way forward. I've only done smaller projects with 3.x and lots of experimentation and preparation for these larger projects, so it is a bit disappointing to see that all rendered useless by the sheer amount of breaking changes unless I decide to stick with a now outdated engine.
Do you actually need to port? It's not like 3.x suddenly stopped working.
It's not like older games are porting to new versions of engines either.
It's not like older games are porting to new versions of engines either.
For my older, smaller projects, nope.
For a few projects I'm involved in that are currently in development, I had anticipated porting because of the bugs in 3.x that we were having to work around which are now hopefully solved, though now I'm reconsidering that and it may be better to stick with 3.x just to get the game out of the door.
For new projects, it's a toss-up. Until a lot more resources (documentation, tutorials, plugins/extensions) make the shift to 4, it might be wiser to start even completely new projects in 3.x. But the improvements and fixes in 4 are enticing, so if the official Godot documentation is sufficient (admittedly, the official docs are quite well written, and usually it's more of a case of finding stuff than it not existing) and there's no need for extensions that don't exist for 4 yet, then doing with 4 might be a the more future-proof choice.
For a few projects I'm involved in that are currently in development, I had anticipated porting because of the bugs in 3.x that we were having to work around which are now hopefully solved, though now I'm reconsidering that and it may be better to stick with 3.x just to get the game out of the door.
For new projects, it's a toss-up. Until a lot more resources (documentation, tutorials, plugins/extensions) make the shift to 4, it might be wiser to start even completely new projects in 3.x. But the improvements and fixes in 4 are enticing, so if the official Godot documentation is sufficient (admittedly, the official docs are quite well written, and usually it's more of a case of finding stuff than it not existing) and there's no need for extensions that don't exist for 4 yet, then doing with 4 might be a the more future-proof choice.
How have people found the learning curve and debugging?
My son did a game with it, but once we started trying custom stuff it wasn’t clear where the code for some things was - some things were in the scene some in the shapes etc.
I.e. it’s crazy easy to start with but gets a lot harder as you go?
For people with programming experience I found it to be reasonably fast to pick up. In some areas it's quite low level but "generally" has a good documentation.
Especially version 4.0 introduced some compatability breaking quality of life changes.
For beginners Godot is not as intuitive as other engines (e.g. Unreal with it's visual blueprints)
Especially version 4.0 introduced some compatability breaking quality of life changes.
For beginners Godot is not as intuitive as other engines (e.g. Unreal with it's visual blueprints)
Well, they phased out visual scripting in 3.x because it was too low-level, but I do hope it will come back in a 4.x with a higher degree of abstraction because for folk with no coding expertise and for simple object scripts, Blueprints are just way easier (and so was Bolt on Unity, which my kids used with great success until I got them to shift to Godot 3.x and learn GDScript).
As someone who's worked in Unreal and Unity, I would have said that Godot is simpler than both. YMMV
That aspect of not being sure how your assets should line up is a general "game engines are complicated" problem, which occurs as soon as you add this kind of flexibility: suddenly there's just a lot more dependency behavior to be aware of as you set up your data and a lot of code bugs become data bugs.
Godot is relatively consistent in what it wants and how it parses a scenegraph, but it's still a little bit quirky: it usually behaves best if you break out any dynamic elements into different scenes so that their instancing is fully encapsulated, and for things that need to change state, add on/off toggles but keep it statically instanced. Attaching stuff after the scene has been instanced tends to bring it out of sync with the state of the collision/physics servers.
Godot is relatively consistent in what it wants and how it parses a scenegraph, but it's still a little bit quirky: it usually behaves best if you break out any dynamic elements into different scenes so that their instancing is fully encapsulated, and for things that need to change state, add on/off toggles but keep it statically instanced. Attaching stuff after the scene has been instanced tends to bring it out of sync with the state of the collision/physics servers.
I have the same experience, it's very easy to get started but gets more complicated and especially buggy the more of the not-widely-used features you begin to use or the larger the project becomes, unfortunately. But many of those issues are constantly being addressed and iterated on, so i'm quite positive about godot's future.
That’s mostly on the way you plan structure your code. But also inherent in programming. Make sure you comment your code and keep certain planning central or near to your files.
Anyone have experience with IK and skeletal animation of rigged 3D models on Godot 4? Last time I checked (back in the 3.x days), it seemed like Godot 3.x was lacking in that area (as opposed to 2D animation) but that they planned to improve 3D animation in Godot 4. I'd be interested to know how viable it now is in Godot 4 compared to other engines.
Skeletal animation was borked and pulled from 4.0 during beta: https://godotengine.org/article/dev-snapshot-godot-4-0-beta-... They're working on it and plan to bring it back in 4.x.
Thanks for the info, very useful (would upvote, but I still don't have enough points for that).
I'm kinda simultaneously sad that it's not yet ready in 4.0 and hopeful about them working on it for some later 4.x version. But in the meantime, that unfortunately means that for anyone wanting to do a game where skeletal 3D animation+IK is required (i.e. most 3D games where you would see humans), Godot is still not a viable option, though hopefully getting there.
The other point that makes me think that Godot (much as I think it's a great project) is probably not the right thing for my requirements is their very opinionated architectural decisions about rendering… which are understandable for their goal of providing a low barrier to entry and reduced learning curve for many common use cases, but make it harder to customize and adapt to other requirements.
specifically: their way of encapsulating all rendering into a separate server with a rather high wall between that and the code of the game developer… is probably not compatible with what I want to do, which requires blending externally pre-rendered background/environment images with animated 3d characters and assets.
So currently, I'm thinking of probably not going with a batteries-included encapsulated game engine like Godot but instead using a render engine (like Filament, Ogre3D Next or The Forge) with a character animation engine like Ozz-Animation.
I'm kinda simultaneously sad that it's not yet ready in 4.0 and hopeful about them working on it for some later 4.x version. But in the meantime, that unfortunately means that for anyone wanting to do a game where skeletal 3D animation+IK is required (i.e. most 3D games where you would see humans), Godot is still not a viable option, though hopefully getting there.
The other point that makes me think that Godot (much as I think it's a great project) is probably not the right thing for my requirements is their very opinionated architectural decisions about rendering… which are understandable for their goal of providing a low barrier to entry and reduced learning curve for many common use cases, but make it harder to customize and adapt to other requirements.
specifically: their way of encapsulating all rendering into a separate server with a rather high wall between that and the code of the game developer… is probably not compatible with what I want to do, which requires blending externally pre-rendered background/environment images with animated 3d characters and assets.
So currently, I'm thinking of probably not going with a batteries-included encapsulated game engine like Godot but instead using a render engine (like Filament, Ogre3D Next or The Forge) with a character animation engine like Ozz-Animation.
Amazing engine that just keeps getting better and better.
Congratulations on the release!
Congratulations on the release!
I've been looking forward to this for so long and when it finally comes I'm on an overnight train in Vietnam (I purposely didn't bring a laptop for the trip). Still, makes mo so happy to see all that hard work payoff, solid job from the team and all contributors
Any recommended tutorials? Preferably text/books over videos
With 4.x JUST getting out books aren't going to be ready for a bit. There are major changes on all levels, from the new renderer to a significant update to their language GDScript to how you do some things in the UI to node type name changes.
If you wanna learn the very basics they have a tutorial on their site for 2d and 3d. Looks like Stable actually now points to the 4.0 version[1] I did the new 2d one and at that point (beta 1 I think?) they still had outdated information but I believe all of it has been fixed.
[1] https://docs.godotengine.org/en/stable/
If you wanna learn the very basics they have a tutorial on their site for 2d and 3d. Looks like Stable actually now points to the 4.0 version[1] I did the new 2d one and at that point (beta 1 I think?) they still had outdated information but I believe all of it has been fixed.
[1] https://docs.godotengine.org/en/stable/
Been using the RC build over Godot 3 and have been pleasantly surprised. There are several quality of life improvements - the biggest one being that you can set default font and just change font sizes without having to create a new theme for reach node - this is probably my most used new feature!!
Wonderful job Godot team, and huge congrats on the 4.0 release
Wonderful job Godot team, and huge congrats on the 4.0 release
Release notes is a 404.
The highlight stream is over an hour away from now: perhaps the release is still happening now?
They should probably merge the PR :) https://github.com/godotengine/godot-website/pull/577
I usually prefer just read the release notes of software updates, but in this case, a video showing and explaining the new features is a great companion https://youtu.be/chXAjMQrcZk
If someone builds a unity to Godot converter, I'd switch in a heartbeat.
That sounds like it would probably take more dev effort just for the converter than for the rest of Godot, given how complicated (and sometimes broken) Unity is.
A hyporthetical question: if you're going to contribute to an open source game engine, which one would it be and why? Godot? Bevy? Others?
Most open source development is the result of people 'scratching their own itch', not randomly selecting a project to 'help'. So if I, hypothetically, was to contribute it probably would be to an engine I was actually using ;)
Godot seems to be furthest in developing a GUI-first engine which is what most people find more approachable since you don't have to learn coding to get a simple game to run. It will profit from network effects due to its growing community.
Bevy is a great engine too, but there are literally hundreds of 'library based' game engines. Also, it requires you to learn Rust first which makes it more of a niche.
Godot seems to be furthest in developing a GUI-first engine which is what most people find more approachable since you don't have to learn coding to get a simple game to run. It will profit from network effects due to its growing community.
Bevy is a great engine too, but there are literally hundreds of 'library based' game engines. Also, it requires you to learn Rust first which makes it more of a niche.
What's the difference between the new "automatic mesh LOD" in Godot and Nanite in Unreal 5?
Godot is using a more traditional graphics pipeline, and sending mesh data to the GPU after having the CPU do initial calculations for LOD. Nanite is designed as a "GPU software renderer" and therefore performs fine-grained LOD calculations "during" its rasterization, within the shader code. That's oversimplifying the exact steps, but it explains the orders-of-magnitude difference between Nanite and traditional approaches since doing more on the GPU means there aren't as many data transfer bottlenecks.
If data transfer bottlenecks are the issue, would using a hybrid CPU/GPU (Intel IGP, Apple Mx) setup not solve the issue?
To the dead comment asking about "mono" builds, they have a .NET runtime so you can use C#
this is awesome...i've started dabbling in game dev and was messing around with unreal 5. i will have to give this a shot
I'm betting we will see StableDiffusion models that can create 3D graphics assets, and basically everyone can create a game (no artists or programmers required).
Everyone can already create a game. There are tons of free and paid assets, along with mature no-code game development tools.
And I've heard from folks at established studios that they've been playing around with generative pipelines for asset creation.
But from my perspective, for the vast majority of games, programming and asset creation isn't what determines a successful or enjoyable game.
It's a mixture of core game mechanics, style, juice, developer follow-through, marketing, random chance, and whether or not it's "fun".
And I've heard from folks at established studios that they've been playing around with generative pipelines for asset creation.
But from my perspective, for the vast majority of games, programming and asset creation isn't what determines a successful or enjoyable game.
It's a mixture of core game mechanics, style, juice, developer follow-through, marketing, random chance, and whether or not it's "fun".
Maybe for some more abstract games. But we'll need a while longer before we see something capable of making a really good 3D human character model with accurate proportions and details. Realistic guns are another thing that's hard to get the details right on. But yeah, hopefully we get something like that soon. I personally enjoy programming games, but despise the assets side of it, and have no friends that could assist in that department.
it's seriously demotivating as a programmer with gamedev dreams to be incapable of shaping something visually to an approximation of your vision. I'd say it's my biggest hurdle every time I try to jump back into gamedev.
being able to draft a rigged and animated model with something like SD would remove a significant motivational roadblock for me. I don't care if it looks like unpublishable shit, as long as it looks like unpublishable shit that roughly approximates my vision. I can then continue on with my game design, with a self-motivating feedback loop, and find an artist once I can better communicate and sell them on the vision. it'd be phenomenal for proof of concepts and gamejams to see if your idea works. especially when you have no friends in the field.
being able to draft a rigged and animated model with something like SD would remove a significant motivational roadblock for me. I don't care if it looks like unpublishable shit, as long as it looks like unpublishable shit that roughly approximates my vision. I can then continue on with my game design, with a self-motivating feedback loop, and find an artist once I can better communicate and sell them on the vision. it'd be phenomenal for proof of concepts and gamejams to see if your idea works. especially when you have no friends in the field.
Something like Makehuman could be a good starting point for humanoid characters.
Unpopular Opinion: Godot should make JavaScript/Typescript its scripting languages.
GDScript is absolutely delightful, just give it a go.
People are always skeptical about it because they fear it is another thing to learn but it is very tailor made for Godot and for that reason you will pick it up in no time.
If you have worked with any scripting language, you will feel right at home. JS/TS would be a worse experience because that language is not designed for Godot.
People are always skeptical about it because they fear it is another thing to learn but it is very tailor made for Godot and for that reason you will pick it up in no time.
If you have worked with any scripting language, you will feel right at home. JS/TS would be a worse experience because that language is not designed for Godot.
Yup. I'm not a Python fan, and I have used C# in gamedev before, so I wasn't super thrilled about GDScript, but it is genuinely really good. And being custom made for Godot pays off in ways that I didn't think about fully when I was using c# in Unity or c++ for Unreal.
I tried it and eventually gave up and ported everything I was working on to C#. Not enough static typing and similar for me in GDScript, I like structure.
I know 4.0 is a bit better for that, though I'm not sure how much better.
I know 4.0 is a bit better for that, though I'm not sure how much better.
GDScript has decent gradual typing support these days.
I tried the static typing support in 3.x and it just wasn't nearly good enough. I really need being able to do shit like Array<Dictionary<Thing, OtherThing>>. And I want the static typing enforced automatically onto me, with compilation errors when I screw it up, not something I have to remember to label. Even with C#, there are still blank spots for this unfortunately, where the Godot standard library just passes you an untyped Array.
I know 4.0 has improvements here for GDScript, which is good to hear, but I'm quite comfortable in C#, coming from a background as a Java/Android dev.
I know 4.0 has improvements here for GDScript, which is good to hear, but I'm quite comfortable in C#, coming from a background as a Java/Android dev.
What features does GDScript have that makes it fit Godot? I've been skeptical for the reason you mentioned but your comment might have convinced me that it's actually worth it.
GDScript is purpose-made for the task of being aware of how the engine wants to bind data. That is, its type system knows what the different components are, the events they can send, types of assets, etc. That makes it much smoother in terms of IDE support than using a general-purpose language - it helps you along with stuff like cueing an animation or audio event.
It's not really a language meant for lots of computation, but that isn't actually what most gameplay code needs: games are generally doing something based on a lookup table, finite state machine, or collisions. It only becomes a deep issue if you've got a lot of custom simulation going on.
It's not really a language meant for lots of computation, but that isn't actually what most gameplay code needs: games are generally doing something based on a lookup table, finite state machine, or collisions. It only becomes a deep issue if you've got a lot of custom simulation going on.
I was in the camp formerly of "just use Lua/C#/JS/etc." for Godot as I didn't want them to reinvent the wheel. I've changed my mind on the matter after using it though. Or, through having a custom implementation, they've integrated it very tightly with Godot's node/refcounting memory model. Much in the same way UE's Blueprint execution feels similar to C++ logic, manipulating nodes and sending signals in GDScript ends up having a similar flow to something done lower-level in the engine.
I think it makes a tighter experience, and less maintenance work is done for bindings and transferring data to/from a separate heap/runtime for scripting.
I think it makes a tighter experience, and less maintenance work is done for bindings and transferring data to/from a separate heap/runtime for scripting.
https://github.com/Geequlim/ECMAScript
Also once people start using GDExtension it should be easy to import languages to 4.x without recompiling.
Also once people start using GDExtension it should be easy to import languages to 4.x without recompiling.
Unity tried it, it happened that very few people used it and support was dropped.
The only advantage would be the jit performance of js engines.
If that is a factor you should be using C# or gdnative C++.
If that is a factor you should be using C# or gdnative C++.
js is a bad language
please no
please no
But Godot is like a breath of fresh air. Lightweight, beautiful abstractions, with a lot of horsepower to back it up. It crashes as much as the competitors if not more, but man is it fun!
Even the Godot subreddit feels like a breath of fresh air compared to /r/gamedev. People are just having fun.