//rp.wtf

Godot productivity tips

Thu Oct 12 2023

Updated 16/06/2024

Godot is pretty great to work with—you have a fast, snappy engine with an integrated editor. It has a file size that's smaller than a lot of phone apps and comes with pretty sane defaults!

That said, you can probably squeeze out a bit more performance out of yourself, the developer, in particular, by trying out the following productivity tips.

Quick Open

Quick Open is a nice little dialog that shows a picker of your project files, and on pressing Enter, it opens it in the scene or script editor, respectively. By default, it's bound to "Shift+Alt+O". I personally rebounded it to the de-facto standard shortcut for file pickers, "Ctrl+P." What's great is that it works with an external editor as well!

Godot's Quick Open dialog.

One strange thing about its behavior is that it will open the script editor if you pick a script while in the 2D/3D editor, but it won't open the 2D/3D editor if you pick a scene while you are in the script editor. I guess it's because it doesn't look at the root node of the scene file to determine if it should open the 2D or 3D editor.

Quick Run Scene

So, you are working on a scene that isn't the default scene, so you set it in the project settings as the main scene, but then you accidentally commit it to git, and then other teammates start giving you shit about it, so you start using Run Current Scene (F6), but quickly realize that having to select that scene every time you want to run it is kinda inconvenient.

"Quick Run Scene" has your back! By default, it's bound on Ctrl+Shift+F5 (at the time of writing, in the editor shortcuts it is listed as "Run Specific Scene"), but I have it bound on F5 as it's my go-to way of running scenes. If you don't close the game screen, you won't have to retype the name of the scene again; it will just relaunch the last one! Allows you to iterate quickly!

Godot's Quick Run Scene dialog.

Unique names

If you are like me, you are using $SomePath, or get_node("SomePath") to store references to the nodes you need. Then you move nodes into a container, everything breaks, and you have to adjust the paths. Frustrating. There is a better way, though: unique nodes.

You mark a node as unique by right-clicking it and then pressing "Access as Unique Name."

Godot 4 node context menu with a red arrow pointing to the Access As Unique Name item.

(It took me longer than I'd like to admit to draw that arrow.)

As you can see, a percentage symbol appears next to it. After that is done, you can just reference it with a % prefix, like this:

# assuming your node is called "SomeImportantChildNode"
@onready var some_important_node = get_node("%SomeImportantChildNode")

These names are local to the scene, so in other scene files, you can freely reuse the "SomeImportantChildNode" name as unique. Unique nodes, just like regular nodes, can also reuse the same name as long as they are not siblings in the hierarchy, but you can't have two unique nodes with the same name within the same scene:

An alert dialog in godot with the text 'Unique names already used by another node in the scene: SomeImportantNode'

In terms of the "tscn" file, it just adds the unique_name_in_owner = true to the node data, nothing magical. But now, you can freely move it around in your scene tree, and some_important_node will keep pointing to the same thing, and there's no path that needs updating!

Inherit selectively

Imagine you create a new scene; the top node is a HBoxContainer. You need to do more things with it than the inspector lets you, so you attach a script to it. By default, its top line will say extends HBoxContainer. All is well, but suddenly you decide that you want to align the children vertically, so you change the type of your HBoxContainer to a VBoxContainer. You run the scene, and Godot crashes.

Script inherits from native type "HBoxContainer", so it can't be assigned to an object of type: "VBoxContainer".

So you go into your script, change the top line to extends VBoxContainer, and work continues. After a while, you change the type back to a HBoxContainer, because, you know, iteration and stuff. Now you have to go back into your script and change the top line again. In time, you realize you aren't using the methods of the HBoxContainer. Hell, the HBoxContainer doesn't even have methods.

What's the solution, then? You extend higher up the inheritance hierarchy. In simpler words, you pick a class that HBoxContainer inherits from, e.g., Container, Control, or CanvasItem (you can see the inheritance hierarchy at the top of every node documentation page), depending on what functionality you need in your script. In even simpler words, extend Control if you attach a script to a user interface item (like a container), extend Node if you don't need to do anything more than add_child() in your script. I hope you get the gist.

If you're wondering, that won't impact the node itself. The inspector's properties for the node won't change, its behavior won't change, etc.

A godot root node which has the CanvasItem icon even though its a HBoxContainer

The icons do change, though. The HBoxContainer here has the icon of a CanvasItem.

Of course, if your node is, let's say, a Label and you need to change the text property, you need extends from Label; otherwise, accessing text will give you an error.

In the end, this is purely situational, but it is good to know nonetheless. The more you use Godot, the more you'll start to remember these inheritance hierarchies, and then you'll be able to decide if you actually need to extend your script from the exact type of your node or if you can just use some of its parent classes.

Create a setup script for new projects

If you are like me and you create new Godot projects regularly, you can use a setup script to quickly set up project settings in a new project. I describe the process in the article "Godot project configuration with GDScript".

QWER

Q, W, E, and R are the keyboard shortcuts for select, move, rotate, and scale, respectively. You can use these to quickly change the cursor modes in the 2D and 3D workspaces, which is really convenient when you are working with canvas items a lot, like when doing world design. I checked, and these shortcuts are the same as in Unity 3D too, which I felt was important to mention for some reason.

Main tools of Godot's canvas workspace.

Also, you can probably boil down this entry to "learn keyboard shortcuts". So here's some more, which I use on a daily basis:

I personally don't use the built-in script editor (<insert vim flex>), but @dbat hooked me up with some useful protips for it:

Also, dbat recommends, and I agree, that you should have "Trim Trailing Whitespace on Save" turned on (Editor Settings → Text Editor → Behavior), especially if you use git and want to have diffs that are easier to read.

There are shortcuts for lots of things, and everyone should be able to find some to speed up their workflow. With that, I hope that the Godot developers add even more over time (or just actions that can be bound to keyboard shortcuts), e.g., one for attaching scripts, which is an action I use constantly.

Quick node references

If you hold Ctrl while you drag a node from the node tree into the code editor, Godot will generate a variable with the reference for you:

Holding ctrl allows you to create a reference to the node in the code

Blender style transforms

If, unlike me, you are familiar with Blender, you can enable Blender-style transforms in the spatial editor, like:

Keep in mind that you have to assign keybinds to them first because they are not bound by default. Just go to Editor → Editor Settings → Shortcuts and type "begin" in the filter bar:

Blender style transform bindings

And the results:

Holding ctrl allows you to create a reference to the node in the code

Editor layout

Last but not least, and somewhat obvious, I still wanted to include it for completeness sake.

Find some time to create an editor layout that works for you.

Godot engine's main editor screen with a custom layout.

This is what works for me. Now I just need an ultrawide screen.

Identify the actions which you do the most and create a layout which serves them best. I am mostly doing game logic, game backends, those kinds of things, so my layout is tailored to that. Artists might have a different layout, generalists might have a different layout, depending on their current focus.

Conclusion

I hope these will help you get more done in less time, or that at the very least you learned something new! I will add more tips to this article over time, as Godot is in active development and cool new stuff gets added all the time. If you have any advice of your own, comments, or criticisms, let me know in the socials!