Let's go back to Unity

02/04/2020

Despite the common wisdom you'll hear as a programmer along the lines of "don't use a hammer for screws", it's still good to find the best hammer when you have nails. In that vein, I departed from my use of Unity for the last year in favor of Godot. And I'm going back to Unity.

Nodes vs. Scenes/GameObjects/Components

At first, the simplicity of Godot's Node system was appealing. In short, everything is a node in a big tree. A scene is a node, a "game object" is a node, and a "component" is a node. The advantage is in its simplicity and flexibility. However, after using it for a year, I have come to realize this flexibility is not necessary, and oftentimes, it's confusing. If you can think of 10 ways of doing the same thing, which way is best? It's hard to tell, and it inevitably leads to me re-working everything 5 times.

In Unity, with the more systematically structured approach, there are fewer ways to do the same thing, and I think that's a good thing! If you're looking at 2 options, it's easier to pick one and commit to it quicker than if you have 10 options.

GDScript vs. C

Godot has a really nice and simple scripting language built-in called GDScript. GDScript makes it really easy to do simple things, but it gives me conniptions when I read about how if you want performance, you should use GDNative and use C++. Maybe I should've just tried GDNative more. In Unity, you use C# for everything. For me, it's even easier than GDScript, and it's more performant. I do have more experience in C#, so that might be why, but the fact that working in C# means you are working on a more widely applicable skill-set is another advantage of using C# over GDScript.

Extending the editor

Both Godot and Unity allow extending the editor in tons of ways. It's just a lot easier in Unity. In Godot, you need to make a plugin which forces a certain folder structure (side note: the plugins directory is called "addons". That bugs me more than it should.). It also comes with a lot of boilerplate you need to make it work. In Unity, for simple stuff, you can use Gizmos which are extremely easy and fast to implement. For more complicated stuff, you can make a custom editor which has a similar amount of boilerplate to a Godot plugin. It even forces a directory structure. Now that I think about it, Godot is just missing that simple Gizmos system. It's also easier to customize the Inspector in Unity.

The Inspector

Optimizing the UX of the inspector is always worth doing as much as possible to make it quick and fun to create content and tweak values. In Godot, there is a set list of exports you can do to expose a variable to the inspector. They are great at getting you a bare-minimum, "technically working" inspector panel for your script. Unity has all of those built-in as well. In addition, most Unity devs use extensions like Naughty Attributes or Odin which allow you to do almost anything you can possibly imagine extremely easily, without needing to make a CustomEditor.

Another reason I like Unity's inspector better is because a GameObject can have multiple components attached, you can edit multiple components at once in the inspector. In Godot, the inspector will inspect one node, which can only have one script attached, so you need to either make one script do everything, or split it up into multiple child nodes, but then you can't inspect all of those at once. Additionally, there are always some options on each node that you probably don't care about when you are looking at a "component node", so it's a little cluttered. Like, I'm not going to "pause" my player movement component.

Features

Godot has an impressive feature set for what it is. However, Unity's feature set is simply much bigger. Some big ones that Unity has that are not in Godot:

  • Occlusion culling. Provides a big performance improvement for free. Only applies to 3d games.
  • LOD system. Unity has a nice, almost automatic LOD system and Godot has none. You can do it manually, but you need to code it.
  • Terrain. There are various terrain packages but Unity's is (recently) really good.

Little things

  • Automatic re-importing. In Unity, I can just save my .blend file and Unity will let me drag that into the scene view, and it'll automatically re-import if I make a change. In Godot, you need to export it to .obj or something similar. On top of that, you need to click the "re-import" button if you make any changes. Those couple extra clicks really add up over the course of a big project.
  • Package Manager. Unity's package manager is amazing. I can disable a bunch of cruft I don't want! And it makes it easy to try out new features and update existing ones.
  • When I switched to Godot, the ability to hide objects in the editor was not there in Unity, but now, with the new design (2019.3) it is!
  • Same thing with selection locking. You couldn't before, but now you can! And it works the same way in 2D and 3D. In Godot, the 2D selection locking is really nice, but it's only pretty nice in 3D for some reason.
  • Scripting API. I just think it's easier to figure out how to get complex things working in Unity than in Godot. The API and the documentation feel like they are designed to be easy to make an engine in Godot, and easy to make a game in Unity. For example, in Unity, you can just say transform.forward to get a normalized forward vector for a game object. In Godot, you can say transform.basis.z but if it's scaled, it doesn't work, so it's like ok, you shouldn't scale that object. but then if the designer scales the object, the game logic breaks and it's a mess. There are a lot of little things like that where it's just a little more complicated to work with in Godot.
  • Relying on Node names in Godot. To get a child node, you get it by it's name that you type in the editor. That is terrible! It basically means that you cannot refactor your node trees, unless you want to scour your code for strings that reference names. In Unity, the corollary is getting a reference to a component, which you do with GetComponent<TYPE>(). So if you refactor the class name of the component, the compiler will tell you 100% of the spots you need to change it, and that's if you don't use your IDE's automatic class name refactoring, which you should. You can export a NodePath which exposes a drag-and-drop style slot in the inspector which is nice, but that adds cruft to the inspector, so it's still not as good as how it works in Unity.

2D games

Godot is still better when it comes to 2D games. There is a dedicated 2D window, which is infinitely better than Unity's approach, which is to show all 2D stuff inside the 3D window, scaled way up so that 1 meter = 1 pixel. That is super jank. In Godot, 1 pixel = 1 pixel. So it's just much easier to work with. There are a lot of really nice options for the built-in 2D nodes in Godot, too. For example, the 2d camera node has amazingly flexible options that make it super easy to make a camera, often without any scripting. It just feels like Godot was designed for 2D and Unity was designed for 3D.

Licensing and Pricing

You just can't beat Godot here. It's free and MIT Licensed. Unity suckers people into forking over some cash by requiring payment to get the dark theme for the editor. Unity probably makes millions of dollars per month just from devs who want the dark theme. Maybe I should hop on that bandwagon.... I could give up Netflix for Unity's dark theme....

Recent Posts

  1. Let's go to Godot
  2. Website Checklist
  3. How Matt Makes a Steak

Find a Post