I picked up Godot for a small game jam two years ago and never went back to anything else for 2D work. I had used Unity before, and the contrast was immediate. Godot opens in under three seconds, the editor itself is one self contained download of about a hundred megabytes, and the whole thing is open source under the MIT license. That last part stopped mattering to me until the day Unity announced runtime fees and I realized how much it matters to own your tools. This post is the orientation I wish someone had handed me on day one.
What Godot actually is
Godot is a free, open source engine for 2D and 3D games. It runs on Windows, macOS, and Linux, and it exports to all the desktop platforms plus web, Android, and iOS. There is no account to create, no license server, no splash screen on your finished game. You download the editor, unzip it, and run it. I keep three different versions on disk because switching is just a different executable.
The version that changed everything was Godot 4. It brought a rewritten rendering backend built on Vulkan, real global illumination for 3D, and a much faster scripting layer. If you are starting today, start on Godot 4. Most tutorials older than that target Godot 3, and the API differences will trip you up constantly.
Nodes and scenes are the whole mental model
Everything in Godot is a node. A sprite is a node. A sound player is a node. A collision shape is a node. You arrange nodes into a tree, and a saved tree is called a scene. That is genuinely the entire architecture, and once it clicks you stop fighting the engine.
The part that took me a week to internalize is that scenes nest. A coin is a scene with a sprite, a collision area, and a sound. Your level is a scene that contains dozens of coin scenes as children. Your whole game is a scene that swaps levels in and out. There is no separate concept of a prefab like in other engines, because every scene is already reusable by design.
Here is how I think about which node to reach for:
- Node2D is the base for anything with a position, rotation, and scale in 2D space.
- CharacterBody2D is what you want for a player or enemy that moves and collides but that you control directly in code.
- Area2D detects overlaps without pushing things around, perfect for pickups, triggers, and hurtboxes.
- Sprite2D and AnimatedSprite2D draw your art.
- CanvasLayer holds your UI so it stays fixed while the camera moves.
GDScript is not Python, but it rhymes
Godot ships with its own scripting language called GDScript. It looks a lot like Python, with indentation based blocks and dynamic typing, but it is built into the engine so it knows about nodes and the scene tree natively. You can also use C# if you need it, and there is a C++ path through GDExtension for performance critical code, but I have shipped real games entirely in GDScript and never hit a wall.
Every script extends a node type. The two functions you will write constantly are _ready, which runs once when the node enters the tree, and _process, which runs every frame. Here is a tiny script that spins a sprite and prints a greeting:
extends Sprite2D
# How fast we rotate, in radians per second
var spin_speed := 2.0
func _ready() -> void:
print("Sprite is ready")
func _process(delta: float) -> void:
# delta is the time since the last frame, so motion stays
# consistent no matter the framerate
rotation += spin_speed * delta
Notice the optional type hints with the colon and the walrus style colon equals for inferred types. I strongly recommend typing your variables. The editor gives you better autocomplete, and the compiler catches mistakes you would otherwise find at runtime.
The signal system, or how nodes talk
Godot leans hard on a publish and subscribe pattern called signals. A button emits a pressed signal. An Area2D emits a body_entered signal when something overlaps it. You connect those signals to functions, either by dragging in the editor or in code. This keeps your nodes decoupled, because a coin does not need to know anything about the player, it just announces that it was touched.
You can connect a signal from code like this:
extends Area2D
func _ready() -> void:
body_entered.connect(_on_body_entered)
func _on_body_entered(body: Node2D) -> void:
print("Something entered: ", body.name)
queue_free()
The queue_free call removes the node safely at the end of the frame. Get comfortable with signals early. Fighting against them by polling state every frame is the most common beginner mistake I see.
The editor layout you will live in
The editor has a Scene dock on the left that shows your node tree, a FileSystem dock below it for your project files, an Inspector on the right for tweaking properties, and the viewport in the middle. The bottom panel is where the output console, the debugger, and the animation editor live. I dock the debugger open at all times because the stack traces are good and the remote scene tree lets you inspect a running game live.
One habit that paid off: keep your project organized into folders from the start. I use a scenes folder, a scripts folder, an assets folder for art and audio, and an autoload folder for global singletons. Godot does not impose a structure, so the discipline is on you.
Autoloads for global state
When you need something accessible from everywhere, like a score manager or an audio bus, you register a scene or script as an autoload in the project settings. It becomes a singleton that loads before everything else and persists across scene changes. This is how I handle the player inventory, settings, and save data. Do not overuse it, but for genuinely global concerns it is the cleanest tool Godot gives you.
Exporting your game
When you are ready to share, you install export templates once and then pick a preset for each platform. Web export is my favorite for jams because you upload a folder and anyone can play in a browser instantly, no download required. Desktop exports produce a single executable. The whole process takes a couple of minutes once it is set up.
Where to go next
The fastest way to learn Godot is to build something tiny and finish it. Do not start with your dream RPG. Make a game where one thing moves and one thing happens when you touch another thing. Once you have the engine basics down, the natural next step is putting them together into something playable. I wrote a full walkthrough of exactly that in building a 2D game in Godot with GDScript, where we wire up a moving character, collisions, and a score from scratch.
Godot rewards people who ship. The engine gets out of your way, the community is generous, and the documentation is genuinely excellent. Download it, open a blank project, and add your first node today.