The Ultimate Question
When choosing to become a game developer, there are a lot of choices. Am I going to do 2D or 3D? Am I going to use assets or learn to model or draw my own? Am I going to try and sell a commercial game, or is this just going to be a hobby? However, the biggest question of all for nearly every game developer getting started today is this:
What game engine am I going to use?
Now, this isn't universal. Some developers choose to forgo an engine and build their own. Some know exactly which engine they want to use given the answers to the other questions above. However, most game devs getting started just want to build their dream game, and they have no idea which technology to get started with.
Personally, I noodled on this choice for months before finally coming to a decision. I carefully read the getting started documentation of each engine, I watched YouTube tutorials, and most importantly, I tried them all. I built an open world level in Unreal, I built a cool little mobile game in Godot 4, and I quickly prototyped an awesome first-person controller and demo in Unity. I tried to build to the strengths of each engine, but also do some of the same things in each one (build an environment, control a character, move a camera). Finally, after a few months of experimentation, I had my answer.
Unity is my Engine
...and all experienced game developers collectively rolled their eyes at me. Yes, yes, it's another Unity user talking about why they picked the most common game engine in use today. Hang with me though. I really do wish that someone had just told me straight out of the gate to pick Unity out of "the big three" (Unity, Unreal, Godot), and I'm going to put together the arguments that I wish I could have found more easily than when I started my search. That being said, each engine has their strengths so I'm going to put the usual disclaimer here that pissed me off too: It's really up to you and your goals.
However, if your goals are like mine, and line up with like 97% of all game devs everywhere, then hang with me and see why Unity is the right choice.
Code comes First
I've been a web developer for nearly a decade. In that time, I've grown confident in my ability to write good, clean code. It's not always perfect the first time around, but I can usually refactor and squeeze out a little bit more optimization and performance. I'm also, admittedly, terrible at node based editing. I don't use it in Blender (which really holds me back) and I don't want to use it in my game engine.
Now, don't get me wrong, I respect the hell out of people who can use visual scripting. Like I said, I suck at it, so props to you. But since my it is an area of improvement for me, I'd be doubling the amount of learning I'd have to do if I needed to use it, and that's essentially the case with Unreal today.
"BUT C++" the fellow nerds shout. Yeah, I get it. You can use C++ as opposed to Blueprints. However, if you read the Unreal docs, and look up Unreal tutorials, and search for Unreal courses, you're going to find Blueprints first and foremost. C++ sucks for those who want to learn how to make games but haven't coded before, so Blueprints rein supreme. And beginner friendliness isn't the only reason. There isn't garbage collection in C++. "BUT WHAT ABOUT THE BUILT IN UNREAL GARBAGE COLLECTION?" they angrily spew. What about it? You have to use a builtin macro to denote anything you want collected by the GC. That's neat, but I don't care to do it.
Then you have Godot and GDScript. GDScript is awesome. I LOVE it. Purpose built with games in mind, the syntax of a love child of JS and Python. I really like it. But it isn't as optimal as C# or C++, and I think that if I were going to make a large production game, I'd decide to use the transpiler that Godot provides for something like Rust. Overall, Godot and GDScript are great, and Godot 4 doesn't even have Visual Scripting, but it's not the perfect choice for me.
Enter Unity. It has both Visual Scripting and Code based logic as options, and it uses C#. I have built in type safety without having to add it like GDScript (it's optional there), it has a garbage collector that works, and the tooling is amazing. Intellisense in Visual Studio is practically an AI code buddy at this point, as it's completing my thoughts like 75% of the time. I haven't written C# in years, and while not as easy to learn as GDScript, it's leagues easier to use than C++. This is the biggest reason I chose Unity, and I love the coding experience.
The Asset Store
I love messing around in Blender. I actually sell models for 3D printing. Does that mean that I want to model every asset a video game would require, then texture them all, then hope that I can get them into Unity in a way that they don't break? No. Does it mean I want to rig and animate every single character in the game I'm working on? Nope. Does it mean that I am going to fire up Blender and build rich, beautiful environments for my players to explore? Nope.
For 90% of these things, I'm going to use prebuilt assets. I've been a huge fan of Synty Studios' low poly packs, but beyond that, I've already downloaded several free assets from the Unity asset store to experiment with. The store is so easy and seamless with the editor, that I barely have to do anything at all to add some serious flair to any scene that I'm working on.
By comparison, there's the Epic Games store that has Unreal Engine assets. It's not great. It's well known that the UI needs a major overhaul, along with the experience of importing assets into a project once you've acquired them. The only saving grace for the Unreal Engine asset store is the amount of free assets they give away every month. From asset kits to entire scenes, they have given away a lot of good stuff.
Finally, Godot falls short by the largest margin in this category in that it doesn't have a paid asset store. It does have a community marketplace where you can pick up free tools and packages, but the offerings are slim in comparison to other engines due to the fact that you can't charge. I'd love to see a paid asset store in Godot, but it goes against their FOSS (Free and Open Source Software) methodology, so I doubt it.
The Capabilities
This category was the nail in the coffin for Godot 4 for me. As much as I wanted to use it for a 3D game, the physics and 3D capabilities is still a long way from being on par with Unity's, and a galaxy away from Unreal. Unity, while not as powerful as Unreal for high fidelity, high poly, production quality 3D technology, can be used to make really good looking 3D scenes. The physics make sense, emulating the real world quite closely, and are easy to use.
Common packages like Cinemachine and Yarnspinner make things like cameras and dialogue easy to deal with, and the animator being a state machine out of the box abstracts one of the hardest concepts for new game devs to grasp. And don't even get me started on the Game Object and Components system. While I'm excited to give DOTS a try, the idea of game objects just clicks for an object oriented programmer. I love the node system in Godot, but it's much more functional programming esque, if that makes sense.
I have hope that Godot 4 will continue to push updates and eventually support more features like Unity has, but it's going to take a lot of time. That's part of the reason why this post has "in 2023" in the title. As is always the case with software, the states of these engines at the time of this writing are snapshots in time, and anything is liable to change.
The Tutorial Ecosystem
I'll end with this last consideration. If you want to learn how to do ANYTHING (and I mean anything) in Unity, a tutorial exists for it. There are thousands of results on YouTube for specific pieces of functionality in Unity. You want to write a first person controller? 5 minutes of your time and you can have basic movement and camera controls up and running. You want Titanfall parkour (yes.)? They have that too. You want to phase through walls, teleport, throw a lightning bolt, or triple in size if you power up? Those all exist.
Unreal has plenty of tutorials as well, but this harkens back to the first problem I had with Unreal. Every tutorial seems to be in Blueprints. The C++ educational stuff is all locked behind long, paid courses, and it's not easy to find a tutorial for anything. As for Godot, there are some awesome, dedicated Godot creators making content that I love to watch. People like Lukky, StayAtHomeDev, and GDQuest come to mind. Again, this is an area where I'm excited to see Godot grow, but it's just not ready yet.
Unity May Not Be Your Engine
You may read this and still be confused. You may love Godot or Unreal, but want to make sure you made the right choice. I still haven't produced a commercial game yet, so you may be reading this and thinking "why should I listen to this guy anyways?" Or maybe you already know an engine other that Unity and want to know if you're missing out on anything. I may not have a lot of game dev experience (yet), but I can tell you what I tell web developers who are getting whiplash trying to pick a frontend framework.
Give them all a try and decide for yourself. You don't have to build a giant project. Make something small, and then replicate it in everything. That way you know what you're leaving on the table when going with a certain tech. There is no one size fits all, I just think Unity gets the closest for me. If that changes, I'll update this article or write a new one, but I think it's safe to say I'll continue making games in Unity.