[pipeline_peak]

> It’s no secret that Unity is painful to use: it’s slow to open, and it often pauses to re-scan the entire project while you’re trying to work

Is this actually true? I always figured Unity's selling point was being lighter and easier to use than unreal.

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

[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.

[sfteus]

Anecdotally, there's something about Godot's structure that just "clicks" better for me. It's odd because they seem pretty similar on the surface (nested scene graph, nodes with scripts that have hooks, etc), so it's hard to determine what exactly makes it easier to understand.

The only two concrete things I can point to are better documentation (IMO), and the first-class signal/observer support in Godot. I'm not sure if that exists in Unity or not, but it's a really intuitive way to handle entity interaction, and I think that makes it way more easy for beginners to get started.

[Uehreka]

It is outrageously painful. Half of the craft of working in Unity is knowing which kinds of operations will trigger a 15 minute re-import and basically scheduling your day so that you have other things you can do while that’s happening. It doesn’t happen every day or every time you open a project, but sometimes you’ll be looking at your master branch in git, and then you go to check out a branch where something big has changed, and then you alt-tab back to Unity and… time to go make a fresh pot of coffee.

[Entinel]

Anyone who used Unity 2.x in 08 would tell you Godot is far beyond where Unity was in 2008 in terms of features and stability.

[BoorishBears]

As someone who did I'd say it's a silly comparison. Godot has a decade of advancements in technology on Unity 2.x, things are generally "nicer" than when Unity started

[scottymac]

Especially for 2D features.

[psyc]

I switched to Unreal after using Unity for many years, both at my day jobs and as an indie. If I had known what it is actually like to work in Unreal, rather than how the grapevine vaguely typecasts it, I would have switched a long time ago, or more likely never used Unity in the first place. Unreal is a delight.

It's unfortunate that Epic ever let Unity persuade people that it's better suited to anything or anyone at all.

[okwubodu]

Personally, I think they were a bit generous there.

I’m not sure what it is but it’s gotten significantly worse over the past few years and I’ve stopped recommending it to new game devs.

[overgard]

It's very true; I remember one game I was working on, when you pulled down the code and new assets it'd take a long time to rebuild the "Library" (which is not something you can check in). And sometimes, if your version of the project was acting wonky and everyone else was fine, the solution was to delete the Library and rebuild it from scratch. If you were doing it from scratch, it could take hours. They've made some improvements but it's still a mess.

The editor itself always seems very buggy. If you have the "Console" open (which you will if you're coding), it's pretty much guaranteed you're going to see a lot of random errors that have nothing to do with even your code. A lot of them don't even make sense or could be ignored. Like you'll get weird asset import errors if you upgrade versions, but a lot of times they're just red herrings and not important. There's also a lot of QOL stuff that's very frustrating, like arrays being annoying to edit (I'm not sure if they've fixed this yet or not). It's also easy to accidentally brick your editor on your own, with debugger shenanigans or loops that don't end.

Also, if you're trying to build a an editor extension, omg was that a nightmare. Just getting things like Undo/Redo and object serialization working correctly are difficult and in some cases impossible. And frankly, you need extensions for a lot of things to actually be useful, like until recently the builtin terrain editor was basically useless, and you have things like Odin because the builtin inspector is a nightmare.

There's a lot to like about Unity, but there's also a huge amount of pain points with it.

[disintegore]

This seems to be a cyclical thing. Every now and then a new solution shows up that is built on new development and UX practices, abandons some baggage that is no longer relevant to most users, makes assumptions in its design that are better suited to the era, etc etc.

Then ten or twenty years pass and it becomes the thing to replace.

[KronisLV]

> Is this actually true?

I'd say that yes, at least in the last 5 or so years.

I decided to make a scene which would contain a single copy of every single model that I'd like to use in a project of mine, for checking the textures, how lighting works, the scale of everything etc.

By the time I got to around 200 different objects (no high poly ones, by the way), it took like a minute to just open that scene.