Godot is insignificant but growing, that's the best way to put it. Godot has a lot of pain points, lack of knowledge and best practices which most Unity devs already figured out about Unity. Especially indie 3D is still kind of a pain in Godot.
Mostly waiting for Godot 4 and hoping a lot of those pains will be solved, both 2D and 3D.
I recently just picked up Godot after years of tinkering with unity as a hobbyist. On the whole I like Godot and will probably continue to use it instead of unity
I am not a pro, but it feels like there are a few rough edges in Godot that will trip up someone used to unity. E.g. the script editor UI is weird (it has reasonable actual code editing, but the layout and how you select files is weird and really unintuitive IMO - no tabs, shows you all scripts and not just the ones in the scene you are editing etc), you cannot easily "view"/"find" a node in the scene by double-clicking, you can easily dig into an instanced scene to edit it but there is no intuitive way of going "back up" so it is easy to get lost in the embedded scenes-within-scenes, you can't move the panes around in the editor how you'd like, you cannot pause the game and "view" the scene in the editor (making debug for collisions etc difficult).
It is taking some getting used-to. I hope v4 sorts some of these niggles out.
>you cannot pause the game and "view" the scene in the editor (making debug for collisions etc difficult).
Do you mean actually pausing the game (play using the editor, then pause) and then checking the remote tree? You can check the remote tree while the game is paused. I have noticed breakpoints (in C#) tend to freeze updates on the remote tree though. Additionally, you can show collision shapes during gameplay by toggling it.
>E.g. the script editor UI is weird (it has reasonable actual code editing, but the layout and how you select files is weird and really unintuitive IMO)
Big reason I use VS Code to edit. Unfortunately shaders are still best written in-engine and the shader window has a really, really annoying tendency of removing itself once selecting a different node without selecting a different shader. Funny since animation and audio tabs don't show the same behavior (the animation tab stays locked until you select another animation tree, audio behaves similarly).
>so it is easy to get lost in the embedded scenes-within-scenes
My biggest problem with scenes, I can get used to scenes-within-scenes by keeping things on a code level, but nodes tend to be fairly expensive and making things like components isn't the most intuitive in Godot coming from Unity, Unreal or anything similar. If the community was a bit more mature and bigger, someone would've probably figured out best practices to avoid these things rather it looking like a flaw in the system itself.
The remote tree is useful, but a fully visual representation in the editor would be best. It seems that I can force the game to reflect what I set in the editor , but not make the editor visually show what is happening in the game at that specific moment.
E.g. imagine I am creating a platformer (for a totally hypothetical example) with a moving platform. There is a bug in the game where the player sometimes drops through the moving platform. In unity I can pause the game when the bug happens and then in the editor I can visually see all of the colliders and so on and quickly work out what is happening (e.g. perhaps the collider for the platform is too short or something and so the player misses it). In Godot it seems there is no way of doing this. Yes I can use the inspector on the remote tree, but this is not easy to visualise the colliders and their overlapping. Add in 3D and it gets even harder. Perhaps I am just missing some button somewhere? Debugging collision issues in Godot is proving to be a real pain in the backside without this feature.
I guess that for Godot it just shells out a new process to run the game and the game is not running in the editor as it appears to be in unity, and that makes it hard to visualise the state in the editor.
The main benefit of Godot 2D is that it is strictly 2D, 2D and 3D are split. If you do things without needing 2D, it will edge out over Unity (UI tends to be better, pains with window sizing etc. tend to be better than Unity). The moment you want any 3D feature, you either do a shoddy hackjob retroactively fitting it into your 2D game, or you rewrite a lot of things to get 3D. Unity's main benefit is everything essentially being a 3D game, and 2D games being hamfisted in a 3D scene, making it so adding the slightest 3D feature is far easier. Simple example, if you wanted to spin sprites a la Paper Mario, you can't just do that in Godot 2D, but you can easily do it in Unity '2D'.
On top, Godot's general lack of community and features still means going beyond a certain level of polish, even in 2D, becomes a bit more annoying. Support for 3rd party plug-ins are limited*. VFX examples are extremely limited. Particles are still fairly barebones in features compared to Unity (Godot 4 is bringing updates to this), and Unity has the added benefit of having a far larger community. In general you'll find similar issues you'd find in Unity, with less history or support to get you out of a bind.
Godot does particularly well in fairly simple games and styles, but the moment you go beyond that scope it's basically a toss-up whether you're better or worse off using Unity right now. That should be changing in the future as more people adopt Godot, but it isn't as cut-and-dry as "2D for Godot is better". Anyone saying that may as well vouch for GameMaker, Ren'py, RPGMaker or something else based on their requirements.
*: Especially art. There are tons of art workflows being popularized now to make art production easier for artists, many coming from Japan. Their support in Unity is already fairly minimal, in Godot it is practically non-existent. I imagine having good plugins for say, Spine 2D, Live2D etc. would help bring over the mobile crowd in particular and cross over to the PC/console markets as indies start trying more than just pixel art.
Loads of mobile games use 2D models and meshes to speed up development time. They allow animation without having to draw frame by frame, and still have elaborate animation. The same as in 3D. Rendering to frame by frame makes a tradeoff between choppier animations or exploding the space required. Spine 2D is an example of a product where these animations can be made in full.
Unity is big in the mobile market, which in turn has more addons and plugins to support these workflows. Godot can support it without rendering the animation to frame-by-frame, but it doesn't have a universally known plugin yet. Most artists don't look forward to doing the exact same thing in Godot with worse tooling.
That’s really interesting - thanks for taking the time to come back to this.
When I first clicked over to Spine 2D I assumed it was skeletons for sprites. But it actually looks like skeletons for 3D meshes, which are then exported for use in 2D applications.
This sort of workflow implies to me - a layman - that the 3D modelling part is less onerous than creating a whole bunch of sprite art. Which is surprising.
Mostly waiting for Godot 4 and hoping a lot of those pains will be solved, both 2D and 3D.