[johnfn]

The quoted statement is 100% accurate. Unity is very slow. When I worked on Unity with a larger project, I'd often have to wait 10+ seconds for Unity to rescan the entire project every time I switched windows from my IDE to Unity, or every time I ran the project. In similar project sizes, Godot was always lightning fast.

> Godot looks like Unity from 2008, it's easy to boast efficiency when you have a limited product.

Unity does have more features - like more obscure 3D features - but that has nothing to do with how Unity deems it necessary to rescan the project tree all the time. Also, when I used Unity, I never used these extra features, so even if this were true, how come all users have to pay the price for features that only a few of us will use?

Honestly, core Godot is very full-featured, and in my experience the central abstractions are much better thought out than those in Unity. I feel a lot of the FUD around "Unity has more features than Godot" comes from people that like seeing a long list of features, not from people who actually need those features.

[aroman]

As someone who uses Unity professionally to make a 2D game, here are some key areas I find godot lacking vs unity:

- Scalable text support a la TextMeshPro (sdf-based rendering)

- the in-editor console is horrible. it frequently tells me "output overflow, print less text!". wtf? also, it doesn't let me click on a line to jump to the code

- the built-in tile editor is very painful in my experience. the UI is clunky and it's lacking important features I depend on in Unity, like tile rules.

- the built-in text editor is _very_ basic, and support for external editors is limited vs Unity (and hampered by lack of mature tooling for gdscript vs C#)

- gdscript's heavy reliance on "magic" strings and lack of type-safety throughout

- unity's UI system sucks, but it's still more capable than Godot's especially for things

[johnfn]

> Scalable text support a la TextMeshPro (sdf-based rendering)

Agreed, this could be better.

> the in-editor console is horrible. it frequently tells me "output overflow, print less text!". wtf? also, it doesn't let me click on a line to jump to the code

Agreed.

> the built-in tile editor is very painful in my experience.

Agreed, but I hear it's better in 4.0

> the built-in text editor is _very_ basic

Actually, I disagree here. Fuzzy find, quick open, search in files, and autocomplete all work and are blazing fast. It is missing some things like a decent Vim mode, I'll admit. However, I tried both using vscode and the godot text editor, and I found that you saved so much time by not having to jump between IDE and Godot that it actually made up for a few of the more minor deficiencies.

> gdscript's heavy reliance on "magic" strings and lack of type-safety throughout

Agreed, but this improves in 4.0.

> unity's UI system sucks, but it's still more capable than Godot's especially for things

I honestly find Godot's workable enough. With Unity I would get into stupid issues because it was scaled 1000x larger than my game (who in their right mind thought this was a good idea?!?). Also, I remember Unity having 3 different modes for their UI, all of which were confusing and counter intuitive. Godot's UI is simple enough to hack.

[aroman]

Thanks for the detailed reply. I am super excited about 4.0, I eagerly read the alpha update blog posts when they appear in my RSS reader :D

I am probably most excited about the gdscript 2.0 features. As someone who currently maintains a fairly large codebase as a solo developer, I cannot imagine writing that in gdscript. I rely heavily on C#'s type safety and more "industrial strength" tooling — a strong standard library, huge ecosystem of tested open source C# modules (e.g. NuGet), great external IDE support (I use Rider), and a lot of language features like generics and interfaces.

Btw on the UI stuff... I definitely remember being very confused about that when I first got started. Now, I actually do see the benefits of having 3 separate modes — it "does the hard work for you" when you want to put UI in screen space vs world space. But yeah Unity's UI system isn't good... and, like seemingly everything else in Unity's, it's apparently deprecated yet it's proclaimed replacement (UI Toolkit) isn't production-ready. Sigh...

[jolexxa]

I believe I can address the first two points for you:

> Scalable text support a la TextMeshPro (sdf-based rendering)

Someone in our Discord recently found a way to scale their project UI correctly according to screen DPI, not sure if that solves your problem or not. Their project is also open source: https://github.com/derkork/openscad-graph-editor

> - the in-editor console is horrible. it frequently tells me "output overflow, print less text!". wtf?

That can be solved by upping the debugger output limit in your project. (https://github.com/chickensoft-games/go_dot_test/blob/1fb342...)

[aroman]

Thanks for the reply! Can you share any more context on the scalable UI solution? Feel free to tag me in the thread on Discord, my handle is avi#9876.

Also TY for the tip about debugger output limit — no idea why the default is so low!

[corrral]

> - gdscript's heavy reliance on "magic" strings and lack of type-safety throughout

Yikes. I was like "eh, I could get over that for a good dev framework" until I hit this one. Dealing with that kind of thing is like driving a car with hexagonal wheels.

[johnfn]

It's actually not as bad as it sounds. There are generally 2 cases where these come up.

1. As a hack for not having functions as first class objects in GDScript - you'd refer to the function by string name. This definitely felt very hacky, but it's been resolved in 4.0, and now we have first-class functions!

2. For some things that other languages would handle as enums. This is also a problem, but it's not nearly as bad as you'd think, because it's generally fairly readable - stuff roughly like `is_key_down("key_left")` - and because Godot's autocomplete is good enough to suggest only the appropriate strings.

[bluefirebrand]

I love working with Godot but I can't help but feel like GDScript is a mistake.

I want better language support and community when working on a project. I want to use nice VSCode plugins that auto format my code (and give type hints... Untyped languages hurt me so much these days)

I can't wait for better C# integration for Godot. It's ok now but I'd love it to be rock solid.

[kevingadd]

Custom scripting language seems to be a common error - early on Unity emphasized a pseudo-custom scripting language (Boo) over C# and had to slowly extract it out of the product, documentation etc.

It makes sense as a risk management strategy early on in engine development, though, since integrating something like C# can be difficult and they may have been afraid that they would regret building around C# later on.

[danbolt]

Normally I'd agree with you, especially as someone that's embedded a scripting language into AAA games, but I think GDScript is the exception to the rule. Or, it's very tightly integrated with the engine's way of handling memory and it feels refreshing compared to a VM that has some bindings to native functions.

[krapp]

On the one hand, Undertale, Spelunky, Hotline Miami and other popular games have been made in GameMaker and GML is much, much worse than GDScript. At the end of the day, the player isn't going to care.

On the other hand, GDScript is not that great a language. No one would use it as a general purpose scripting language outside of Godot, it's like a more awkward wannabe Python without many of Python's useful features, and outright frustrating features like "pass" and funcref and not actually being able to type-hint signals.

To each their own, but I've never enjoyed using GDScript, which is unfortunate because the framework itself is amazing.

[bluefirebrand]

I do wonder if integrating C# is more effort than building and maintaining a language though.

But I do understand it. I just am not sure it's a good strategy for longterm growth.

[bluescrn]

Pushing people towards a non-standard scripting language is definitely not a strategy for long-term growth.

It needs a widely-known language with good performance and high quality debugging support (you can use the Visual Studio debugger with Unity C# or UE C++, for example)

[TillE]

> the central abstractions are much better thought out

Totally agree. Godot is the first engine I've ever used where I don't feel like I'm fighting with it the whole time to make it do what I want.

Godot is pretty clearly a solid choice for anyone making 2D games, and will eventually be a fantastic choice once we get a stable Godot 4.0 with .NET 6 and other nice features.

[thrillgore]

The only real FUD that has any basis is 1) The lack of good 3D support and 2) DOTS style architecture. These are things the community is addressing now for future releases.

The 3D support will be significantly overhauled in 4.x https://www.youtube.com/watch?v=DNJXkcQxXEg and additional enhancements will reduce the need for DOTS/ECS for many. There's also Godex https://github.com/GodotECS/godex that adds ECS to the engine.

[eatsyourtacos]

Agreed- my limited Unity usage has been horrible just because of how bloated and massive it seems every time I try to give it a go.

Whereas Godot opens up in literally 1 second and boom I am there.

And for 2D projects, there is very little "lacking" compared to Unity. It's way more clear what is going on.

[jpeter]

I recently tried out unity with this tutorial https://www.youtube.com/watch?v=_Pm16a18zy8 and imported a sprite map. It took like 10 minutes to load. No idea why it takes so long

[jayd16]

Are you comparing apples to apples with similar sized projects? I'd be curious to hear about larger Godot projects.

[johnfn]

Yep. Similar numbers of assets, similar sizes of assets, etc. Things that would cause Unity to keel over and die were virtually instantaneous in Godot. I had a project with something like 10k game objects in Godot with no major issues.

Actually, there was one issue where saving was taking like 5 seconds in Godot instead of being instantaneous. I reported it and it was solved in the next point version. https://github.com/godotengine/godot/pull/49570

[Dracophoenix]

Would you still recommend Unity for 3D iOS game development, or would it be better to move on to Godot?

[johnfn]

Hmm, it depends how much you're going to be using the 3D features that Unity provides. If you're going down the big list of Unity 3D features and you're thinking you need a whole bunch of them, then it's possible that Unity would be a time save in the long run. But honestly I like Godot so much that it would take a lot to tip the scales.

I would personally not use Unity at all because I find the developer experience so frustrating. I'd rather spend an extra couple of days enjoyably hacking something together rather than spending less time in more frustrating ways (like waiting for compiles). But I feel I'm more sensitive to these things than most people.