The Unity-developer’s survival guide to Godot 4.0
Godot 4.0 stable is finally out! I’ve been a fan of the Godot project for years now, and while I always thought Godot 3.x was a neat alternative to Unity, Godot 4 is a genuine competitor.
If you - like me - come from a Unity background, Godot might feel familiar yet kind of off at the same time to you. There are enough subtle differences between the two engines that can trip you up when creating your first project in Godot. In this article, I want to go over the most important differences, so you can hit the ground running on your Godot 4.0 journey. Let’s get started:
Scenes
While they may look like they do the same thing on a surface level, scenes in Godot really don’t work like Unity-scenes at all. Godot’s Scenes function more like beefed-up Prefabs than fully standalone levels. You are expected to keep scenes fairly small and add/remove scenes dynamically at runtime via instantiation.
Scenes can have nested scenes, so a single scene should usually contain a logical unit of your game like an enemy, a HUD, a collectible and so on. Managing your Scene Tree during runtime is one of the main challanges when building a game in Godot and it’s something the engine expects you to keep in mind at all times during development, different to the mostly fire-and-forget nature of Unity’s scene system.
Nodes
Nodes in Godot are single-purpose. You can’t add more than one script to any given node, which will extend the behaviour of that node. In general, behaviour is moch more closely tied to the node instances themselves than in Unity, where components handle the functionality and you can add an arbitrary number of them to your GameObjects. Do you want to handle web requests? There’s a HTTPRequest node for that. Do you want to add a collider to a mesh? Add a CollisionShape node as a child of your Collider node, and place it below your MeshInstance node.
This single-purpose approach might seem overly compartmentalized at first, and it’s a big reason why scenes tend to be so much smaller in scope in Godot than in Unity. Godot forces you to be concious of how you build scenes, and what nodes each scene comprises of. The benefit you gain is that endless GetComponent calls like in Unity become obsolete this way, especially when you’re working in GDScript, which supports duck typing.
Scripting
Speaking of, while it may be tempting to jump into Godot programming exclusively with C# (especially now with full .NET 6 support), Godot’s homegrown scripting language GDScript has gotten a huge upgrade from 3.x to 4.0, becoming so much more comfortable to work with in the process. Its modern feature set, concise python-like syntax and dynamic type system can help you get to results a lot faster.
Because Godot is way stricter about the structure of your scenes than Unity is, we can leverage that strictness while programming. For instance, it is common in Godot-scripts to call children directly via NodePath, instead of searching for components or setting up refenrences manually through serialized editor-variables (aka. export-variables). Both of these options work too in Godot, you just need them way less than you would in Unity.
Events
Fans of event-driven software development will be pleased to know that events (called Signals in Godot) are not just baked into every single node by default, they are a key part of working with the engine.
Signals are amazingly powerful. You can connect or disconnect functions via code or the graphical editor, permanently or as a one-shot function call, bind arguments as you please, you can even await them. You can, of course, create your own signals too.
Generally speaking, you will want to call down, signal up when working in Godot, meaning your node children will be called directly via NodePath and your node parents will listen for Signals that you emit. This way, your codebase stays clean and relatively easy to keep track of, even with multiple nested scenes all communicating with each other.
Resources
There’s really only two types of structures in Godot: Nodes and Resources. And if your thingamajic is not part of the former, it’s probably part of the latter.
Much like Unity’s ScriptableObjects, Resources can also be created through code classes. This means you can create complex data structures quickly and easily, save them to disc if needed, and share them across multiple node instances. There’s even a powerful inbuilt serialization system that can take any resource as input and convert it into text or bytes with only a single line of code.
Conclusion
There’s more to cover, but these five are the main pitfalls that you will need to look out for in my opinion. Getting started with Godot today is easier than it’s ever been and I’m excited to see what the future holds. The jump from 3.5 to 4.0 has been massive and there’s now more people creating pull requests for Godot than ever before.
Cheers!
