Congratulations to the Godot team for reaching this milestone. As someone who leads a team working on a game project using an old, custom engine we have a quiet desire to switch to a different engine. There is a temptation to consider investing in Godot over one of the other tried and true engines due to its leanness and open source nature but still feels like a gamble for a 3D project. I wish there were more people talking about their experience with Godot beyond a hobby level.
> As someone who leads a team working on a game project using an old, custom engine we have a quiet desire to switch to a different engine.
Curious about the reasoning behind this? Has your engine had good technical leadership, or is it tacked together based on need? (If I were starting a studio today, I'd strongly prefer build an engine for our teams from the ground up, but that's certainly counter to the intuition of most, and likely inadvisable.)
As a builder on the team of one of the largest deployed Godot projects, it is certainly effective and I'm incredibly glad exists—I am very happy to use it, but it's not without its pain points. I rate it significantly better than Unity, a fair bit worse than Unreal (but ), open source is a major benefit (we have our own modifications), and there are some peculiar maintainer/code/project decisions...but we can deal with it. All that said, we'll probably never be able to upgrade to Godot 4, but Godot 4 looks damn good.
Ultimately we probably won’t switch but our game runs on a 20 year old engine that has had no updates in all that time. Directx9, no pixel shaders, poor performance, custom formats, windows only and no interoperability with modern formats. We don’t have any graphics or engine specialists on the team so upgrades on that front are challenging. However all of these can be overcome the biggest enticement is the editor platform. Our current tooling system is dire and making good tooling is such a time sink. Being able to build tools within another platform is inticing while also getting other advantages such as cross platform deploy, asset imports, UI framework, etc. is tempting. The grass is always greener!
I feel the same way. Godot has made amazing progress ... both in the engine and in the community. But it's still "very early" in terms of adoption for big commercial teams. Having said that, depending on the genre of game your team is making, it could very well be a good choice. Perhaps not for a AAA 3D title ... but for other genres where having cutting edge visuals isn't the most relevant part of the content.
I for one am hoping there's a Rust-based engine on the horizon in the next 5 years (Bevy perhaps?)
> As someone who leads a team working on a game project using an old, custom engine we have a quiet desire to switch to a different engine
I'd be careful with this and make sure that if you do try a switch, you'd keep the existing tech alive. I've worked on a bunch of game projects in different companies and in pretty much every single one of them, both custom and external engines, people wanted to use something else.
One of my favorite jokes was that the biggest feature UE brings is that you get to blame Tim Sweeney when something goes wrong instead of the engine CTO :-P.
As much as I'm looking forward to 4, has GDExtension been stabilized / documented yet? I know there's the existing C++ example [1], but I really, really don't want to jump through a scons & C++ project simply to call a single native function in a DLL. You can do such a thing with GDNative, and I presume that it is possible in GDExtension as well, though it isn't obvious how to do so. This strikes me as a huge barrier to adoption, since GDNative is one of the big things that will be incompatible with 4.
There's an ongoing discussion at [1, 2] which highlights an important difference between GDNative and GDExtension in terms of what the developers expect them to be used for. A lot of people were using GDNative as a way of writing game logic in other programming languages (particularly I've seen this with Rust), but GDExtension seems to be designed to allow people to write editor plugins (e.g. things like a voxel node type, or a custom GUI tool). Each pligin currently seems to provide a custom Node in its own right, not the ability to hook into existing nodes.
This is why at the moment, you cannot live-reload a compiled GDExtension library, as the assumption is that it's a product that being provided to the user of the editor, not something which the game developer is directly creating.
I think there might be some mechanisms/hooks to allow this to work as wanted, but it has to work quite differently.
Faolan-Rad and I (fire) are working in that area https://github.com/godotengine/godot/pull/72883 "LibGodot is a system to allows Godot to be compiled as a library and connected into it using GDExtensions by giving a function pointer to the entry point of a GDExtension implementation"
Yes, I was in the first category of people, where I am using GDNative to ultimately call a single function written in Go, not due to speed, but simply in order to leverage a huge amount of code I had already written in that language. Judging by the GDExtension headers, I can probably pull off something similar if I forgo all of the C++ bindings that I don't need. However, I am hesitant to dedicate any time to doing so at the moment.
Don't get me wrong, GDExtension seems awesome, but it's also true that it doesn't seem geared towards the case that I was using GDNative for.
I've seen on their Discord where before they release the next version they call upon the community to help document all the new features before release if I remember correctly. Maybe a good issue to bring up before it gets looked over.
Now I can finally go rebase all of my plugins against the new GDScript now that it's stabilized a bit. Seems there were a number of small but breaking changes between the beta releases. Overall the betas have been fairly pleasant to use.
Hoping that the Godot team will consider producing double precision binaries now that we're closer to release. It's a small pain to have to build from source and divine the right flags etc.
I started a very simple simulator in Godot and I don't want to reimplement everything in GDscript or use a library. So I put it on hold for Godot 4 because of the navigation improvements.
If I were making a 2d only game and didn't care about consoles, 10. Godot > unity | unreal. 3d games, Unreal is still the king imo. Maybe Godot 4 will change this a bit. But I really do not like Unity so I might be biased.
FYI Godot's shortcomings in consoles is an issue with the console manufacturers not the engine.
I'd say it depends, though I suppose the same could be said for Blender vs Cinema4D. Overall, if I had to put a number on it I'd say a 7, however that cuts both ways, I could say that Godot is 70% as good as Unity or that Unity is 70% as good as Godot.
I migrated from Unity to Godot a few years ago because its open source, but now even if Unity went the same way I doubt I'd go back. The only things I really miss about Unity are the solid features for 3D (but Godot is getting there) and the choice for using a generic, performance orientated language over a built-in, ease-of-use orientated language (which I don't see changing anytime soon, though mono support is improving). That last one is especially important to me, but I'd be more likely to move onto another open source engine/framework than back to Unity.
Just going to point out that Unity games last year generated over several billions in revenue (largely on the strength of Genshin Impact), and at this point in its lifecycle Unity games were already generating several hundred million in revenue across multiple platforms.
Godot games collectively have generated a few million in its entire lifespan, and most of that was the Sonic Colors re-release.
Godot is great if you want an open-source game engine for a hobby project. It's not so great if you want a commercial game engine for a game you intend to actually release (the one major commercially released game using Godot was a buggy mess). So in that respect, it's like Gimp vs Photoshop (or Affinity), it's a 5: you choose Godot for ideological reasons but not for technological or business reasons.
If you want 2D games, go with GameMaker. If you want 3D games, go with Unity for mobile or Unreal for console, or either for PC.
Really impressed that they're supporting dotnet six and are in active testing of their support of dotnet seven. IIRC, Unity is currently supporting dotnet three.
Just started a game project with some friends in Godot 3 in December. Already see some things (Await comes to mind) that would've been great had we opted for 4. Still, it's hard to sign on to an unsettled technology for our first ever game. Who knows, maybe we'll consider upgrading if it looks manageable.
Really exiting, I love Godot and have been using the beta releases. I just really hope they fixed the bug where you cannot rename nodes if you running KDE Plasma Wayland (first in beta 15 and I believe exits through beta 17).
