The fact that it's open source is also big, because there are often bugs in the Unity engine that I can't fix since I don't have source access.
A lot of devs also like jumping on new technology because it feels good to learn new things.
Oh and then because it's open source, you can improve the engine and it gives you the "Ikea effect" where you like something more because you helped to create it.
And very bad ones, at that; which will persist for years and several major versions.
For instance: let's say you have a game that supports user generated content via loading asset bundles. This being the lowest barrier to entry for games to leverage the unity editor for UGC, it's quite common.
Well, now and always, and known and reported since at least 5.2, any asset bundle that references a class not found in the compiled game client will crash the client on load.
The only work around is to write your own asset bundle inspector and pre-analyse on load.
I don't know what the story is with Godot (beyond the breaking changes between 2.0 and 3.0 that was mentioned in the linked blog post) but if that is a lot better then I can imagine that some game devs might be more interested in Godot for that reason too.
Or is it that you can't fully trust them, and you'll need to do that by hand anyway, because you might be one of the exceptional cases?
But those were 2-3 year game cycles. Maintaining a project would be less fun. But it'd be like choosing to do a rails or react upgrade.
Do they have a culture of incompatibilities so they can simplify their development and keep the best features and discard the worst?
They make older versions of the engine available in their management app, and projects are linked to a specific version unless you explicitly upgrade.
Unreal also has more features available than both engines out of the box, as far as I am aware. I don't want to sound like an advert, but the shading and Blueprint systems in UE4 are extremely intuitive and easy to work with, and the C++ is definitely managable. I've never used Godot, but the last time I compared Unity to UE4 it felt extremely clunky. Lastly, prototyping stuff in UE4 is fun, once you get used to it and develop your own workflow.
Recently I wanted to write a workout game for the Oculus Quest for my own use and I am really impressed how well VR development works in Godot. I have never made a godot game before and never made a VR game before and it is really progressing nicely. An added benefit is that one of the devs has already added experimental hand tracking support. So even if the big game studios do not support it yet godot games can already support it, which is a real benefit for a workout game where you also have to do pushups (unsing the controller is a bit unwielding there)
For those who are interested what a first game looks in godot
Here's a meme which is actually very illuminating. Someone in the comments mentions checklist-driven development, which seems about right. Unity doesn't feel like a complete product right now, it's full of systems which are either incomplete and badly documented or outdated and buggy.
Or if it's just an inherent complexity in the actual job.
Or if it's an issue with management and product managers that can't decide which users to service, so they do the easy, but wrong thing and try to service them all.
It also works well with Git, which as a coder first, game creator second, I appreciate. I don't think this is the case with Unity, but I am not sure.
The choice to move the projects i've been working on to godot though was after setting up some sprite animations I'd set up previously manually using Sfml. What took me almost two weeks originally took me 30 minutes to redo and improve upon using godot.
Also, sort of insiginificant but, I really enjoy the way you can enter equations into any input box that accepts a number and it'll solve it for you automatically. The only other software I've used that does this is alphacam and it's such a handy feature I really miss it when it's not there.
Godot just frees your mind from that side of things, and so in that case, it's a 10x experience if that long-range commercial element taxes your mind.
First up the added Unity maturity isn't always as helpful as you'd expect. There were many areas that felt very incomplete, requiring us to write our own solutions, or find third party ones often at cost. An example was I believe we encountered strong limitations with the built-in AI Navigation system that made it pretty useless to us. There were third-party navigation solutions, but this sort of summarizes part of the problem with Unity: there is a lot of third party addons, but a lot of them felt like things that just overcome the often confusing limitations of the original product that I already paid money for. Lots of game engines can suffer from being particularly suited for certain genres and not others, even supposedly generic ones like Unity. So if you were making something that was kinda weird and would require a lot of bespoke special work, using Unity didn't really get you any wins.
Godot plays better with VCS systems using a nice human-readable scene format called tscn, that is swapped for a binary format on project export. I find this format is usually readable enough to review scene file changes in PRs, with the usual exception being a scene that was primarily imported geometry data. To get around that we'd import geometry data into bespoke geometry scenes, and they'd be nested by reference into the scenes that you'd like to be able to review diffs on. Additionally this scene format merges nicely in git, and has allowed me to work on team projects and have people edit scene files in their own branches without fear. Unity (and Unreal) at least at the time, had nothing approaching this. There was a Unity text-scene format, but it was a merge nightmare regularly. In practice we ended up using a VCS product (I believe perforce) that allows you to exclusively check out a scene file. Which at least stops people stepping on each others toes too much but hinders productivity.
Unity as of last I heard still does not have an out-of-the-box solution for nested prefabs, with many opting to use a commercial add-on to supplement the short-coming. This feels like it has been the single most complained about Unity pain point, so it was very confusing that nothing really seemed to be happening. Godot uses an approach that I find much more elegant. There's no distinction between a scene file and a prefab, which allows for some nice refactoring where something becomes a prefab after not initially being conceived as one. You simply have the ability to make a scene graph node that is a instanced reference to an external scene, and this nests nicely with no limit that I've ever encountered.
The Unity Editor was a bit of a dog. It regularly crashed and experienced general slowness. I find Godot much more stable snappy, and don't experience anywhere near the amount of tool frustration. But I have heard that it has been quite a bit more stable in the past year or so.
I encountered a lot more weird rigid design in Unity. IIRC if you wanted to runtime load content such as textures or models, they had to be inside of one specific subdirectory of the project. In general Unity seemed to force its philosophy of project organization onto you, while Godot will happily go along with whatever approach you want.
I still think there are reasons to use Unity. It is more mature, companies generally want access to an existing talent pool, and let's not forget that often it is worth sticking to the tool you know. But I definitely have found that I enjoy working in Godot more than I did Unity, and as a fairly experienced programmer I don't mind not having as big of a community to rely on for assistance. I don't work as a game programmer anymore, but I continue to do hobby projects near exclusively in Godot.
I'll have to check out Godot's note system, and it seems like when everything can be represented with the same thing, you have the ability to refactor your code as it resizes and scales.
The canonical story is described by Clay Christensen in the Innovator's Dilemma, where the new toy X is inferior to the mature Y along most dimensions. However, something changed in the world, and people are starting to value a dimension where the new toy X is 10x better than the mature Y along a single dimension. And that allows the new toy X to gain a foothold. I'm super curious as to how Godot managed it, even if it has been a long time in the making.
Of course, not all toys end up replacing the incumbent. But by dismissing everything as a toy, you're shutting off a line of inquiry to see how this process happens. If you're on HN, it's a good chance you're a programmer and by definition a creator. And if you're at all ever wanting to bring something new into the world, it'd behoove you to understand how new creations are accepted.
Usually happens when something is 10x better at something new that people care about that the incumbent is blind to or is structurally incapable of addressing. I'm just wondering what it is in this specific case.
Ease of use? Beginner friendly? Open source so you don't have to pay? The node system makes it easier to do X?