Godot is also great for 3D, and increasingly so. We're already making great VR games with it, and it's only going to get better with Godot 4.0 which will support Vulkan (to be released this summer).

I've switched from Unity ~7 months ago and never looked back.

Curious - is your team using GDScript, C#, or C++ primarily? It seems like GDScript is still the happy path for compatibility, but I have mixed feelings about it as a language (though I've written enough Python to be relatively productive in it in my little Godot experiments).

We're using GDScript and like it a lot. I find that I'm much faster than with C# and haven't had any performance issues yet. The good thing is that you can mix and match languages as you like. So you could write 99% in GDScript and there's something where you really need performance just write it in C++, Rust, Python or any other language you want.

It looks like that they're re-working GDScript for 4.0, so that'll get a lot better, too.

I've used Unity and Unreal Engine 4 for a while I don't think i'll want to switch from UE4 for 3D based things i'm pretty excited for Godot 4.0 and all the new nifty features I've been hearing about.

Does it make sense to hold off diving into Godot until 4.0 (for 2D-based things) or will there not be too much to "relearn"?

I'm not a contributor to Godot, but my understanding is that Godot 3.x projects will be mostly compatible with Godot 4.0, and where conversion is needed they will provide tools.

Therefore, I assume that the fundamentals of Godot will stay the same and you should be fine diving in with 3.0 already :-)

I'm a programmer, who feels most comfortable writing code, so that was the route I took, and that route ended up being inaccessible. I've also heard that you can't really do everything for an entire game in just blueprints.

Unity's C# scripts on the other hand - despite all of the engine's problems - are incredibly straightforward to write, set up tooling for, build, plug into a project, and you can use them to control everything from game logic to the editor to the rendering pipeline. This is Unity's greatest strength, IMO.

>I've also heard that you can't really do everything for an entire game in just blueprints.

I wouldn't do networking in blueprints. But for your core gameplay ? It can absolutely do anything you want.

You can do anything you want if you are into managing a huge spaghetti node system. Sometimes its more efficient and especially flexible to be able to write code, and easier to maintain, update and edit.

Same would happen with code if best practices aren't taken into account.

Blueprints provides the tooling to package stuff into re-usable components, exactly to avoid spaghetti code, just like in most graphical programming languages.

Has anyone ported to a console? The wording here is a bit confusing, I thought they meant you have to pay a 3rd party to port your whole game (from scratch?) but maybe it means they'll have to compile a special version of the engine for you instead with the devkit or something?

It's the latter. A third party provides you with the stuff you need to export to consoles, e.g. export template(s) and such that for legal reasons can't be included in the normal version of Godot. Here's a recent thread about having a Godot game built for Switch: https://twitter.com/monolithofminds/status/12599133551769272...