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.
> 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.
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.
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.
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.
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.
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.
But I do understand it. I just am not sure it's a good strategy for longterm 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)
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.
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
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.
- 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
> 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...)
Also TY for the tip about debugger output limit — no idea why the default is so low!
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.
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...
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.
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.
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.
It's unfortunate that Epic ever let Unity persuade people that it's better suited to anything or anyone at all.
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.
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.
Then ten or twenty years pass and it becomes the thing to replace.
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.