With the major controversy of Unity throwing game devs under the bus, a lot of people have been looking into moving to Godot. I'm writing this post from the perspective of a Unity developer that moved to Godot 4 earlier this year. While I'm not a wildly successful dev or anything, I'll talk about my experience and what you should expect if you make the switch.

Why I switched

In my final Unity days I was getting increasingly upset over how bloated the engine is, how there were often 5 different ways to do the same thing, how overly-reliant I had to be with libraries to make obvious things work, how slow the development experience is in a lower-end device (I have a 7th gen i5 with an old GTX 1050), and many other complaints you've definitely heard or experienced regarding Unity...

I was following Godot development for a while and anticipating version 4.0's release, which finally came in March 1st this year. My initial impressions matched my expectations, Godot was such a joy to use compared to Unity! Some highlights for me were:

• It's light: Godot weighs in under 100mb in size, it launches very quickly and creating a project takes a matter of seconds. The editor is snappy and runs wonderfully.

• GDScript is great: While you can use C# (not recommended unless you know what you're doing; I'll elaborate later), it mainly uses its own scripting language called GDScript. It's really fun to use and has batteries included. Being integrated into the engine itself provides many benefits, such as better integration with its systems (like signals), not having to manage imports (everything you need is right there), and making life easier for common tasks (for example any function can be a coroutine without explicitly saying it is, you can always await (thing))

• It's Open Source: No royalties, no tricks, engine code you can modify, no CEO to call game developers "****ing idiots". Enough said.

• Light Projects: Godot's project files are very tiny in size. An empty Godot project is only around 3kb in size (practically empty) as opposed to Unity farting out 300-400mb of Shaderlab files (i.e. garbage that fills your disk). This also means Godot works perfectly with Git out of the box, and it even adds the .gitignore for you!

• It's simple: The engine is very easy and fun to use. There's usually only one easily defined way to do something. There is only one input system. One way to make UI elements. One spot for all your project settings. It's a breath of fresh air compared to how Unity turned into a Frankenstein amalgamation of features held together with duct tape.

There's more to gush about why I like developing with Godot, but you're not here for that. Let's actually talk about what you should know coming in from Unity.

Why you maybe SHOULDN'T switch to Godot

Honestly, as much as I love Godot, it's not all sunshine and rainbows. Godot has many pain points and major issues that are still unresolved. While Unity does crash every now and then, I hesitate to say Godot is more stable than that, so I wanted to set some expectations. There are quite a few bugs that you may come across but things are rapidly improving. Some major issues are:

• The web export has big issues. Godot 4's web exports do not run on MacOS browsers, and they require special headers for the game to run: CrossOriginIsolation and SharedArrayBuffer. Most websites do not support this so you likely won't be able to profit off web games because of it.

• There is no official way to export Godot games to consoles (yet). W4 Games is an entity created by Godot leaders specifically to remedy this, but there isn't an ETA to when this might come. Your games will have to stay on PC/mobile for the time being.

• Godot's ecosystem is not mature yet. Expect support, tutorials, assets, extensions to be way more scarce than Unity. You'll have to reference the (very well-made) official docs more than Youtube or forums. The lack of of a proper asset store can also cause some whiplash coming in from Unity where you can find everything in the Unity Asset Store.

• There's an official blog post talking about what Godot is currently missing to be viable for AAA games. The lack of asset streaming makes open world games a no-go, and some important things like low level rendering access and large-scale version control support are still not here yet.

• It's somewhat unstable. Honestly, you will likely come across some annoyances in your journey. For example, RigidBodies regularly get stuck between tiles. I had to make a tool to pre-bake tilemap collisions as a band-aid solution. Some issues can't be solved as easily, and you sometimes have to just accept that the thing you're doing won't work properly and you should look for alternatives.

Of course, Godot 4 was only released half a year ago and the future is looking very bright. Still, if any of this sounds like a deal breaker than maybe it would be wise to wait before starting any serious large-scale projects. If you're a hobbyist or beginner, I totally recommend you to just jump into Godot as most of these issues won't affect you!

Making the jump: What to expect?

If you decided to proceed anyways, welcome to Godot! You'll like it here.

I think most people will be pleasantly surprised how easy the switch from Unity to Godot is. Most of the skills and concepts are transferable, and the editor itself is fairly similar. The only big differences I would say are GDScript itself, signals, and the way nodes and scenes work.

Graphically, Godot looks very serviceable, although it doesn't look as good as Unreal or Unity out of the box. Godot 4 can look great with some effort, and remember, the reason you're not seeing many examples for it is because this major rework of the engine is only 6 months old, and the community mostly consists of hobbyists.

Since Godot is so light and small, there's no reason why you can't download it right now and test the waters. Download the engine and follow the official tutorial for your first game. It should take you 15-20 minutes or so and will give you a good first impression of what to expect.

If you'd prefer a more in-depth crash course, I recommend Chris' Tutorials video on making a 2D platformer. It's an excellent short tutorial that jumps straight into making a game.

After that, feel free to start browsing the docs and making things. If you're coming from Unity, you should be able to manage easily as long as you know what you're looking for. The official Discord server has many help channels and tons of people willing to help if you ever get stuck or need advice.

Tips & Tricks for Veterans

While you may transition without many issues, here are some tips and things I wish people had told me earlier when I was switching:

1. Use GDScript instead of C#. I know your knee-jerk reaction is to use the same language that you've used all this time, but C# users are second-class citizens in many aspects in Godot. Many features such as web exports don't work with C# projects, and C# often has bugs specific to it while lacking tutorials/documentation. GDScript is very easy to pick up and I promise you, it will be more convenient for you in the long run. This is of course just a recommendation, and it's up to you if you still want to go with C#. Many people use C# regardless due to its execution speed and external libraries, just be aware of its limitations and expect some issues when using it for Godot.

2. This isn't Unity! Get out of the mindset that it's a 1:1 replacement, many things require a different point of view. The Autoload system allows you to fearlessly make Singletons, you should use it. Stop calling functions through references all the time, use signals often to make your code much cleaner!

3. "Groups" in Godot are just tags, except each node can be part of multiple groups! Popular functions you may be looking for are get_tree().get_nodes_in_group("group_name") and get_tree().get_first_node_in_group("group_name").

4. Referencing nodes by name in the scene tree is a very cheap operation in Godot compared to Unity. You don't need to cache your variables if you're planning to rarely use them. Feel free to use get_parent() and get_children() as well.

5. You don't need object pooling for most use cases. Instantiating scenes in Godot is quite cheap, so if you have a total of 50 player projectiles at a time for example you likely won't need to pool them. Still, if you're making a bullet hell with thousands of projectiles you likely want to implement object pooling as there is still some performance benefit.

6. GDScript calls C++ functions under the hood, so despite being a scripting language it's actually quite fast. It also uses reference counting rather than a garbage collector, which is very neat and part of the reason why object pools are unnecessary!

7. You may have noticed that Godot doesn't let you interact with the scene in the editor when it's running, which is a bummer. However, you can still access and interact with the tree by clicking on the Remote tab while the game is running, and you can move the camera around with the Project Camera Override (which is a blue camera icon above your scene).

8. Godot's 3D physics were re-made from the ground up for Godot 4. Unfortunately that means it's very unstable and has major issues, if you're making a 3D game that relies on physics you should use the Godot Jolt extension. It's a drop-in replacement that's so much better, to the point where the Godot devs are considering adding it officially.

Outro

While I definitely do recommend moving to Godot I still wanted to set some expectations. Many people are looking into the engine expecting to see "Unity but FOSS", but it's most certainly not Unity. Whether that's a good thing or a bad thing depends on you.

You should be weary if you're planning to use Godot to create large-scale games, while people make fun of Unity for a ton of reasons, it is admittedly tried and tested. Creating large-scale AA/AAA games with Godot 4 is uncharted territory, so nobody can really know what to expect there. For everyone else, I hope this post was useful.