Godot 4.0 Stable
github.com
github.com
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.
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.
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.
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 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.
https://dotnet.microsoft.com/en-us/apps/aspnet/web-apps/blaz...
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!
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.
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.
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).
https://github.com/derkork/openscad-graph-editor
which I've been using quite successfully.
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 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!
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.
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.
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.
It's great to see some "commercially viable" games like Dome Keeper being built upon Godot.
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.
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.
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).
???
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?
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).
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)
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.
It might make more sense to use that link instead.
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
> As I'm about to start
You sure your not just looking for external reasons to justify procrastinating?
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.
There is also of course the Godot 4 channel in the Godot Discord that is helpful.
You were waiting for Godot?
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.
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.
It's not like older games are porting to new versions of engines either.
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.
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)
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'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.
Congratulations on the release!
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.
Wonderful job Godot team, and huge congrats on the 4.0 release
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.
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".
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.
Also once people start using GDExtension it should be easy to import languages to 4.x without recompiling.
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.
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.
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 know 4.0 is a bit better for that, though I'm not sure how much better.
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.
IMO, their scripting language is pretty accessible to anyone with a bit of experience with programming and has nice syntactic sugar to integrate with the engine.
If that is a factor you should be using C# or gdnative C++.
please no