Hacker News new | ask | show | jobs
by aroman 1442 days ago
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

3 comments

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

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

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

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!

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

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.