See all glossary terms

Editor Tooling

One of the benefits of editors like Godot is the ability to visually change values like images or animations, or change numbers, and see the changes reflected immediately without having to run the game.
This is important because in games, iteration speed really helps in polishing and finding the fun in your game. With this said, most games have specific needs that the editor won't cover. Almost any ambitious game will require some custom tooling.
This is much more convenient if the tooling is part of the interface. Because this is so important, virtually all game engines have some form of editor scripting. This allows you to extend the editor with custom tools, and automate repetitive tasks. In Godot, this is specially easy, thanks to the fact that the editor is itself a Godot game; everything you can do in a game, you can do in the editor, and vice versa. This means everything within the editor can be manipulated.
There are several levels of tooling that one can do in Godot. The simplest is to just use the @export annotation with properties. With this simple mechanism, you can already do quite a lot thanks to the neat additional and special exports that Godot provides (see the breakdown here).
But sometimes, this isn't enough. For running scenes in the editor, you can add the @tool keyword at the top of the script. This will make the script run in the editor. This is useful for creating custom tools that run in the editor, like a level editor or a custom inspector. To check if you're in the editor or not (to avoid running functions that you want only in the game), you can use if Engine.editor_hint:.
Once the @tool keyword is set, you can make use of _get_property_list to get a custom list of properties to show in the inspector. This is more versatile than using @export because you can add custom logic, and have more freedom about how things are presented. It's however fairly complicated and not very documented (Explaining how it works is outside the scope of this article, but we may write about it some day).
You can also override _get_configuration_warnings() to show the little warning icon.
You can run scripts in the editor directly, not tied to any scene or node, by using EditorScript:
@tool
extends EditorScript

func _run():
	pass
You can then run the script with FileRun. This is useful for testing things, or for example automations.
Finally, you can also use the EditorPlugin class to create custom tools that run in the editor. This is a bit more complicated, but it's very powerful. You can create custom inspectors, custom editors, tabs, and even custom scenes that run in the editor. That's how the GDQuest exercises and the tour are made.

See Also

Related terms in the Glossary