I think the original commenter just really likes "plug and play" solutions with a lot of hand holding which is what Unity is excellent at. The problems come down the line.

Godot is objectively a way way better tool

> Godot is objectively a way way better tool

If you like things like Godot, Godot is the type of thing you will like.

Seriously though, Godot works way better for me using C# than it does with GDScript and the OOP structure means I can refer to classes by their identity.

That doesn't make any sense. Unity may have a pedigree of being for beginners, but in recent years they can barely keep current documentation on their new systems. This smells like a comment from someone who has never used it.

I haven't used it in the past 3 or so years, but I used to use it quite extensively before that.

It's definitely not a "way way better tool" and no serious game developer would say that. Everyone agrees that Godot has a lot of catching up to do but we're still using it because we believe in the foundation and what it will eventually become.

I'm a serious game developer, been in the industry for decades.

I would say that. Godot is a way way better tool.

There, I've falsified your claim.

But more seriously, it's a faster dev experience, it's more ergonomic, it's not cluttered with half baked "new" ways of doing things that don't do everything the old ways do. There's no reason to pick up Unity unless you are being paid to, IMO.

Or any of these

> Unity's advantage over Godot is it's 3D renderer, built in physX, il2cpp backend for C#, profiler, general runtime performance and console support.

And correct me if I'm wrong, but Godot doesn't have hot code reloading where you don't have to restart your game.

Godot has a good 3D renderer. It has a built in physics system and an off the shelf upgrade to Jolt (which was used in horizon forbidden west). There's absolutely a profiler (https://docs.godotengine.org/en/stable/tutorials/scripting/d...).

Hot reloading is supported.

Console support is some work. Possible, but work.

I'm a Godot contributor.

The 3d renderer is okay, but I'm hesitant to call it good. It's not as good as Unity nor Unreal, imo.

The internal profiler really sucks.

Everything is possible if "some work". Porting to PlayStation 5 is probably a lot of work.

I'm a Godot fan boy, but we gotta be honest about its flaws.

If your targeting 3D on console, definitely go with Unity or Unreal imo.

It does have hot reloading at some level. I use GDSCript for a lot of stuff and it hot reloads. And you can use live++ with it to have true top level hot reloading. We implemented a hacky live reloading for native code in shared libraries which works as well.

Unity is a bit of a mess but to compare apples to apples when Unity has more features seems not quite fair.

Are signals significantly better than Unity events or is it more that the API uses them heavily?

Honestly, why doesn't Unity retool SendMessage() and public API callbacks to be an exposed Unity event? Unlike merging prefabs and scenes, that's not even a breaking change.

GDScript sucks big time, it's not even close to C#. They should drop that Python like language and go full in C# integration.

The core developers are too enamored with GDScript, but that's fine, C# and C++ (GDExtension) support is excellent. There are only a handful of API functions which are hampered by their need to support GDScript, so it's something you can basically just ignore.

You don't even have to use Nodes much, though they're great for lots of stuff. For real performance, you can drop all the way down to their thin wrapper over Vulkan and do whatever you want.

GDScript makes simple things simple and complicated things complicated. It's pretty good for the simple parts of your game. You can still use C# for its complicated parts as they integrate well.

What "sucks" about it? Since they added type checking it's been perfectly fine, besides the notable omission of nullable types (which is... a strange omission, to be sure).

No tuples. No structs. No real debugger. Extremely limited profiling tools. Autoformatting breaks code more often than not. No interfaces. Extremely weak async story. No refactoring tools, external IDE features like jump to definition. Built in editor is slow and buggy. No destructuring assignment, no enumerate for loops, no looping over key and value together from a dict.

GDScript is, in my opinion, unsuitable for anything more than a couple hundred lines at most.

I agree with this. I suspect it's part of a more general Godot philosophy that involves full in-editor workflows with highly detailed scenes, many nodes, and with small scripts attached to all of them.

Your comments are accurate, but they aren't the whole story.

> unsuitable for anything more than a couple hundred lines at most.

I work profesionally in ~5 code bases with ~10,000 lines of GDScript each. I think GDScript is great for UI widgets. I dont think you can say it has a 'line number' limit. It has a 'complexity' limit.

If your writing a ton of tiny little classes that do one thing (like play a sound when a button is pressed), then GDScript is probably the best language for that. Certainly c++ is not the best, and C# is perhaps worse as well. Note: GDScript doesnt need to be compiled _at all_. In unity, its common to have an annoying 'hang' every time you alt-tab from vscode back to unity, as the c# is compiled. In Godot, I can write a new UI widget directly in the editor, with no compilation hang, with hot reloading. It's simply a smoother experience for writing the mountain of basic plumbing that you write when making a commercial game. It's not all complex algorithms here, it's just a crapload of boring ass code. And GDScript is great for that.

Most of the code in games is tiny little things that manage sequences of animations. There is seriously so much small code to make a UI look and feel nice. Writing this code in GDScript is way faster and ergonomic than any other language I've used.

I agree, GDScript has many flaws, but from where I'm sitting (small studio, been in the industry for 10 years), GDScript is a massive boost for my productivity.

For complex stuff, I like to figure out the algoirithm in GDScript then rewrite it in C++ if it needs it. Works great. Again, massive increase in productivity.

I love everything about Godot so much, except for its UI system

It is just so confusing to me and took me over a day to get a simple menu aligned how I wanted

it might just be me not understanding how it works though

Godot’s UI system is easier when you realize that Control-derived nodes are even more granular than even HTML elements. They’re more like Tailwind classes.

Yes, your UI will be a tree of Control nodes 20 levels deep, and that’s fine.

Your root UI node will probably be an HBoxContainer, or VBoxContainer, each of which simply arranges their children horizontally or vertically, respectively. Between those two nodes you can create 90% of UIs you’d want to.

I recommend trying Zenject in Unity! It provides a pretty good dependency injection framework, but more importantly in reply to your comment it has a very easy to use signal bus implementation!

Now I have not tried Godot so I don't know how the two compare, but for where I work Zenject was basically the a-ha moment that made it possible to develop Unity apps/games that don't devolve into a huge unmaintanable mess.

I thought everyone was abandoning unity after their fiasco

A lot of people made a lot of noise about it and it hasn’t been long enough to tell for sure, but there is no real competition to Unity in many situations without a lot more work falling on your dev team.

Fully agree, in Godot a Scene and a Node are the same thing which makes it much simpler conceptually. Also, having a true text based scene format makes merging commits easier than merging unity changes.